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

Mark Kettenis kettenis@wins.uva.nl
Wed Aug 16 14:28:00 GMT 2000


   From: Ulrich Drepper <drepper@redhat.com>
   Date: 15 Aug 2000 09:05:43 -0700

   Andreas Jaeger <aj@suse.de> writes:

   > _GNU_SOURCE defines both - and we don't get a prototype.  How should
   > this get fixed?

   Tricky.  Not providing the prototype wven for _GNU_SOURCE is sending
   the right message since nobody should use this function...  We could
   add an additional prototype in include/stdio.h or make the prototype
   visible for _GNU_SOURCE.  Preferences?

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.

Another argument for providing the cuserid prototype is the fact that
cuserid() is derived from System V Release 2.0 according to the Unix
98 man page.  Therefore I assume it is in SVID, and _GNU_SOURCE is
supposed to include SVID.  However this would probably mean we'd have
to include the legacy stuff in _GNU_SOURCE forever, and I'm not sure
I'd want that.

I guess I don't really care ...

Mark


More information about the Libc-hacker mailing list