Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: _IOSTRG in stdio.h
Message-ID: <1353@mcgill-vision.UUCP>
Date: 15 Nov 88 10:12:36 GMT
References: <1004@cps3xx.UUCP> <14413@mimsy.UUCP>
Distribution: na
Organization: McGill University, Montreal
Lines: 42

In article <14413@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> In article <1004@cps3xx.UUCP> usenet@cps3xx.UUCP (Usenet file owner) writes:
>> Could someone tell me what the _IOSTRG parameter in stdio.h on BSD
>> controls?
> Absolutely nothing.  It is never tested.  You can expect it to vanish
> in the future.

[Reality check time: I'm about to disagree with Chris.]

From flsbuf.c:
	fclose(iop)
		register FILE *iop;
	{
....
		if (iop->_flag&(_IOREAD|_IOWRT|_IORW) && (iop->_flag&_IOSTRG)==0) {

From filbuf.c:
	_filbuf(iop)
	register FILE *iop;
	{
....
		if (iop->_flag&(_IOSTRG|_IOEOF))

(And yes, Chris, this is the distribution stdio, not my stdio.)

To answer what the original poster probably wanted to know, _IOSTRG
indicates that the stream is a fake stream for I/O to a string: sprintf
or sscanf.  As for what it actually *controls*, Chris is almost
correct; I think _doprnt doesn't check this flag at all [VAX version],
and (bug alert!) neither does _flsbuf.  If you sprintf more than 32K,
sprintf will make mistakes.  Initially, the mistakes are (relatively)
benign (the sprintffed output past 32K gets stuffed in malloc()ed
memory which is then lost), but if you push it to 40K, it will start
flushing stuff to a random file descriptor ("random" = "stack trash"),
which in my tests happened to be 0, the standard input.  Examination of
the code indicates that potential exists for it to drop core if it gets
the wrong stack trash.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu