wescott@micky.columbia.ncr.com (Mike Wescott) (02/24/90)
I am trying to port a program. It blows up in fprintf because SysV stdio has the implicit assumption that a given file descriptor will be used by no more than one stdio stream. Which is broken? The program that does: fpin = fdopen(fd,"r"); fpot = fdopen(fd,"w"); Or the stdio that blows up in memcpy() called from doprnt() called by fprintf() in the same program? BTW the "implicit assumption" mentioned above is due to the fact that the array _bufendtab[] is indexed by fp->_file rather than by fp-_iob or built into the FILE structure itself. -- -Mike Wescott mike.wescott@ncrcae.Columbia.NCR.COM
rpw3@rigden.wpd.sgi.com (Rob Warnock) (02/24/90)
In article <2010@sauron.Columbia.NCR.COM> wescott@micky.columbia.ncr.com (Mike Wescott) writes: +--------------- | I am trying to port a program. It blows up in fprintf because SysV stdio | has the implicit assumption that a given file descriptor will be used by | no more than one stdio stream. Which is broken? The program that does: | fpin = fdopen(fd,"r"); | fpot = fdopen(fd,"w"); | Or the stdio that blows up in memcpy() called from doprnt() called by | fprintf() in the same program? +--------------- This is a well-known problem to anyone who has ported any Berkeley networking applications to System V. IMHO, Sys5's broken, but it's that way in all the S5R2's I've seen. (Did it make it into S5R3? Will it still be there in S5R4?) +--------------- | BTW the "implicit assumption" mentioned above is due to the fact that | the array _bufendtab[] is indexed by fp->_file rather than by fp-_iob | or built into the FILE structure itself. +--------------- Your diagnosis is exactly correct. On the other hand, Berkeley Unix stores the bufend pointers in the FILE struct (no problem). By the way, a simple workaround for this problem (*hack* *hack*) is: fpin = fdopen(fd,"r"); fpot = fdopen(dup(fd),"w"); -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311
dold@mitisft.Convergent.COM (Clarence Dold) (02/25/90)
in article <2010@sauron.Columbia.NCR.COM>, wescott@micky.columbia.ncr.com (Mike Wescott) says: > BTW the "implicit assumption" mentioned above is due to the fact that > the array _bufendtab[] is indexed by fp->_file rather than by fp-_iob > or built into the FILE structure itself. This same _bufentab[] problem causes an array of difficulties if the system NFILE is higher than NOFILES for stdio. If there is a mix of open(2) and fopen(3), streams can use a pointer off the end of the array, into some unknown data space. Might work, might not... -- --- Clarence A Dold - dold@tsmiti.Convergent.COM (408) 435-5293 ...pyramid!ctnews!tsmiti!dold FAX (408) 435-3105 P.O.Box 6685, San Jose, CA 95150-6685 MS#10-007
dold@mitisft.Convergent.COM (Clarence Dold) (02/25/90)
in article <2010@sauron.Columbia.NCR.COM>, wescott@micky.columbia.ncr.com (Mike Wescott) says: > I am trying to port a program. It blows up in fprintf because SysV > stdio has the implicit assumption that a given file descriptor will > be used by no more than one stdio stream. > BTW the "implicit assumption" mentioned above is due to the fact that > the array _bufendtab[] is indexed by fp->_file rather than by fp-_iob > or built into the FILE structure itself. From fopen(3) man page: "...input may not be directly followed by output" [later stated vice-versa] "without an intervening fseek or rewind..." which I believe will straighten out the _bufentab[fd] pointer. -- --- Clarence A Dold - dold@tsmiti.Convergent.COM (408) 435-5293 ...pyramid!ctnews!tsmiti!dold FAX (408) 435-3105 P.O.Box 6685, San Jose, CA 95150-6685 MS#10-007
gwyn@smoke.BRL.MIL (Doug Gwyn) (02/25/90)
In article <2010@sauron.Columbia.NCR.COM> wescott@micky.columbia.ncr.com (Mike Wescott) writes:
-Which is broken? The program that does:
- fpin = fdopen(fd,"r");
- fpot = fdopen(fd,"w");
-Or the stdio that blows up in memcpy() called from doprnt() called by
-fprintf() in the same program?
It's hard to say. I don't think it's reasonable for an application
to attempt such a feat, but on the other hand STDIO should behave
sensibly anyway.
-BTW the "implicit assumption" mentioned above is due to the fact that
-the array _bufendtab[] is indexed by fp->_file rather than by fp-_iob
-or built into the FILE structure itself.
I agree that this is a design error that should be fixed.igb@fulcrum.bt.co.uk (Ian G Batten) (02/26/90)
rpw3@rigden.UUCP (Robert P. Warnock) writes: > This is a well-known problem to anyone who has ported any Berkeley networking > applications to System V. IMHO, Sys5's broken, but it's that way in all the > S5R2's I've seen. (Did it make it into S5R3? Will it still be there in S5R4?) Yes. I ported IDA Sendmail to 5.3.2 last week and hit this problem. As previously stated, dup()ing the file descriptor is a cure. ian -- Ian G Batten, BT Fulcrum - igb@fulcrum.bt.co.uk - ...!uunet!ukc!fulcrum!igb
thomas@uplog.se (Thomas Tornblom) (03/01/90)
In article <0S&#P?$@masalla.fulcrum.bt.co.uk> igb@fulcrum.bt.co.uk (Ian G Batten) writes: rpw3@rigden.UUCP (Robert P. Warnock) writes: > This is a well-known problem to anyone who has ported any Berkeley networking > applications to System V. IMHO, Sys5's broken, but it's that way in all the > S5R2's I've seen. (Did it make it into S5R3? Will it still be there in S5R4?) Yes. I ported IDA Sendmail to 5.3.2 last week and hit this problem. As previously stated, dup()ing the file descriptor is a cure. If anyone cares, here is the fix to stdio I made. I also came across the problem while bringing sendmail up. Requires source of course... ----------------------------------------------- There is only 3 files that need a change. /usr/include/stdio.h: Add a new member last to the FILE struct: unsigned char *_bufendp; /* get rid of bufendtab */ redefine the macro _bufend(): #define _bufend(p) ((p)->_bufendp) remove the definition of _bufendtab[] .../src/lib/libc/port/data.c: add a new initializer to the _iob[] struct for stdin, stdout and stderr: FILE _iob[_NFILE] = { { 0, NULL, NULL, _IOREAD, 0, NULL}, { 0, NULL, NULL, _IOWRT, 1, NULL}, { 0, _smbuf[2], _smbuf[2], _IOWRT+_IONBF, 2, _smbuf[2]+_SBFSIZ}, }; remove the declaration of _bufendtab[]; .../src/lib/libc/port/print/doprnt.c There is one place where _bufendtab[fno] is referenced. Change it to _bufend(iop). This can be done without the other changes. Then you have to recompile libc.a of course, but thats another story. Thomas -- Real life: Thomas Tornblom Email: thomas@uplog.se Snail mail: TeleLOGIC Uppsala AB Phone: +46 18 189406 Box 1218 Fax: +46 18 132039 S - 751 42 Uppsala, Sweden
meissner@osf.org (Michael Meissner) (03/02/90)
In article <THOMAS.90Mar1150529@uplog.uplog.se> thomas@uplog.se (Thomas Tornblom) writes: | If anyone cares, here is the fix to stdio I made. I also came across the | problem while bringing sendmail up. | Requires source of course... | ----------------------------------------------- | There is only 3 files that need a change. | /usr/include/stdio.h: | Add a new member last to the FILE struct: | unsigned char *_bufendp; /* get rid of bufendtab */ Be sure to recompile EVERYTHING that may have even remotely refered to stdin, stdout, stderr, putc, putchar, getc, or getchar! -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Catproof is an oxymoron, Childproof is nearly so
thomas@uplog.se (Thomas Tornblom) (03/02/90)
In article <MEISSNER.90Mar1164952@curley.osf.org> meissner@osf.org (Michael Meissner) writes: In article <THOMAS.90Mar1150529@uplog.uplog.se> thomas@uplog.se (Thomas Tornblom) writes: | If anyone cares, here is the fix to stdio I made. I also came across the | problem while bringing sendmail up. | Requires source of course... | ----------------------------------------------- | There is only 3 files that need a change. | /usr/include/stdio.h: | Add a new member last to the FILE struct: | unsigned char *_bufendp; /* get rid of bufendtab */ Be sure to recompile EVERYTHING that may have even remotely refered to stdin, stdout, stderr, putc, putchar, getc, or getchar! Well, already compiled applications that uses these that works need not be recompiled. If you have your makefiles set up properly, i.e. dependent of stdio.h, this wouldn't be a problem. -- Real life: Thomas Tornblom Email: thomas@uplog.se Snail mail: TeleLOGIC Uppsala AB Phone: +46 18 189406 Box 1218 Fax: +46 18 132039 S - 751 42 Uppsala, Sweden
gwyn@smoke.BRL.MIL (Doug Gwyn) (03/03/90)
In article <THOMAS.90Mar2083853@uplog.uplog.se> thomas@uplog.se (Thomas Tornblom) writes: >Well, already compiled applications that uses these that works need not >be recompiled. Yes they do. The _iob array element size has changed, so the offsets determined at the last compile are not correct for the new library usage.
jfh@rpp386.cactus.org (John F. Haugh II) (03/05/90)
In article <12270@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <THOMAS.90Mar2083853@uplog.uplog.se> thomas@uplog.se (Thomas Tornblom) writes: >>Well, already compiled applications that uses these that works need not >>be recompiled. > >Yes they do. The _iob array element size has changed, so the offsets >determined at the last compile are not correct for the new library usage. Unless the library is shared or he is planning on re-linking the compiled C files against the new library, there is no need to recompile the program. The code he is executing hasn't been changed by the change in the FILE structure in the new library. It's still as flaky as a pie crust ... -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
thomas@uplog.se (Thomas Tornblom) (03/12/90)
In article <12270@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: In article <THOMAS.90Mar2083853@uplog.uplog.se> thomas@uplog.se (Thomas Tornblom) writes: >Well, already compiled applications that uses these that works need not >be recompiled. Yes they do. The _iob array element size has changed, so the offsets determined at the last compile are not correct for the new library usage. We must have a communications problem here :-) What I meant was that ready-to-run applications still works after the change. After all, we haven't changed the system call interface. Applications still use write(2), wich is completely independent of stdio! Anything dependent on <stdio.h> must have been compiled with the same version. -- Real life: Thomas Tornblom Email: thomas@uplog.se Snail mail: TeleLOGIC Uppsala AB Phone: +46 18 189406 Box 1218 Fax: +46 18 132039 S - 751 42 Uppsala, Sweden