public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Sam James <sam@gentoo.org>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH 2/5] fuse2fs: stop aliasing stderr with ff->err_fp
Date: Sun, 20 Jul 2025 22:42:34 -0700	[thread overview]
Message-ID: <20250721054234.GN2672022@frogsfrogsfrogs> (raw)
In-Reply-To: <20250720185135.GS2672070@frogsfrogsfrogs>

On Sun, Jul 20, 2025 at 11:51:35AM -0700, Darrick J. Wong wrote:
> On Sun, Jul 20, 2025 at 09:27:41AM +0100, Sam James wrote:
> > This seems to have introduced https://github.com/tytso/e2fsprogs/issues/235.
> 
> Heh, section 7.23.1 paragraph 4 of the latest C2y draft says that
> stdin/stdout/stderr “are expressions of type "pointer to FILE" that
> point to the FILE objects associated, respectively, with the standard
> error, input, and output streams.”
> 
> The use of "expression" should have been the warning sign that a symbol
> that can be mostly used as a pointer is not simply a pointer.
> 
> Later in footnote 318, they say [stdin/stdout/stderr] “need not be
> modifiable lvalues to which the value returned by the fopen function
> could be assigned.”
> 
> "need not be" is the magic phrasing that means musl and glibc are both
> following the spec.  IOWs, every C programmer should reduce the amount
> of brainpower they spend on their program's core algorithm so that they
> can all be really smart about this quirk.
> 
> So yeah, you're right.
> 
> But we could also do:
> 
> 	fd = open(logfile, O_WRONLY | O_CREAT | O_APPEND, 0666);
> 	dup2(fd, STDOUT_FILENO);
> 	dup2(fd, STDERR_FILENO);
> 
> and skip all this standards-worrying.  I would have just done that, but
> for fear that somewhere there might be a library that actually *does* do
> freopen and this trick won't work.
> 
> Yaaay, it's 2025 and we all still suuuuuuuck.

Oh wait no it turns out that libfuse obliterates std{in,out,err} in
fuse_daemonize() by opening /dev/null and using that exact trick.  So
the only reason why I was ever getting any FUSE2FS debug output
throughout *any* of the fuse+iomap development sprints was that glibc
lets you assign stdout/stderr directly.

freopen also won't work (at least on glibc) because its freopen
implementation uses the dup2 trick which will be undone by libfuse.

GREAT!  I only got to debug my program because OF A WEIRD GLIBC QUIRK!!

So the only way to actually fix this is to open whatever logging file we
want to use, and explicitly pass that around to every function that
wants to log a message or an error, because the libraries can't be
trusted not to fsck it all up.  libext2fs has a callback for any errors
that it wants to print, and that will have to do.

--D

  reply	other threads:[~2025-07-21  5:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-24 21:38 [PATCHSET 1/5] fuse2fs: better logging Darrick J. Wong
2025-04-24 21:38 ` [PATCH 1/5] fuse2fs: enable runtime debugging Darrick J. Wong
2025-04-24 21:39 ` [PATCH 2/5] fuse2fs: stop aliasing stderr with ff->err_fp Darrick J. Wong
2025-07-20  8:27   ` Sam James
2025-07-20 18:51     ` Darrick J. Wong
2025-07-21  5:42       ` Darrick J. Wong [this message]
2025-07-21 11:41         ` Theodore Ts'o
2025-07-21 17:01           ` Darrick J. Wong
2025-04-24 21:39 ` [PATCH 3/5] fuse2fs: use error logging macro for mount errors Darrick J. Wong
2025-04-24 21:39 ` [PATCH 4/5] fuse2fs: make other logging consistent Darrick J. Wong
2025-04-24 21:40 ` [PATCH 5/5] fuse2fs: redirect all messages when FUSE2FS_LOGFILE is set Darrick J. Wong
2025-05-21 14:51 ` [PATCHSET 1/5] fuse2fs: better logging Theodore Ts'o

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250721054234.GN2672022@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sam@gentoo.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox