Re: Patch 2/3 for topic/libposix

[Bruce Korb]

On 11/11/10 17:23, Eric Blake wrote:
> It's nice to provide a ChangeLog entry, either as a patch to ChangeLog
> itself or as the commit message (or both; if you use Jim's vc-dwim pacage).

True, hadn't dotted my "i"s nor crossed my "t"s yet.

>>  /* The calling program should define program_name and set it to the
>>     name of the executing program.  */
>> -extern char *program_name;
>> +#ifdef HPUX
>> +extern
>> +#endif
>> +char *program_name;
> 
> I'm not convinced this change is correct.

Because I misspelled the guard, or the approach?
Basically, the "extern" is needed on those platforms
where, as Ralf said, the anonymous segment is not
supported.  My fuzzy recollection is that HPUX was
one such and as such needs an explicit, non-conflicting
definition.  Unfortunately, "program_name" is a pretty
likely name for some external that some program will
use, so I think it inadvisable to unconditionally define
the thing in this library.

>> +  else if (program_name == NULL)
>> +    {
>> +#if _LIBC
>> +      __fxprintf (NULL, "program_name not set\n");
>> +#else
>> +      fprintf (stderr, "program_name not set\n");
>> +#endif
> 
> mid-method #ifdefs are harder to maintain.  Easier is an up-front:
>
> #ifndef _LIBC
> # define __fxprintf fprintf
> #endif

I agree.  I was just hoisting duplicate code into an inline function.
The define needs to be a little more complicated though:

#ifndef _LIBC
# define __fxprintf fprintf
# define FPRINTF_FP stderr
#else
# define FPRINTF_FP NULL
#endif

> More importantly, error.c is a file that we sync with glibc.  We should
> probably work on updating the synchronization between the two places, as
> well as cleaning up existing style, so that it would be easier to push
> this patch back into glibc sources.  I'm a bit reluctant to push this
> big of a patch into gnulib without first gauging glibc response; if we
> could reduce the size of the changes and still resolve the root cause
> that you are trying to address, that might be better.

The problem I am addressing is that seg faulting in response to an
anticipatable and easily detected "mistake" is in itself a mistake.
This is especially true if the "mistake" is a failure to call a
non-POSIX function when using a library that purports to be a
POSIX backfill library.  I spent a little time trying to chase through
dependencies to try to figure out how the error module gets pulled in,
but it turned out that the POSIX modules pulled in a lot of modules
that are not POSIX.  There were a lot of threads to follow and I
did not have a lot of time to follow them.

RE: following up with glibc.  I agree, it should be done.
Forgive me if I defer and beg someone else to do the deed.
Are you volunteering?  Please?

Thank you!  Regards, Bruce