sonenbli@oxy.edu (Andrew D. Sonenblick) (07/05/90)
Yeeeeeeeeehaaaaa! I just solved a problem that's been eatin me for days!! (Maybe now I can make my deadline!!!) Anyway, I won't go into the details of the prol_~?oblem--just the cause in case it happens to you... I simply had an array of booleans like this: Boolean monitor[3]; simple enough. However, in my code I hade this: Boolean someBoolean, anotherBoolean; monitor[3]; AHHHHG! Note that there is a semi-colon after anotherBoolean!! (it's embarrassing to think I was hunting for days to find the root of my problem) Think C (4.00) compiled this with no complaints (don't ask me what it thought monitor[3]; means, I don't know...) so it appears to be a bug. Anywho, my code now works withour error, and the world is a happier place Ando Moon, programmer at large...
austing@Apple.COM (Glenn L. Austin) (07/05/90)
sonenbli@oxy.edu (Andrew D. Sonenblick) writes: >I simply had an array of booleans like this: Boolean monitor[3]; >simple enough. However, in my code I hade this: >Boolean someBoolean, > anotherBoolean; > monitor[3]; >AHHHHG! Note that there is a semi-colon after anotherBoolean!! (it's >embarrassing to think I was hunting for days to find the root of my problem) >Think C (4.00) compiled this with no complaints (don't ask me what it >thought monitor[3]; means, I don't know...) so it appears to be a bug. Probably it thinks that monitor is an array of ints, since untyped variables, parameters, and functions default to int... -- ----------------------------------------------------------------------------- | Glenn L. Austin | "Turn too soon, run out of room, | | Auto Racing Enthusiast and | Turn too late, much better fate" | | Communications Toolbox Hacker | - Jim Russell Racing School Instructors | | Apple Computer, Inc. | "Drive slower, race faster" - D. Waltrip | | Internet: austing@apple.com |-------------------------------------------| | AppleLink: AUSTIN.GLENN | All opinions stated above are mine -- | | Bellnet: (408) 974-0876 | who else would want them? | -----------------------------------------------------------------------------
dce@smsc.sony.com (David Elliott) (07/05/90)
In article <102102@tiger.oxy.edu>, sonenbli@oxy.edu (Andrew D. Sonenblick) writes: |> Boolean someBoolean, |> anotherBoolean; |> monitor[3]; |> Think C (4.00) compiled this with no complaints (don't ask me what it |> thought monitor[3]; means, I don't know...) so it appears to be a bug. The 4.3BSD C compiler and the MIPS C compiler (which is pretty close to ANSI) don't complain about this either. Technically, the default type for any variable is the natural integer data type for the machine: int. This is why you can say things like "register i;" or "unsigned j;" and it knows that you mean "register int" and "unsigned int" and not "register short" or "unsigned long". I personally feel that it should force you to give a type or a modifier, but it's not a bug for it not to. David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "If I had a hat the size of Oklahoma, I'd be a happy person."
jamesth@microsoft.UUCP (James THIELE) (07/06/90)
In article <102102@tiger.oxy.edu> sonenbli@oxy.edu (Andrew D. Sonenblick) writes: |Yeeeeeeeeehaaaaa! I just solved a problem that's been eatin me for days!! |(Maybe now I can make my deadline!!!) Anyway, I won't go into the details |of the prol_~?oblem--just the cause in case it happens to you... | |I simply had an array of booleans like this: Boolean monitor[3]; |simple enough. However, in my code I hade this: | |Boolean someBoolean, | anotherBoolean; | monitor[3]; | |AHHHHG! Note that there is a semi-colon after anotherBoolean!! (it's |embarrassing to think I was hunting for days to find the root of my problem) | |Think C (4.00) compiled this with no complaints (don't ask me what it |thought monitor[3]; means, I don't know...) so it appears to be a bug. If it's like most C compilers, it thinks monitor[3] is an array if ints. To quote "The C Programming Language", Kernighan and Ritchie, First Edition, Appendix A, Section 13 Implicit declarations, "In a declaration inside a function, if a storage class but no type is given, the identifier is assumed to be an int;". Not a bug, unless you consider this language feature to be a bug. :-) | |Anywho, my code now works withour error, and the world is a happier place | |Ando Moon, programmer at large... James Thiele -- microsoft!jamesth
casseres@apple.com (David Casseres) (07/06/90)
In article <1990Jul5.150741.12535@smsc.sony.com> dce@smsc.sony.com (David Elliott) writes: > In article <102102@tiger.oxy.edu>, sonenbli@oxy.edu (Andrew D. > Sonenblick) writes: > |> Boolean someBoolean, > |> anotherBoolean; > |> monitor[3]; > ...Technically, the default type > for any variable is the natural integer data type for the machine: int. > > This is why you can say things like "register i;" or "unsigned j;" > and it knows that you mean "register int" and "unsigned int" and not > "register short" or "unsigned long". Whether you actually DO mean int or not, it "knows" that you do... > I personally feel that it should force you to give a type or a > modifier, but it's not a bug for it not to. Yes. Isn't C a wonderful "language"? Even C++ preserves this kind of wonderful feature. I wish I could have a compiler control of some kind that would turn off all that defaulting; it would be like telling the compiler "When I want something to be an int, I'll tell you so." David Casseres Exclaimer: Hey!
russotto@eng.umd.edu (Matthew T. Russotto) (07/06/90)
In article <55662@microsoft.UUCP> jamesth@microsoft.UUCP (James THIELE) writes: >In article <102102@tiger.oxy.edu> sonenbli@oxy.edu (Andrew D. Sonenblick) writes: >|I simply had an array of booleans like this: Boolean monitor[3]; >|simple enough. However, in my code I hade this: >| >|Boolean someBoolean, >| anotherBoolean; >| monitor[3]; >| >|Think C (4.00) compiled this with no complaints (don't ask me what it >|thought monitor[3]; means, I don't know...) so it appears to be a bug. > >If it's like most C compilers, it thinks monitor[3] is an array if ints. > >To quote "The C Programming Language", Kernighan and Ritchie, First >Edition, Appendix A, Section 13 Implicit declarations, "In a declaration >inside a function, if a storage class but no type is given, the >identifier is assumed to be an int;". > >Not a bug, unless you consider this language feature to be a bug. :-) Actually, whatever that is, it is OUTSIDE a function. Inside a function the statement 'monitor[3]' will be treated as an expression, and the compiler will complain that monitor is undefined. The strange thing is that if monitor[3] IS declared as an array of ints, the code should work-- becuase Boolean is typedefed to short, which in THINK C is the same as int. -- Newsgroups: comp.sys.mac.misc Subject: Re: Expensive doorstops Summary: Expires:
russotto@eng.umd.edu (Matthew T. Russotto) (07/07/90)
In article <9008@goofy.Apple.COM> casseres@apple.com (David Casseres) writes: > >Yes. Isn't C a wonderful "language"? Even C++ preserves this kind of >wonderful feature. I wish I could have a compiler control of some kind >that would turn off all that defaulting; it would be like telling the >compiler "When I want something to be an int, I'll tell you so." Yeah-- how about integerating 'lint' and the compiler (optionally, of course). (Is there a good MPW or standalone 'lint' for the mac?) -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu ][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions? Hey! Bush has NO LIPS!
dce@smsc.sony.com (David Elliott) (07/07/90)
In article <1990Jul6.183526.6460@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes: >Yeah-- how about integerating 'lint' and the compiler (optionally, of course). >(Is there a good MPW or standalone 'lint' for the mac?) Well, in this case it wouldn't make a difference, since lint didn't complain about it. I think that the extra level of type checking that lint gives you is one of the goals of ANSI C. The real problem is often that the more checking you do, the more time it takes, and people really do like faster compilers. -- David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "You know my motto: Forgive and uh... the other thing."
philip@pescadero.Stanford.EDU (Philip Machanick) (07/09/90)
In article <1990Jul7.025556.4968@smsc.sony.com>, dce@smsc.sony.com (David Elliott) writes: > I think that the extra level of type checking that lint gives you > is one of the goals of ANSI C. The real problem is often that the > more checking you do, the more time it takes, and people really do > like faster compilers. And getting the wrong answers quickly? Are C compilers any faster than Pascal compilers of equivalent quality (whatever that means)? If speed is really such a factor, I would think integrating the various phases which are separately implemented in traditional C compliers into one program would probably give a bigger speedup than the time lost to better type checking. For that matter, is proper type checking more expensive than implementing arcane rules for default type conversions? Philip Machanick philip@pescadero.stanford.edu
dce@smsc.sony.com (David Elliott) (07/09/90)
In article <1990Jul8.194321.9582@Neon.Stanford.EDU>, philip@pescadero.Stanford.EDU (Philip Machanick) writes: |> And getting the wrong answers quickly? Are C compilers any faster than |> Pascal compilers of equivalent quality (whatever that means)? If |> speed is really such a factor, I would think integrating the various |> phases which are separately implemented in traditional C compliers |> into one program would probably give a bigger speedup than the time |> lost to better type checking. For that matter, is proper type checking |> more expensive than implementing arcane rules for default type |> conversions? I'm not arguing that adding the checking would be wrong. In fact, I welcome it. Then again, my Mac II is the slowest machine I have to work on, the others being 7-10 times as fast, so it doesn't bother me to have a program take a few seconds longer to compile. On the other hand, and this was my point, there are people who will argue that the checking already exists in the form of lint, which is there when you need it and not there slowing down the compiler when you don't. You argue that one could speed up the compiler to offset the additional cycles used to check for problems, and I agree. Then again, if you add the same speedups to the compiler and don't add the checking, you get a faster compiler. Again, when you need the extra checking, lint is there. Why add it? I do see your point, and I really don't have a problem with adding this kind of checking to the compiler. Then again, the slowest machine I use is a Mac II (everything else is 5-10 times as fast), and I don't do enough development on it to care if it is a little slower. But, there are people out there who want that extra speed. Isn't that one of the reasons that the old LightSpeed C was popular? (Of course, none of this takes into account that the problem that started this whole discussion isn't caught by lint. There are a number of areas in C where lack of strictness gets people into trouble, but that's a language issue.) David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "You know my motto: Forgive and uh... the other thing."