../sysdeps/posix/cuserid.c:30: warning: function declaration isn't aprototype

Mark Brown bmark@us.ibm.com
Thu Aug 17 12:37:00 GMT 2000


I'll add my 2-cents (US) here from a standards-conformance perspective.

Mark Kettenis wrote:
> Depends on what we want _GNU_SOURCE to be.  According the the manual
> it is:
> 
>  - Macro: _GNU_SOURCE
>      If you define this macro, everything is included: ISO C, POSIX.1,
>      POSIX.2, BSD, SVID, X/Open, LFS, and GNU extensions.  In the cases
>      where POSIX.1 conflicts with BSD, the POSIX definitions take
>      precedence.
> 
> I suppose _GNU_SOURCE is more or less a moving target, i.e. it is the
> latest ISO C, POSIX, X/Open, etc. that is included.  However, I think
> that should be the latest *official* ISO C, POSIX, X/Open stuff.
> Right now that means ISO C99, POSIX.1:1996 and X/Open issue 5.  Since
> cuserid is present in X/Open Issue 5, I think we should continue to
> provide the cuserid prototype.  In this view it is also debatable
> whether _GNU_SOURCE should enable X/Open Issue 6 until it is final.

Tracking to drafts is asking for a world of pain. I would not
have _GNU_SOURCE enable Austin Group project material ("Issue 6") until it
is final. In fact, my personal preference would be to wait and do C99 
and the Austin Group specification at the same time :-) 

However: cuserid *is* a rquired part of the Open Group SUS ("Issue 5")
and if _GNU_SOURCE claims to support it, cuserid should be there. It is
also in the SVID3 (BA_OS). As much as you may not like the interface,
keeping it adds to overall source portability.

mark 
-- 
Mark S. Brown                                                   bmark@us.ibm.com
IBM RS/6000 AIX System Architecture                    512.838.3926  T/L678.3926
IBM Corporation, Austin, Texas


More information about the Libc-hacker mailing list