Your message dated Tue, 17 Aug 2021 12:26:38 +0200 with message-id <[email protected]> and subject line Re: Bug#980764: libc6-dev: wrong return value for fputs when STDOUT_FILENO was closed() has caused the Debian Bug report #980764, regarding libc6-dev: wrong return value for fputs when STDOUT_FILENO was closed() to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 980764: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980764 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: libc6-dev Version: 2.28-10 Severity: normal When running following code: ```C #include <unistd.h> #include <stdio.h> #include <stdlib.h> int main() { close( STDIN_FILENO ); close( STDOUT_FILENO ); int fd = dup( STDERR_FILENO ); close( STDERR_FILENO ); if( -1 == fprintf( stdout, "%d\n", fd ) ) { return -1; } char s[] = "should fail\n"; if( -1 == write( STDOUT_FILENO, s, sizeof( s ) ) ) { return -2; } return EXIT_SUCCESS; } ``` built with glibc, the program returns 254. When built with muslc, it returns the expected value of 255. I believe glibc's behavior here is wrong. From what I could get by using strace, it seems that the 1st printf's write() call is ran _after_ the 2nd one, even when adding a call to fflush( stdout ) right after the printf. A way to make the code behaving as one would expect is to add a fprintf call before closing descriptor. It then behaves as expected with both libCs. -- System Information: Debian Release: 10.7 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) Versions of packages libc6-dev depends on: ii libc-dev-bin 2.28-10 ii libc6 2.28-10 ii linux-libc-dev 4.19.160-2 libc6-dev recommends no packages. Versions of packages libc6-dev suggests: pn glibc-doc <none> ii manpages-dev 4.16-2 -- no debconf information
--- End Message ---
--- Begin Message ---On 2021-02-07 12:16, Florian Weimer wrote: > * Morel Bérenger: > > >> * Bérenger: > > ... > >> Why do you think this is a bug? > > > > POSIX 10031-2017 standard says: > > POSIX requires that if you manipulate the underlying file descriptor > of a stream, you first need to call fseek when using the stream again. > Your example code does not do that, so it's not following POSIX > requirements for these interfaces. > > But there's another reason why POSIX requirements are met by the glibc > implemetnation. > > > In the error section, we can read that it can return the same errors > > (in errno) as fputc, which itself says, as for errors: > > > >> [EBADF] The file descriptor underlying stream is not a valid file > >> descriptor open for writing. > > The error is conditional: > > | The fputc() function shall fail if either the stream is unbuffered > | or the stream's buffer needs to be flushed, and: […] > > As I explained, the stream is buffered because it is not connected to > a terminal. > As explained by Florian, this is not a bug. I am therefore closing it. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://www.aurel32.net
--- End Message ---
