Re: [PATCH] strerror_r: avoid compiler warning

[Eric Blake]

On 05/25/2011 03:49 AM, Bruno Haible wrote:
>> in the latter case, deleting the 
>> only declaration here makes compilation fail (which is what we want,
>> since that means the system didn't really comply with POSIX after all).
> 
> The usual gnulib approach is to provide the declaration only. This is also
> what we do in string.in.h:
> 
> #  if address@hidden@
> _GL_FUNCDECL_SYS (strerror_r, int, (int errnum, char *buf, size_t buflen)
>                                    _GL_ARG_NONNULL ((2)));
> #  endif
> 
> But in the module description modules/strerror_r, we happen to use the
> replacement function also when only the declaration is missing, so indeed
> in this case it doesn't matter what the "checking whether strerror_r works"
> test reports. Probably this was done because on OSF/1 the declaration is
> 
> #if defined(_REENTRANT) || defined(_THREAD_SAFE)
>                 /* _POSIX_REENTRANT_FUNCTIONS */
> extern int      strerror_r __((int, char *, int));
> #endif

HP-UX 10.20 has a similar situation; the declaration is hidden behind
_REENTRANT (which is not provided by the 'extensions' module), but if it
is exposed, it uses int instead of size_t.

> 
> and it's risky to mix function pointers with 'int' vs. 'size_t' arguments.

Still, I can't help wonder if we should be trying to use the hidden
strerror_r on HP-UX - right now, the code falls back to the sys_nerr or
strerror path, which seems awkward if the system strerror_r can help us out.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature