[tlbuild] dvi test?

[Paul Vojta]

On Wed, Feb 02, 2022 at 02:53:32AM +0100, Bruno Haible wrote:
> Karl Berry wrote:
> > I think it's the implementation of ftruncate that is doing that lseek
> 
> I don't think so: ftruncate is marked as a "system call" in macOS [1];
> if ftruncate() would change the file descriptor's position, you wouldn't
> see it in the dtruss log.
> 
> Rather, the situation is that the OS provides two subsystems:
> 
>   * the file descriptors, nearly entirely handled in the kernel,
> 
>   * the FILE streams, implemented in libc, based on file descriptor
>     system calls. In particular, a FILE stream typically has a file
>     descriptor, a cache for the position of that file descriptor, a
>     buffer and a "next byte to read" pointer into that buffer.
>     fseek() on buffered FILE streams is typically implemented as follows:
>       - if the new position is inside the buffer region, it just updates
>         some fields in the FILE struct,
>       - otherwise it invalidates the buffer and makes an lseek() call on
>         the file descriptor.
> 
>     IMPORTANT: The FILE stream implementation assumes that it owns
>     the file descriptor, that is, that the application does not do
>     system calls with the file descriptor.
> 
>     It could well be that the make_backup_fp function, especially
>     through
>       target_fp = try_fdopen(tmp_fd, "wb+")
>     and continued use of tmp_fd, violates this assumption.

Good point.  The message thread

    https://stackoverflow.com/questions/873454/how-to-truncate-a-file-in-c

provides a bit more information on this matter.

Most notably, probably it would be a good idea to call fseek() and fflush() 
before ftruncate().

--Paul