mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Markus Wichmann <>
Subject: Re: [musl] What if the line in /proc/mounts is too long when calling getmntent_r?
Date: Sat, 28 Aug 2021 08:17:08 +0200	[thread overview]
Message-ID: <20210828061708.GA3090@voyager> (raw)
In-Reply-To: <CDUT4S6JD78D.MIJNK22HIE4B@mussels>

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.


  reply	other threads:[~2021-08-28  6:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-27 13:26 Érico Nogueira
2021-08-27 13:43 ` Rich Felker
2021-08-28  2:58   ` Érico Nogueira
2021-08-28  6:17     ` Markus Wichmann [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-08-27  4:48 care
2021-08-27 13:05 ` Érico Nogueira

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:

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

  git send-email \
    --in-reply-to=20210828061708.GA3090@voyager \ \ \

* 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.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).