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 !@HAVE_DECL_STRERROR_R@ > _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 ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature