* should "man feature_test_macros" mention _LARGEFILE_SOURCE?
@ 2014-03-18 19:46 Robert P. J. Day
2014-03-18 20:19 ` Michael Kerrisk (man-pages)
2014-03-19 2:48 ` Mike Frysinger
0 siblings, 2 replies; 7+ messages in thread
From: Robert P. J. Day @ 2014-03-18 19:46 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w; +Cc: linux-man-u79uwXL29TY76Z2rM5mHXA
just noticed under /usr/include on my fedora rawhide system the
following:
/usr/include/bits/environments.h:# define __ILP32_OFFBIG_CFLAGS "-m32 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
/usr/include/python3.3m/pyconfig-64.h:#define _LARGEFILE_SOURCE 1
/usr/include/features.h: _LARGEFILE_SOURCE Some more functions for correct standard I/O.
/usr/include/features.h:# undef _LARGEFILE_SOURCE
/usr/include/features.h:# define _LARGEFILE_SOURCE 1
/usr/include/features.h:#ifdef _LARGEFILE_SOURCE
/usr/include/python2.7/pyconfig-64.h:#define _LARGEFILE_SOURCE 1
but there's no mention of "_LARGEFILE_SOURCE" in "man
feature_test_macros". is that assumed to be implied by
_LARGEFILE64_SOURCE? it's not clear.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: should "man feature_test_macros" mention _LARGEFILE_SOURCE?
2014-03-18 19:46 should "man feature_test_macros" mention _LARGEFILE_SOURCE? Robert P. J. Day
@ 2014-03-18 20:19 ` Michael Kerrisk (man-pages)
2014-03-19 2:48 ` Mike Frysinger
1 sibling, 0 replies; 7+ messages in thread
From: Michael Kerrisk (man-pages) @ 2014-03-18 20:19 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: linux-man
On Tue, Mar 18, 2014 at 8:46 PM, Robert P. J. Day <rpjday-L09J2beyid0N/H6P543EQg@public.gmane.org> wrote:
>
> just noticed under /usr/include on my fedora rawhide system the
> following:
>
> /usr/include/bits/environments.h:# define __ILP32_OFFBIG_CFLAGS "-m32 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
> /usr/include/python3.3m/pyconfig-64.h:#define _LARGEFILE_SOURCE 1
> /usr/include/features.h: _LARGEFILE_SOURCE Some more functions for correct standard I/O.
> /usr/include/features.h:# undef _LARGEFILE_SOURCE
> /usr/include/features.h:# define _LARGEFILE_SOURCE 1
> /usr/include/features.h:#ifdef _LARGEFILE_SOURCE
> /usr/include/python2.7/pyconfig-64.h:#define _LARGEFILE_SOURCE 1
>
> but there's no mention of "_LARGEFILE_SOURCE" in "man
> feature_test_macros". is that assumed to be implied by
> _LARGEFILE64_SOURCE? it's not clear.
I don't know the answer, but when you do, send a patch!
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: should "man feature_test_macros" mention _LARGEFILE_SOURCE?
2014-03-18 19:46 should "man feature_test_macros" mention _LARGEFILE_SOURCE? Robert P. J. Day
2014-03-18 20:19 ` Michael Kerrisk (man-pages)
@ 2014-03-19 2:48 ` Mike Frysinger
2014-03-19 11:51 ` Robert P. J. Day
2014-03-19 13:37 ` Michael Kerrisk (man-pages)
1 sibling, 2 replies; 7+ messages in thread
From: Mike Frysinger @ 2014-03-19 2:48 UTC (permalink / raw)
To: Robert P. J. Day
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w,
linux-man-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]
On Tue 18 Mar 2014 15:46:43 Robert P. J. Day wrote:
> just noticed under /usr/include on my fedora rawhide system the
> following:
>
> /usr/include/bits/environments.h:# define __ILP32_OFFBIG_CFLAGS "-m32
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
> /usr/include/python3.3m/pyconfig-64.h:#define _LARGEFILE_SOURCE 1
> /usr/include/features.h: _LARGEFILE_SOURCE Some more functions for
correct
> standard I/O. /usr/include/features.h:# undef _LARGEFILE_SOURCE
> /usr/include/features.h:# define _LARGEFILE_SOURCE 1
> /usr/include/features.h:#ifdef _LARGEFILE_SOURCE
> /usr/include/python2.7/pyconfig-64.h:#define _LARGEFILE_SOURCE 1
>
> but there's no mention of "_LARGEFILE_SOURCE" in "man
> feature_test_macros". is that assumed to be implied by
> _LARGEFILE64_SOURCE? it's not clear.
nope, none of the three LFS flags imply each other, nor should they. they're
related, but orthogonal by design.
i could have sworn i saw a description of them in POSIX, but i can't find it
now. the GNU C library manual covers it though:
https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html
here's a terse summary off the top of my head:
_LARGEFILE_SOURCE: expose prototypes for new funcs which POSIX got wrong
originally. e.g. fseek & ftell utilize "long", so fseeko & ftello were added
which use "off_t".
_LARGEFILE64_SOURCE: expose prototypes for 64-bit variant funcs w/out
affecting any existing funcs. e.g. you now have fseeko64 & ftello64 which
take explicit off64_t types while fseeko and ftello are unchanged. makes
sense when sizeof(off_t) == 4 && sizeof(off64_t) == 8.
_FILE_OFFSET_BITS: explicitly set the off_t size. set it to 32 if you want
sizeof(off_t) == 4, or set it to 64 if you want sizeof(off_t) == 8.
in the ideal world, _FILE_OFFSET_BITS should default to 64 and
_LARGEFILE_SOURCE should default to defined. in our crap world, apps should
be always building with these in their CPPFLAGS.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: should "man feature_test_macros" mention _LARGEFILE_SOURCE?
2014-03-19 2:48 ` Mike Frysinger
@ 2014-03-19 11:51 ` Robert P. J. Day
2014-03-19 13:37 ` Michael Kerrisk (man-pages)
1 sibling, 0 replies; 7+ messages in thread
From: Robert P. J. Day @ 2014-03-19 11:51 UTC (permalink / raw)
To: Mike Frysinger
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w,
linux-man-u79uwXL29TY76Z2rM5mHXA
On Tue, 18 Mar 2014, Mike Frysinger wrote:
> On Tue 18 Mar 2014 15:46:43 Robert P. J. Day wrote:
> > just noticed under /usr/include on my fedora rawhide system the
> > following:
> >
> > /usr/include/bits/environments.h:# define __ILP32_OFFBIG_CFLAGS "-m32
> > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
> > /usr/include/python3.3m/pyconfig-64.h:#define _LARGEFILE_SOURCE 1
> > /usr/include/features.h: _LARGEFILE_SOURCE Some more functions for
> correct
> > standard I/O. /usr/include/features.h:# undef _LARGEFILE_SOURCE
> > /usr/include/features.h:# define _LARGEFILE_SOURCE 1
> > /usr/include/features.h:#ifdef _LARGEFILE_SOURCE
> > /usr/include/python2.7/pyconfig-64.h:#define _LARGEFILE_SOURCE 1
> >
> > but there's no mention of "_LARGEFILE_SOURCE" in "man
> > feature_test_macros". is that assumed to be implied by
> > _LARGEFILE64_SOURCE? it's not clear.
>
> nope, none of the three LFS flags imply each other, nor should they.
> they're related, but orthogonal by design.
... snip ...
i mentioned this only because the current features.h header file
mentions this macro near the top in the documentatiin:
...
_LARGEFILE_SOURCE Some more functions for correct standard I/O.
_LARGEFILE64_SOURCE Additional functionality from LFS for large files.
_FILE_OFFSET_BITS=N Select default filesystem interface.
...
but the man page for "feature_test_macros" says nothing about it. just
an observation.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: should "man feature_test_macros" mention _LARGEFILE_SOURCE?
2014-03-19 2:48 ` Mike Frysinger
2014-03-19 11:51 ` Robert P. J. Day
@ 2014-03-19 13:37 ` Michael Kerrisk (man-pages)
[not found] ` <53299DAF.20201-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
1 sibling, 1 reply; 7+ messages in thread
From: Michael Kerrisk (man-pages) @ 2014-03-19 13:37 UTC (permalink / raw)
To: Mike Frysinger, Robert P. J. Day
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w,
linux-man-u79uwXL29TY76Z2rM5mHXA
On 03/19/2014 03:48 AM, Mike Frysinger wrote:
> On Tue 18 Mar 2014 15:46:43 Robert P. J. Day wrote:
>> just noticed under /usr/include on my fedora rawhide system the
>> following:
>>
>> /usr/include/bits/environments.h:# define __ILP32_OFFBIG_CFLAGS "-m32
>> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
>> /usr/include/python3.3m/pyconfig-64.h:#define _LARGEFILE_SOURCE 1
>> /usr/include/features.h: _LARGEFILE_SOURCE Some more functions for
> correct
>> standard I/O. /usr/include/features.h:# undef _LARGEFILE_SOURCE
>> /usr/include/features.h:# define _LARGEFILE_SOURCE 1
>> /usr/include/features.h:#ifdef _LARGEFILE_SOURCE
>> /usr/include/python2.7/pyconfig-64.h:#define _LARGEFILE_SOURCE 1
>>
>> but there's no mention of "_LARGEFILE_SOURCE" in "man
>> feature_test_macros". is that assumed to be implied by
>> _LARGEFILE64_SOURCE? it's not clear.
>
> nope, none of the three LFS flags imply each other, nor should they. they're
> related, but orthogonal by design.
>
> i could have sworn i saw a description of them in POSIX, but i can't find it
> now. the GNU C library manual covers it though:
> https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html
>
> here's a terse summary off the top of my head:
>
> _LARGEFILE_SOURCE: expose prototypes for new funcs which POSIX got wrong
> originally. e.g. fseek & ftell utilize "long", so fseeko & ftello were added
> which use "off_t".
Thanks, Mike. I'd forgotten those details.
So, as far as I can see, _LARGEFILE_SOURCE is largely of (ancient) historical
interest, so I don't think I'll bother adding it to the FTM(7) page.
Cheers,
Michael
> _LARGEFILE64_SOURCE: expose prototypes for 64-bit variant funcs w/out
> affecting any existing funcs. e.g. you now have fseeko64 & ftello64 which
> take explicit off64_t types while fseeko and ftello are unchanged. makes
> sense when sizeof(off_t) == 4 && sizeof(off64_t) == 8.
>
> _FILE_OFFSET_BITS: explicitly set the off_t size. set it to 32 if you want
> sizeof(off_t) == 4, or set it to 64 if you want sizeof(off_t) == 8.
>
> in the ideal world, _FILE_OFFSET_BITS should default to 64 and
> _LARGEFILE_SOURCE should default to defined. in our crap world, apps should
> be always building with these in their CPPFLAGS.
> -mike
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-03-20 7:53 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-18 19:46 should "man feature_test_macros" mention _LARGEFILE_SOURCE? Robert P. J. Day
2014-03-18 20:19 ` Michael Kerrisk (man-pages)
2014-03-19 2:48 ` Mike Frysinger
2014-03-19 11:51 ` Robert P. J. Day
2014-03-19 13:37 ` Michael Kerrisk (man-pages)
[not found] ` <53299DAF.20201-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-03-19 19:15 ` Mike Frysinger
2014-03-20 7:53 ` Michael Kerrisk (man-pages)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).