Eric Blake writes ("Re: [RFC PATCH 1/7] error reporting: Introduce errnoval
parameter to vreport"):
> On 04/26/2018 12:32 PM, Ian Jackson wrote:
> > But, 0 might be fed to strerror. This is not normally deliberate, but
> > it does occor. It is not unusual for people to write code which can
> > f
On 04/26/2018 12:24 PM, Eric Blake wrote:
>> @@ -222,6 +224,11 @@ static void vreport(report_type type, const char *fmt,
>> va_list ap)
>> }
>>
>> error_vprintf(fmt, ap);
>> +
>> +if (errnoval >= 0) {
>> +error_printf(": %s", strerror(errnoval));
>
> Off-by-one. You do N
On 04/26/2018 12:32 PM, Ian Jackson wrote:
>>> * Print a message to current monitor if we have one, else to stderr.
>>> * @report_type is the type of message: error, warning or informational.
>>> + * If @errnoval is nonnegative it is fed to strerror and printed too.
>>
>> That implies 0 is fed
Eric Blake writes ("Re: [RFC PATCH 1/7] error reporting: Introduce errnoval
parameter to vreport"):
> On 04/26/2018 11:53 AM, Ian Jackson wrote:
> > We use strerror rather than strerror_r because strerror_r presents
> > portability difficulties. Replacing strerror with strerror_r (or
> > somethin
On 04/26/2018 11:53 AM, Ian Jackson wrote:
> This will allow new callers of vreport to specify that an errno value
> should be printed too. Update all existing callers.
>
> We use strerror rather than strerror_r because strerror_r presents
> portability difficulties. Replacing strerror with stre
This will allow new callers of vreport to specify that an errno value
should be printed too. Update all existing callers.
We use strerror rather than strerror_r because strerror_r presents
portability difficulties. Replacing strerror with strerror_r (or
something else) is left to the future.
No
