Something's Broken: was ... Re: tgetent

[Peter da Silva]

In article ... rwwetmore at grand.waterloo.edu (Ross Wetmore) writes:
> In article <1033 at ficc.UUCP> peter at ficc.UUCP (Peter da Silva) writes:
> >In article ... james at 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.