Paul Eggert wrote:
> But the function names use leading __ in both Solaris and glibc, and I
> expect that if they are ever standardized they'll be standardized with
> the leading __.
I sincerely hope no standardization group would do such a mistake:
- Standardizing functions starting with '__' would encourage users to
adopt similar naming conventions (since users often use conventions
prototyped by the OS vendors), leading to collisions between user namespace
and compiler/libc namespace.
- The function __fpurge has no return value. But the 'fpurge' function
on Cygwin can fail. The Solaris people forgot to think about possible
failures.
- The function __flbf is only half-baken: it returns only part of the
information provided by the 3rd argument to setvbuf. This function
does not allow the user to distinguish unbuffered and block-buffered
streams. A better function should return the 3rd argument unchanged.
- The functions __freadable, __fwritable, __freading, __fwriting need to
return 'bool' in gnulib, otherwise an assignment
bool x = __freadable (fp);
may assign an invalid integer (4 or such) to x, if '_Bool' is not a
compiler builtin type.
> So for this particular case I suggest using names
> with leading __, at least in user code
I think gnulib should not provide functions starting with '__'. Remember
the '__setfpucw' and '__libc_wait' functions from glibc? glibc offered them,
people used them, and then glibc withdraw them and broke widespread programs.
And Ulrich Drepper said effectively: "The application programmers should not
have used these functions; it was obvious, since they start with __".
How can anyone expect users to understand that '__' symbols are reserved,
if glibc documents such functions?
Bruno
