[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210828061708.GA3090@voyager>
Date: Sat, 28 Aug 2021 08:17:08 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: What if the line in /proc/mounts is too long when calling
getmntent_r?
On Fri, Aug 27, 2021 at 11:58:11PM -0300, Érico Nogueira wrote:
> This is bad, of course, if there are
> folks writing code to call getmntent_r again even after it returns 0 (it
> would be very kooky code, since differentiating between the 0 returns
> sounds complicated to me, unless they used errno==ERANGE as a
> sinalizer); in their case, they expect to receive the next entry, but
> the function would just loop eternally with too short a buffer. This
> corner case feels like it would come from coding to the observed
> behavior rather than any specification, so I don't know if it needs to
> be respected.
>
This type of behavior is also used in other functions. readdir() returns
a NULL pointer at end of directory and on error. And getpriority()
returns -1 on error and if the priority currently actually is -1. So
zeroing out errno and testing it after the call is a normal way to
distinguish error returns and normal returns in some interfaces.
The entire mntent library is non-standard, according to the manpage. So
the only specification that exists is glibc behavior. And it skips over
too long lines. Therefore we will have to do the same. Anyone who wants
something else will have to write their own parser. mntent is not the
most complicated format in the world.
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.
