[PATCH] Implement error_print_progname
Carmelo Amoroso
carmelo73 at gmail.com
Wed Apr 2 21:07:59 UTC 2008
Will Newton wrote:
> On Fri, Mar 21, 2008 at 12:47 PM, Will Newton <will.newton at gmail.com> wrote:
>> On Fri, Mar 21, 2008 at 7:47 AM, Carmelo Amoroso <carmelo73 at gmail.com> wrote:
>>
>> Hi Carmelo,
>>
>>
>> > Will Newton wrote:
>> > > Further to the changes to error.c to fix bug #1869 it would be nice if
>> > > uClibc supported error_print_progname. The attached patch aims to do
>> > > that.
>> > >
>> > >
>> >
>> > Hello,
>> > this is an old story. uClibc doesn't provide support for error_print_progname
>> > even if header error.h declare it.
>> > I would like to have it implemented before using. If we know that it's missing,
>> > while testing for its value and call it ?
>> > This my opinion.
>>
>> I know, I've been subscribed to this list some time and I have read
>> the archives.
>>
>> As I understand it error_print_progname is a global that is intended
>> to be assigned by the user, that is how the interface is intended to
>> be used:
>>
>> "If the global variable error_print_progname is assigned the address
>> of a function (i.e., is not NULL), then that function is called
>> instead of prefixing the message with the program name and colon. The
>> function should print a suitable string to stderr. "
>>
>> And I think my patch implements that.
>>
>> error.h is a GNU interface and dropping one part of it
>> (error_print_progname) seems to be unnecessarily incompatible. Better
>> to remove error.h completely than implement 95% of it, at least then
>> e.g. gnulib can be used as a replacement.
>>
>
> Ping!
>
> Does anyone have any objections to this patch? I'll be happy to
> incorporate any improvements people can suggest.
>
> Thanks,
>
Hi Will,
honestly speaking I did not understand the fact that error_print_progname
should be assigned to a user function. Now reading the comment again
I'm convinced about that, and yes, your patch looks fine to me.
Does anybody have concerns about ? otherwise it can be committed.
Carmelo
More information about the uClibc
mailing list