Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: C90 fpeek
Date: Fri, 24 Jan 2025 16:49:54 +0200
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <20250124164954.00007935@yahoo.com>
References: <vmv082$1u6pm$1@dont-email.me>
	<87plkc6bgm.fsf@nosuchdomain.example.com>
	<vn07r3$28bkd$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 24 Jan 2025 15:49:58 +0100 (CET)
Injection-Info: dont-email.me; posting-host="1a3bf6e0363845c200608d71f04f46bf";
	logging-data="2334323"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+OpRHfV7Q8TjTfB8GTPEKMHWVwcPyrd5g="
Cancel-Lock: sha1:OvZ+wh5l6FHGgiXxPEeAoLvpB7Y=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 2343

On Fri, 24 Jan 2025 09:24:35 -0500
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

> On 1/24/25 00:13, Keith Thompson wrote:
> > "Paul Edwards" <mutazilah@gmail.com> writes:
> > [...]  
> >> With the benefit of hindsight, is there any reason why fpeek
> >> couldn't have been added to C90, with implementations
> >> being allowed with just a macro that returns some sort of
> >> "unsupported"?
> >>
> >> If fpeek (or similar) makes sense, can someone suggest an
> >> appropriate interface?  
> > [...]
> > 
> > It would help to know what "fpeek" is supposed to do.  There no such
> > function in any edition of the C standard or in any implementation
> > that I'm aware of.  
> 
> A google search uncovered a stackoverflow question for which the
> answer was:
> 
> int fpeek(FILE *stream)
> {
>     int c;
> 
>     c = fgetc(stream);
>     ungetc(c, stream);
> 
>     return c;
> }
> 
> I don't see any reason why such a function is needed in the standard
> library. However, if it were added, since fgetc() and ungetc() are
> mandatory for hosted implementations, I also see no reason to allow
> for it to be unsupported.

It can be supported, but not useful for OP's purouses without ability
to set file to O_NONBLOCK. Which, I would think, is outside of C
standard.