Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!ukc!dcl-cs!nott-cs!jpo
From: jpo@cs.nott.ac.uk (Julian Onions)
Newsgroups: net.lang.c
Subject: Re: Missing stdio features.
Message-ID: <3438@robin.cs.nott.ac.uk>
Date: Mon, 18-Aug-86 06:40:47 EDT
Article-I.D.: robin.3438
Posted: Mon Aug 18 06:40:47 1986
Date-Received: Thu, 21-Aug-86 01:20:21 EDT
References: <2340@robin.cs.nott.ac.uk> <7003@utzoo.UUCP> <479@mcgill-vision.UUCP>
Reply-To: jpo@cs.nott.ac.uk (Julian Onions)
Organization: Computer Science, Nottingham Univ., UK.
Lines: 67
Keywords: stdio, buffering

In article <479@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP writes:
>> Addition:	fpending(fp)
>(Henry Spencer comments that "the right solution to that is fselect(),
>not fpending().".  I disagree; suppose you want to select on a FILE*
>and on a file descriptor both?  How do you tell the difference?

OK, I'm greedy, I want both. fpending(fp) I wanted after some code
that checked the input for pending characters using FIONREAD.
fselect is rather involved requiring several lines of code,
fpending comes out as something like
#define fpending(fp) ((fp)->_cnt)
Give either fpending or fselect the other can be built and fpending seems
simplest, but maybe not the answer to the right question.
All in all, fselect is the right way to go (stdio features tracking
system calls), but fpending is so trivial it might as well be thrown in.

>> Addition:	fbufsiz(fp), fbuftype(fp)
>Never wanted 'em.
Neither have I, but for the sake of consistency it'd be nice to tell
what buffering is set as well as being able to set buffering.

>Here are the things I have wanted badly enough to add to stdio:
>FILE *fopenfxn(int (*fxn)(), char *mode)
>	Function-stream I/O.
Can't say I've ever thought about this one. I'm not sure when you'd
use it either.

>FILE *fopenstr(char *str, int len, char *mode)
>	An extension to sprintf() and sscanf().  This returns a stream
>	which performs I/O to a string (this makes sprintf() and
>	sscanf() unnecessay, though they are still convenient).
I like this one, C++ has something like this in its streams stuff,
and I liked the idea there. Being able to treat incore strings and
files the same seems a good idea.
e.g.
	if(argc>1)
		if(( fp = fopen(argv[1], "r")) == NULL)
			process(fp = fopenstr(argv[1], strlen(argv[1]), "r"));
		else	process(fp);
	else
		process(fp = stdin);
	fclose(fp);

>unfdopen(FILE *f)
>	Undoes fdopen(), that is, closes the FILE* without close()ing
>	the underlying file descriptor.
Yes, I'd thought of that, however as you say its trivial and can be
done reasonably portably e.g.
unfdopen(fp)
FILE *fp;
{	int oldf, tmpf;
	tmpf = dup(oldf = fileno(fp));
	fclose(fp);
	return dup2(tmpf, oldf);
}
Seems like a good idea. When you've finished playing around with
fprintf's etc. and just want the file descriptor for locking or
some other nefarious process and not all the expensive buffering space.
I'd prefer fdclose as the name though.

Julian.

jpo@cs.nott.ac.uk
jpo%cs.nott.ac.uk@ucl-cs.arpa
mcvax!ukc!nott-cs!jpo
-- 
Julian Onions