[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <877d7t5q4e.fsf@oldenburg.str.redhat.com>
Date: Wed, 13 Apr 2022 10:44:49 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Rich Felker <dalias@...c.org>
Cc: libc-coord@...ts.openwall.com
Subject: Re: stdio_ext.h extensions for gnulib
* Rich Felker:
> Early on in musl's history, we added a set of further extensions in
> stdio_ext.h:
>
> size_t __freadahead(FILE *);
> const char *__freadptr(FILE *, size_t *);
> void __freadptrinc(FILE *, size_t);
> void __fseterr(FILE *);
>
> The purpose of these functions was to provide a way for gnulib to do
> the things they already insisted on doing, but without having access
> to the FILE representation internals (which is how they implemented
> these things for every other system at the time).
I assume the first three functions provide access to the read buffer,
and do not perform locking or error checking (that is, incrementing past
the end of the read-ahead value is undefined).
fseterr is the converse of clearerr, and therefore uses locking, right?
> The topic recently came up again via Toybox, where the author is not
> using gnulib but was looking for some of the same functionality. I'm
> told Bionic is on-board with adding these, and it might make sense to
> coordinate this with glibc and other libc implementations/other
> systems, or even propose these as some sort of standard.
For glibc, the read buffer pointers are part of the ABI (even when
ignoring the attempt to share the stream implementation with historic
libstdc++ versions). So we would probably provide inline definitions
(unless they require locking). But adding such functions seems fine to
me.
Thanks,
Florian
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.
