Hi Eric,
> > since the caller does not know
> > in advance how long the string will be (i.e. how long the buffer needs
> > to be for a complete message), that ERANGE should be the "lowest priority"
> > error. That is, I think EINVAL should take precedence over ERANGE.
>
> I personally disagree -
On 05/20/2011 05:21 PM, Eric Blake wrote:
> But both errors are allowed by POSIX, and we have the case that glibc's
> __xpg_strerror_r favors EINVAL while cygwin's _xpg_strerror_r favors
> ERANGE. The testsuite tests for both codes, because there is no
> heirarchy in POSIX on which error code if m
On 05/20/2011 04:50 PM, Bruno Haible wrote:
> Hi Eric,
>
>> @@ -95,6 +95,15 @@ int
>> strerror_r (int errnum, char *buf, size_t buflen)
>> #undef strerror_r
>> {
>> + /* Filter this out now, so that rest of this replacement knows that
>> + there is room for a non-empty message and trailing
Hi Eric,
> @@ -95,6 +95,15 @@ int
> strerror_r (int errnum, char *buf, size_t buflen)
> #undef strerror_r
> {
> + /* Filter this out now, so that rest of this replacement knows that
> + there is room for a non-empty message and trailing NUL. */
> + if (buflen <= 1)
> +{
> + if (
* lib/strerror_r.c (strerror_r): Filter out buflen of 1 up front.
Signed-off-by: Eric Blake
---
ChangeLog|3 +++
lib/strerror_r.c | 30 +-
2 files changed, 12 insertions(+), 21 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 598238f..bda43a6 1006
