Date: Thu, 4 Aug 2022 16:23:22 +0200 From: Markus Wichmann <nullplan@....net> To: musl@...ts.openwall.com Cc: Sascha Brawer <sascha@...wer.ch> Subject: Re: Should fdopen() check the passed file descriptor? On Thu, Aug 04, 2022 at 02:42:49PM +0200, Sascha Brawer wrote: > Dear list > > Should musl’s fdopen() verify whether the passed file descriptor refers to > an open file? > It should not. Normal musl policy for "may fail" is to just not check that. musl only implements "shall fail". In this case, using numbers that are not FDs as such is really really bad. It means the control flow is utterly br0ken. How did the program even get into a state in which a variable is supposed to be holding an FD but doesn't? It betrays a really big problem with the program if this can happen. If the program is multi-threaded (or opens files from a signal handler, which can happen since open(2) is async-signal-safe), the program might suddenly start using a file descriptor wrong. That would be an interesting problem to debug. In short, any program calling fdopen() with a number that is not guaranteed to be an open file has a logic error that needs to be fixed post-haste. Returning EBADF is really only plastering over the problem. It would be like dereferencing a pointer fresh out of malloc() and catching the SIGSEGV instead of just testing whether the pointer is 0. Ciao, Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.