[tlbuild] dvi test?

[John Hawkinson]

Bruno Voisin <bvoisin at icloud.com> wrote on Tue,  1 Feb 2022
at 11:05:05 EST in <DE1CE251-0CB0-44E3-9D5B-6132D5DC10B2 at icloud.com>:

> >      3208/0x31ed:  ftruncate(0x6, 0x0, 0x0)		 = 0 0
> >      3208/0x31ed:  lseek(0x6, 0xFFFFFFFFFFFFF7C7, 0x1)		 = -1 Err#22
...
> Looking whether ftruncate exhibits peculiar behavior on macOS I found this

Note that in this case, it's not ftruncate() that's failing but rather fseek()/lseek(), and as I noted yesterday, checking the return values from the fseek() calls is sufficient to catch this and make xdvi behave properly.

Despite a casual approach to checking return values of many many system calls, xdvi does indeed check and handle ftruncate() failing.

[...]
> But this is for data written to memory if I understood correctly,
> whereas xdvi uses it for a file, right?

Right.

I'd be medium-surprised if the concerns about Apple's ftruncate() misbehaving on shared memory segments applies to disk files, but perhaps. Anyhow it seems like we're zeroing in the the problem and there's enough to build a small test case outside of xdvi and figure out what is really going on under Darwin.

Among other things, this ftruncate() shared memory behavior was present in older versions of OSX where xdvi did not crash. Or so I conclude since the the lists.apple.com reference is from 2004 and the stackoverflow post is from 7 years ago.

--
jhawk at alum.mit.edu
John Hawkinson