rwwetmore@grand.waterloo.edu (Ross Wetmore) (07/08/88)
In article <1033@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: >In article <3222@bigtex.uucp>, james@bigtex.uucp (James Van Artsdalen) writes: >> IN article <701@nod2sco>, rosso@sco.COM (Ross Oliver) wrote: >>> - Don't use "0" to mean NULL ( i.e. (char *)0 ). >> This last statement is incorrect, or rather, evidence of a broken >> compiler. >He's speaking in the context of a function call. Large model 286 >programs have 32 bit pointers but 16 bit integers, so if you pass >0 to a function expecting a pointer the stack will be off by two >bytes. And large model '386 programs have 48 bit pointers and 32 bit ints ... >So, the problem isn't a broken compiler, it's a broken CPU architecture. >-- `-_-' Peter (have you hugged your wolf today) da Silva. >-- U Ferranti International Controls Corporation. The assumption that pointers and ints are of equal length is the problem, no? This is a fundamental assumption of the 'C' language, if not an explicit requirement. It would be unfair to fault either the architecture, or compiler in this case. It just means the 'C' language was designed for a certain class of hardware and thus has limited use in its pristine (unkludged) form. Ross W. Wetmore | rwwetmore@water.NetNorth University of Waterloo | rwwetmore@math.Uwaterloo.ca Waterloo, Ontario N2L 3G1 | {uunet, ubc-vision, utcsri} (519) 885-1211 ext 3491 | !watmath!rwwetmore
" Maynard) (07/10/88)
In article <19789@watmath.waterloo.edu> rwwetmore@math.Uwaterloo.ca (Ross Wetmore) writes: > The assumption that pointers and ints are of equal length is the >problem, no? This is a fundamental assumption of the 'C' language, >if not an explicit requirement. NO!!!!! Before I let the wizards in comp.lang.c (Doug Gwyn, Chris Torek, Karl Heuer, and Henry Spencer come immediately to mind) shred this statement, I'll point a flame at it: C does NOT require that pointers and integers be interchangeable. Any attempt to do so is inherently non-portable. That some folks (most notably, those from the school of "All the world's a VAX running BSD") get away with that is a crying shame, for it makes the rest of us have innumerable problems attempting to port their code. > It would be unfair to fault either the architecture, or compiler in >this case. It just means the 'C' language was designed for a certain >class of hardware and thus has limited use in its pristine (unkludged) >form. You're right; the real blame lies with the (incompetent) programmer. Both the language and the architecture do their job just fine, thank you. (Note to Peter: Me, defending C??!?!!) -- Jay Maynard, EMT-P, K5ZC...>splut!< | Never ascribe to malice that which can uucp: uunet!nuchat! | adequately be explained by stupidity. hoptoad!academ!uhnix1!splut!jay +---------------------------------------- {killer,bellcore}!tness1! | Birthright Party '88: let's get spaced!
peter@ficc.UUCP (Peter da Silva) (07/12/88)
In article ... rwwetmore@grand.waterloo.edu (Ross Wetmore) writes: > In article <1033@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: > >In article ... james@bigtex.uucp (James Van Artsdalen) writes: [ the statement "Don't use 0 to mean NULL" is evidence of a broken compiler ] > >He's speaking in the context of a function call. Large model 286 > >programs have 32 bit pointers but 16 bit integers, so if you pass > >0 to a function expecting a pointer the stack will be off by two > >bytes. > And large model '386 programs have 48 bit pointers and 32 bit ints ... Large model '386 programs? Whatever for? By the time you need that much address space the '386 will long be history. I should hope that the 586 (or whatever you call it in that day) will have 64-bit registers. > >So, the problem isn't a broken compiler, it's a broken CPU architecture. > The assumption that pointers and ints are of equal length is the > problem, no? This is a fundamental assumption of the 'C' language, > if not an explicit requirement. No, the aspect of the '386 that's broken is the fact that the address space is not contiguous. This is a problem with any language. I guess I wasn't too precise about this. Anyway... If you want to pass NULL to a function, cast it to the right pointer type until such time as you have an ANSI conformant compiler and this last major hole in the typing structure of the language is closed. [ 'C' is pretty useless in it's unkludged form ] I really don't think you meant to imply that function prototypes are a kludge, right? -- -- `-_-' Peter (have you hugged your wolf today) da Silva. -- U Ferranti International Controls Corporation. -- Phone: 713-274-5180. CI$: 70216,1076. ICBM: 29 37 N / 95 36 W. -- UUCP: {uunet,academ!uhnix1,bellcore!tness1}!sugar!ficc!peter.
peter@ficc.UUCP (Peter da Silva) (07/12/88)
In article <1061@ficc.UUCP>, I said... > No, the aspect of the '386 that's broken is the fact that the address > space is not contiguous. Of course, I meant the '286. The '386 is the first decent processor intel's come out with since the 8085. -- -- `-_-' Peter (have you hugged your wolf today) da Silva. -- U Ferranti International Controls Corporation. -- Phone: 713-274-5180. CI$: 70216,1076. ICBM: 29 37 N / 95 36 W. -- UUCP: {uunet,academ!uhnix1,bellcore!tness1}!sugar!ficc!peter.