cramer@optilink.UUCP (Clayton Cramer) (08/06/88)
I was trying to reduce memory requirements, so I cut BUFFERS and FILES
in CONFIG.SYS back to 10, and tried to recompile. The compiler started
to give me a message which is not in the 5.0, or the 5.1 update:
C1015:
Yup! That's it! No message -- just a number. I finally figured out
that it was telling me there weren't enough FILES in CONFIG.SYS because
C1014 is "too many include files" "Nesting of #include directives
exceeds 10 levels" and the complaints were usually the fifth or sixth
#include in a source file.
Clayton E. Cramerevas@euraiv1.UUCP (Eelco van Asperen) (08/07/88)
in article <335@optilink.UUCP>, cramer@optilink.UUCP (Clayton Cramer) says: > I was trying to reduce memory requirements, so I cut BUFFERS and FILES > in CONFIG.SYS back to 10, and tried to recompile. The compiler started > to give me a message which is not in the 5.0, or the 5.1 update: > > C1015: > > Yup! That's it! No message -- just a number. This is perfectly sensible behaviour; MSC stores it's error messages in files named C1.ERR, C23.ERR and CL.ERR. So, to display the message that belongs to error C1015 ("cannot open include file '%s'"), MSC has to open the file C1.ERR, which fails because there are no more file-handles available. This is for MSC 5.1. [more inews-filler....] -- Eelco van Asperen. uucp: evas@eurtrx / mcvax!eurtrx!evas #include <inews/filler.h> earn/bitnet: asperen@hroeur5 #include <stdjunk.h> "We'ld like to know a little bit about you for our files" - Mrs.Robinson, Simon & Garfunkel
blair@enint.Wichita.NCR.COM (Brian Lair) (08/08/88)
In article <769@euraiv1.UUCP>, evas@euraiv1.UUCP (Eelco van Asperen) writes: > in article <335@optilink.UUCP>, cramer@optilink.UUCP (Clayton Cramer) says: >> C1015: >> Yup! That's it! No message -- just a number. > > This is perfectly sensible behaviour; [...cause description deleted...] Explainable, perhaps, but not sensible. -- Brian R. Lair NCR Corporation, E&M Wichita, Advanced Development Brian.Lair@Wichita.NCR.COM {ece-csc,hubcap,gould,rtech}!ncrcae!ncrwic!Brian.Lair {sdcsvax,cbatt,dcdwest,nosc.ARPA,ihnp4}!ncr-sd!ncrwic!Brian.Lair
ddb@ns.UUCP (David Dyer-Bennet) (08/09/88)
In article <769@euraiv1.UUCP>, evas@euraiv1.UUCP (Eelco van Asperen) writes: > in article <335@optilink.UUCP>, cramer@optilink.UUCP (Clayton Cramer) says: > > C1015: > > Yup! That's it! No message -- just a number. > This is perfectly sensible behaviour; I have to disagree. It may be _inevitable_ behavior given, as you say, that msc stores the text of error messages in external files, and couldn't get at them because the error message was due to running out of open file slots; but I can't bring myself to call it sensible! Actually, I think that the error messages for things precluding openning the error message files should be hardcoded, to prevent precisely this situation. Yes, I realize that that makes them come out in the wrong language in most countries in the world, but that's better than nothing. Also, I believe the original post said that C1015 wasn't listed in the manual, which is an apalling botch. -- -- David Dyer-Bennet ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb Fidonet 1:282/341.0, (612) 721-8967 hst/2400/1200/300
neals@tekigm2.TEK.COM (Neal Sedell) (08/09/88)
In article <769@euraiv1.UUCP> evas@euraiv1.UUCP (Eelco van Asperen) writes: >in article <335@optilink.UUCP>, cramer@optilink.UUCP (Clayton Cramer) says: >> I was trying to reduce memory requirements, so I cut BUFFERS and FILES >> in CONFIG.SYS back to 10, and tried to recompile. The compiler started >> to give me a message which is not in the 5.0, or the 5.1 update: >> >> C1015: >> >> Yup! That's it! No message -- just a number. > >This is perfectly sensible behaviour; MSC stores it's error messages >in files named C1.ERR, C23.ERR and CL.ERR. So, to display the message Yes, it's prefectly sensible if you're complier doesn't have enough sense to close the files that it opened. Seems like the first thing it would do would be to close all the opened files... x x x x x x x x x x x x x -- Neal Sedell
nwd@j.cc.purdue.edu (Daniel Lawrence) (08/09/88)
> in article <335@optilink.UUCP>, cramer@optilink.UUCP (Clayton Cramer) says: > > C1015: > > Yup! That's it! No message -- just a number. > This is perfectly sensible behaviour; If MSC opened its error message file FIRST.. this would not be able to happen. Errors are something that can occur at any time in a program... and MSC should make sure it can report them properly at any time. Messages could also be hard coded without an error file by using a header file with definitions for the messages (which could be changed for different languages). Daniel Lawrence (317) 742-5153 UUCP: {ihnp4!pur-ee!}j.cc.purdue.edu!nwd ARPA: nwd@j.cc.purdue.edu FIDO: 1:201/2 The Programmer's Room (317) 742-5533
ado@elsie.UUCP (Arthur David Olson) (08/15/88)
A solution is to open the error message file early in the game, to ensure that exhaustion of descriptors won't preclude opening it late it the game. -- ado@ncifcrf.gov ADO is a trademark of Ampex.