stdio fudging errno ?

stdio fudging errno ?

[Vineet Gupta]

Hi,

I've been trying to cleanup uClibc test-suite failures on ARC and when debugging
test-double ran into a totally unrelated issue where it fails as

| testing double (without inline functions)
| Failure: finite (0): errno set to 11, expected 0 (unchanged)

Turns out the test harness uses asprintf() which seems to be fudging errno causing
test harness to erroneously declare failure:


Here's a simple test case which shows the problem:

	#define _GNU_SOURCE
	#include <stdio.h>
	#include <stdlib.h>
	#include <errno.h>

	void main(void)
	{
        	const char *this_func = "finite";
	        char *test_name;

        	errno = 0;
	        if (asprintf (&test_name, "%s (%s)", this_func, "my-str") == -1)
			abort ();

	        printf("%d\n", errno);	// <-- prints 11
	}

The errno unconditionally being set to EAGAIN seems to have been introduced in
commit 568ceebf6adfc58c64a95133311268db6 ("Fix infinite loop when fopencookie
custom write returns 0 on error") bakc in 2016.

+#define __STDIO_STREAM_CUSTOM_WRITE_FUNC(S, ARGS...) \
+ if (__STDIO_STREAM_IS_CUSTOM((S))) { \
+       _IO_cookie_file_t *cfile = (_IO_cookie_file_t *) (S); \
+       if (cfile->__gcs.write == NULL) { \
+               __set_errno(EINVAL); \
+               return -1; \
+       } \
+       __set_errno(EAGAIN); \
+       ssize_t w = cfile->__gcs.write(cfile->__cookie, ##ARGS); \
+       return (w == 0 ? -1 : w); \
+ }


I don't understand all the logic but shouldn't it be set after __gcs.write() call ?

Thx,
-Vineet


_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [uclibc-ng-devel] stdio fudging errno ?

[Florian Weimer]

* Vineet Gupta:

> Here's a simple test case which shows the problem:
>
> 	#define _GNU_SOURCE
> 	#include <stdio.h>
> 	#include <stdlib.h>
> 	#include <errno.h>
>
> 	void main(void)
> 	{
>         	const char *this_func = "finite";
> 	        char *test_name;
>
>         	errno = 0;
> 	        if (asprintf (&test_name, "%s (%s)", this_func, "my-str") == -1)
> 			abort ();
>
> 	        printf("%d\n", errno);	// <-- prints 11
> 	}
>
> The errno unconditionally being set to EAGAIN seems to have been
> introduced in commit 568ceebf6adfc58c64a95133311268db6 ("Fix
> infinite loop when fopencookie custom write returns 0 on error")
> bakc in 2016.

For functions specified by standards, successful calls can alter errno
unless specified otherwise.  asprintf is not a standardized function,
but it is reasonable to expect that a similar rule applies.

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [uclibc-ng-devel] stdio fudging errno ?

[Vineet Gupta]

On 12/14/19 1:37 AM, Florian Weimer wrote:
> * Vineet Gupta:
>
>> Here's a simple test case which shows the problem:
>>
>> 	#define _GNU_SOURCE
>> 	#include <stdio.h>
>> 	#include <stdlib.h>
>> 	#include <errno.h>
>>
>> 	void main(void)
>> 	{
>>         	const char *this_func = "finite";
>> 	        char *test_name;
>>
>>         	errno = 0;
>> 	        if (asprintf (&test_name, "%s (%s)", this_func, "my-str") == -1)
>> 			abort ();
>>
>> 	        printf("%d\n", errno);	// <-- prints 11
>> 	}
>>
>> The errno unconditionally being set to EAGAIN seems to have been
>> introduced in commit 568ceebf6adfc58c64a95133311268db6 ("Fix
>> infinite loop when fopencookie custom write returns 0 on error")
>> bakc in 2016.
> For functions specified by standards, successful calls can alter errno
> unless specified otherwise.  asprintf is not a standardized function,
> but it is reasonable to expect that a similar rule applies.

Right, but ...

1. Don't those standards specify the exact errno for specific scenarios and that
typically errno won't be changed to !0 if there was no error.
2. The EAGAIN being returned can be seen as "leaking" out of internal details of
the ensuing call stack.
3. This breaks the way uclibc test harness works. It clears the errno at the start
of a call sequence and in the end when notices the change it trips. It expects the
errno to be set (or not set) by the math routines and asprintf changing them trips
it. glibc test harness is no different - it would have failed in similar way had
similar errno fudging existed there !

At any rate the fix is simple to only change errno in case of a failure.

Thx,
-Vineet
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc