[bug-gnulib] Re: automatic prototypes

[Simon Josefsson]

Jim Meyering <address@hidden> writes:

>> Perhaps it
>> would be simpler and easier to have a file "string-gnu.h" that
>> contains all the GNU extensions to string.h, and consolidate
>> memrchr.h, memmem.h, into string-gnu.h.  Similarly for unistd-gnu.h
>> and getcwd/getopt, etc.
>
> I have mixed feelings about this idea.
> On one hand, it documents in the code the dependency on a nonstandard
> interface.  But it also means more hard-to-check work for the developer:
> remembering to include that extra file, in case the code is built on
> a non-GNU system.  Sure, if they remember to include string-gnu.h from
> the start there's no problem, but if they do `man memrchr' and see that
> <string.h> is required, they might not add string-gnu.h until someone
> reports the problem when building on a non-GNU system.

If you use gnulib, you currently need to include memmem.h, memrchr.h
etc, which all are non-standard.  Why is that so different from
including string-gnu.h?

>> string-gnu.h could include string.h, so there'd be no need for a program
>> to include both files.
>
> That sounds good, but it would be better not to have to include
> any extra file at all.  For functions involving only types like
> struct stat*, char*, uid_t, gid_t, pid_t, size_t, ssize_t, etc.,
> that shouldn't be hard.

I'd prefer this as well.  This could be solved by putting the
prototypes for non-standard functions into config.h, see my "automatic
prototype" proposal.

Admittedly, it might be cleaner if there was a 'gnulib.h' which was
generated by gnulib-tool, and that file could be included.  Then I
could include it in config.h, and others could include it in their
source code explicitly.