Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.lang.c
Subject: Re: Missing stdio features.
Message-ID: <6418@sun.uucp>
Date: Thu, 21-Aug-86 15:03:29 EDT
Article-I.D.: sun.6418
Posted: Thu Aug 21 15:03:29 1986
Date-Received: Thu, 21-Aug-86 22:25:00 EDT
References: <2340@robin.cs.nott.ac.uk> <7003@utzoo.UUCP> <479@mcgill-vision.UUCP> <3438@robin.cs.nott.ac.uk>
Organization: Sun Microsystems, Inc.
Lines: 43

> >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.

It might be useful for I/O on "streams" that aren't implemented by a file or
a string.  I suspect somebody out there has wanted such a beast (for
instance, one might use it with the 4.2BSD "syslog" facility, so that each
line written to the stream was logged.

> >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).

It looks straightforward to implement IF you have the 4BSD version of
standard I/O, where there's a "this is a string" flag for each FILE
structure.  The S5 version, unfortunately, has only a "char" for the flags,
not a "short", so it says that the "last" FILE entry, and only that entry,
is a stream.  If AT&T-IS is willing to put up with the terrifying
possibility of forcing people to delete *object* files and recompile them
for S5R4 (not *executable images*, they'll work fine as long as they don't
use shared libraries; if you can control which version of a shared library
you bind to, you can even make images built against shared libraries work),
they can do this too.  (Which way did V7 do this?)

Given "fopenstr" you can actually provide a version of "sprintf" that
performs *bounds checking* on the string it's printing into.  (Wow, what a
unique concept, software that doesn't scribble its data space when a user
types in a string longer than it expected!)

> 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.

That name might imply that the "fd" gets "close"d.  "unfdopen" is,
admittedly, a bit awkward.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)