Tcl Source Code

I noticed this in ticket:
   https://core.tcl.tk/tcl/info/92564326a98b5510

No code should ever be accessing the *64 functions directly.

The configuration process should be using the output
of `getconf LFS_CFLAGS` (and LFS_LDFLAGS and LFS_LIBS) as appropriate.

I apologize for any confusion, but my comment about the order of tests does not apply to _LARGEFILE64_SOURCE, so I don’t think [d6640b90305e] makes any difference. Although that macro is also considered obsolete, it is in the sense that the family of function declarations and structure definitions it enables, e.g. stat64() and struct stat64, are obsolete in favor defining _FILE_OFFSET_BITS=64 to enable 64-bit stat() and struct stat and using those instead. Not defining _LARGEFILE64_SOURCE leaves stat64() and struct stat64 disabled, regardless of whether _FILE_OFFSET_BITS=64 is defined.

Also be aware that, depending on whether _FILE_OFFSET_BITS=64 or _TIME_BITS=64 are defined, sizeof(struct stat64) and the implementation (i.e. symbol name) of stat64() can change on 32-bit systems.

P.S.: https://gcc.godbolt.org is a neat tool for exploring this stuff.

Thanks, I see your point: [d6640b90305e1e21]

Closing this ticket, since [d40b9c8503eb] already handles the necessary steps for old systems. I see no reason to rewrite the whole stuff, since all is obsolete in the 64-bit world anyway.

man feature_test_macros from the Linux man-pages project says that the _LARGEFILE_SOURCE macro is obsolete, and that _FILE_OFFSET_BITS=64 is now enough to enable 64-bit declarations of fseeko() and ftello(). I am not aware exactly how long this has been the case. But there is seemingly no harm in leaving a configuration test in Tcl for defining _LARGEFILE_SOURCE in case it is needed; it should now just go after the one for _FILE_OFFSET_BITS=64 (recently added for [d40b9c8503eb]).

A start implementing this, can be found in the "bug-02b58d5d04" branch. Basically, remove the use of the various "64"-related macro's.

Right.  If this had been done correctly (i.e. implicit) in the first
place, the referenced ticket would never have had a bug.

I cannot think of a reason to ever use explicit access.  Perhaps in the
early days of 32/64 conversion when a 32-bit API might need to be accessed.

I agree, there's no need to rush this into place, but I think it greatly
reduces the chances of bugs and should simplify the code.

"(implicit) 3. The size of filesize related data types is increased to 64 bits. eg off_t, blkcnt_t, etc are now 64 bits in size"

Since explicit was used, the size of off_t may be different on 32-bit systems.

bll-tecra:bll$ egrep -l off_t */*.c */*.h
generic/tclIOUtil.c
macosx/tclMacOSXFCmd.c  # 64-bit, no issue here.
unix/tclUnixChan.c
generic/regex.h
unix/tclUnixPort.h
bll-tecra:bll$ egrep -l blkcnt_t */*.c */*.h
generic/tclIOUtil.c

All of this is described in: https://people.redhat.com/berrange/notes/largefile.html

As I understand it, both 'implicit' and 'explicit' LSF is allowed. Care should be taken to the STAT functions as well, so it's not trivial to make this change. It gives more readable code, so I'll have a look. (I won't be angry if someone provides patches .....)

Anyway, such a change should be tested very well on various platforms. So I think it's wise to to that for Tcl 9, not 8.x, because it might easily break some platform if not done well.