dan@kfw.COM (Dan Mick) (05/02/90)
In article <558@venice.SEDD.TRW.COM> waldorf@venice.sedd.trw.com (Jerry Waldorf) writes: > >In the file /usr/include/stdio.h on a BSD box, there is a defined: > >#define _IOSTRG 0100 > >What exactly is this used for? It's part of that strange hack to get sprintf and sscanf to work sort of the same way (f)printf and (f)scanf do. The routines invent a FILE structure, call common routines with that FILE structure's address, and set _IOSTRG in the flags field to get some special-casing in the common routines. > What is the equivalent on SYSV machines? I hope to God there isn't one.
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/02/90)
In article <558@venice.SEDD.TRW.COM> waldorf@venice.sedd.trw.com (Jerry Waldorf) writes: > In the file /usr/include/stdio.h on a BSD box, there is a defined: >#define _IOSTRG 0100 > What exactly is this used for? What is the equivalent on SYSV machines? It's a flag bit used internally by sprintf() and sscanf(), in a FILE structure that they own, to indicate that I/O is from/to a memory buffer, instead of the usual file descriptor in a user-supplied FILE structure. UNIX System V often uses a totally different kludge for this; in Release 2 it was to reserve the last _iob[] member for this purpose. Better approaches are possible.
guy@auspex.auspex.com (Guy Harris) (05/03/90)
>> What is the equivalent on SYSV machines? > >I hope to God there isn't one. Uhh, System V's hack is worse; it sets the file descriptor number for a "this is really a string" stream to _NFILE, and it *does* do some special-casing in "_doscan". The problem with this is that it *hard-codes* the idea that _NFILE is the number of file descriptors into standard I/O, which sucks because the maximum number of file descriptors is tunable in later S5 releases. Choosing some far out-of-range value such as 255 on unsigned-char machines and -1 on signed-char machines would have been preferable.... (Yes, I know that S5's standard I/O has a fixed number of "_iob" entries, and thus couldn't use the extra descriptors anyway. This is *not* a valid excuse; 4.3BSD's standard I/O dynamically allocates the "_iob" stuff, and those techniques could be applied to S5's as well - definitely so if binary compatibility isn't a concern, and it may be possible even if it *is* a concern.)
chris@mimsy.umd.edu (Chris Torek) (05/05/90)
In article <558@venice.SEDD.TRW.COM> waldorf@venice.SEDD.TRW.COM (Jerry Waldorf) writes: >In the file /usr/include/stdio.h on a BSD box, there is a defined: >#define _IOSTRG 0100 >What exactly is this used for? Almost nothing. It is set in exactly two places (sprintf and sscanf) and tested in one (_filbuf). In particular, it is not tested in _flsbuf, so that char dst[32800], src[32768]; int i; for (i=0; i<32767; i++) src[i] = 'x'; src[32767] = 0; sprintf(dst, "too much: %s", src); calls write() on a random file descriptor. All _IOSTRG really does is keep _filbuf() from reading from a random file descriptor. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris