bagpiper@oxy.UUCP (10/02/87)
In article <2853@husc6.UUCP>,ddl@husc6.UUCP (Dan Lanciani) >In article <173@westmark.UUCP>, dave@westmark.UUCP (Dave Levenson) writes: >| In article <1576@dicome.UUCP>, stryker@dicome.UUCP (don Stryker) writes: >| >| > I've run up against a disturbing feature of the Microsoft C compiler >| > for the PC. Microsoft limits an applicaton to 20 open files, 5 of >| > which are taken up by the standard file handles. I can open my files >| > using DOS system calls to bypass the compiler, ... >| >| This limit is imposed by MS-DOS itself, not by the C compiler. > > Unfortunately, the limit is also imposed by the C library >which maintains its own table of open file descriptors. This table >contains information about the binary/text mode of the file and >whether it is open (don't know why they really need the second). >(This is for MSC 4.0.) > > > Dan Lanciani > ddl@harvard.* ahhhh...I had a problem the other day the I think may have something to do with this. The following piece of code will clarify: #include <stdio.h> main() { FILE *otherptr ; fprintf(stdprn,"This goes to the system printer!!") ; otherptr = strprn ; fprintf(otherptr,"And so does this...(on the same line even)\n") ; fclose(otherptr) ; fprintf(stdprn,"But this doesn't....???????\n") ; } BTW, this was using IBM C 1.0 (can anybody tell me roughly what MSC version this is??). fclose seems to have a FILE * linked in some manner with the corresponding system file handle. When you have two pointers sharing a handle (as seems to happen in this case), fclose seems to close out both the system handle as well as the FILE *. Not the question is: Does this make sense? I have been able to convince my self both ways. Anybody got a good argument!! Michael Hunter UUCP : ....{seismo, rutgers, ames}!cit-vax!oxy!bagpiper Box 241 ARPA : oxy!bagpiper@csvax.caltech.edu Occidental College BITNET: oxy!bagpiper@hamlet.bitnet Los Angeles, CA 90041 CSNET : oxy!bagpiper%csvax.caltech.edu@relay.cs.net
rwhite@nusdhub.UUCP (Robert C. White Jr.) (10/04/87)
In article <2.bagpiper@oxy.uucp>, writes: > fprintf(stdprn,"This goes to the system printer!!") ; > otherptr = strprn ; > fprintf(otherptr,"And so does this...(on the same line even)\n") ; > fclose(otherptr) ; > fprintf(stdprn,"But this doesn't....???????\n") ; > Your problem is very simple. The type of stdprn is a pointer to FILE. You coppied the pointer value from stdprn into otherptr. When you closed otherprinter you were pointing to te same thing as stdprn. Since both of the pointers are identical [and therefore have the same MS-DOS file handle] the single handle was closed. Remember type FILE is a structure one entry of which is the file handle is only one part. This also holds true for any UNIX STREAM. Instead of the asignment you did in the code fragment, you should have either used dup() or dup2() functions so that you had 2 seprate files open to the same device. NOTE: on MS-DOS versions before 3.0 the close will still cause futrue writes to fail [do to an ms-dos bug] because the close routine will still sometimes close both file handles (this from my Microsoft C manual.) The code works correctly for 3.0 ms-dos and above. Robert ("So who asked you anyway?") White.
steve@nuchat.UUCP (Steve Nuchia) (10/05/87)
In article <2.bagpiper@oxy.uucp>, writes: > ahhhh...I had a problem the other day the I think may have something to do > with this. The following piece of code will clarify: > > #include <stdio.h> > main() > { > FILE *otherptr ; > > fprintf(stdprn,"This goes to the system printer!!") ; > otherptr = strprn ; > fprintf(otherptr,"And so does this...(on the same line even)\n") ; > fclose(otherptr) ; > fprintf(stdprn,"But this doesn't....???????\n") ; > } It suprises you that stdprn is closed after you close it? What exactly do you expect that program to do? Lets look at it. You have a local variable of type FILE *. You assign the value stdprn to it. Then you pass that value (ie, stdprn) to fclose. Now, what would you expect to happen if you had said: fclose ( stdout ); fprintf ( stdout, "help, I can't talk anymore!\n" ); I would expect it to not be able to talk and thus it would say nothing. Now, recalling that this is C and not some hypothetical language we are discussing, how is fclose supposed to know the difference between fclose ( stdprn ); and foo = stdprn; fclose ( foo ); ????????? ***** SPOILER WARNING ***** It isn't. -- Steve Nuchia | [...] but the machine would probably be allowed no mercy. uunet!nuchat!steve | In other words then, if a machine is expected to be (713) 334 6720 | infallible, it cannot be intelligent. - Alan Turing, 1947