linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>,
	"Robert P. J. Day"
	<rpjday-L09J2beyid0N/H6P543EQg@public.gmane.org>
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: should "man feature_test_macros" mention _LARGEFILE_SOURCE?
Date: Wed, 19 Mar 2014 14:37:51 +0100	[thread overview]
Message-ID: <53299DAF.20201@gmail.com> (raw)
In-Reply-To: <4257256.dYt9XWSnPY@vapier>

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

  parent reply	other threads:[~2014-03-19 13:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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) [this message]
     [not found]     ` <53299DAF.20201-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-03-19 19:15       ` Mike Frysinger
2014-03-20  7:53         ` Michael Kerrisk (man-pages)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53299DAF.20201@gmail.com \
    --to=mtk.manpages-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=rpjday-L09J2beyid0N/H6P543EQg@public.gmane.org \
    --cc=vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).