Darren New <dne### [at] sanrrcom> wrote:
> On 7/23/2011 7:59, Warp wrote:
> >    If you access first and check bounds afterwards, that's kind of a bit
> > late, don't you think?

> In the first example, he reads, then checks, then writes, and it's not 
> unreasonable to think that he's ensuring the write isn't out of bounds 
> because the read is harmless.  (Yes, there are still architectures where 
> *NULL does not trap.)

  But there are many architectures where dereferencing null will trap,
which is why the C standard does not want to force it either way (in
other words, it does not want to force compilers to add a check to each
dereferencing to see if it's dereferencing null, and then either cause
an abort() or some other defined behavior).

  If dereferencing null is normal in a certain architecture, then compilers
made for that architecture should take that into account (which the standard
fully allows, obviously).

  (As always, this is a compromise between efficiency and safety. If the
standard said "thou shalt not dereference null, or you'll be abort()ed",
then every single pointer and array access would become slower.)

> >    Well, if the code is accessing out of boundaries, there's a bug. If there's
> > such a bug, the compiler is free to do whatever it likes. There's nothing
> > surprising about that.

> It is to a large number of people who work with safe languages. :-) Even 
> more surprising to people who work with languages where having an index out 
> of bounds doesn't even make sense, let alone be "a bug".

  Then these people either have to learn C properly, or not use it.
It really is a case of "take it or leave it".

-- 
                                                          - Warp

Post a reply to this message