Re: gdb not catching out-of-bounds pointer

Rainer Weikusat <rweikusat@xxxxxxxxxxx> writes:

Ben Bacarisse <ben.usenet@xxxxxxxxx> writes:
Techniques that break ABI compatibility would be out, yes, but code
that, for example, accesses one array from a pointer to another is
already broken to some extent.
<snip>
Such code is not written in strictly conforming C. It is nevertheless
extremly common whenever actual memory management is involved. This
implies that any malloc implementation not written in assembly
would then be 'broken to some extent', the same being true for all
operating systems kernels and parts thereof, specifically, device
drivers, as well. And this isn't even a real escape route because
combining object code files generated from different source language
is also not defined by the C-standard, IOW: writing code in anything
but assembly is 'broken to some extent'.

You obviously don't like my choice of words and I agree that is was
not ideal. It might have been better to say something like
"worryingly familiar with the implementation". Code inside malloc
*is* the implementation, so any degree of familiarity is fine --
provided the library writer knows what the compiler writer guarantees
about undefined code. In other words, how much you worry about this
familiarity depends on who you are and what sort of code you are
writing.

Writing a portable allocator would require more strict adherence to
the standard unless a particular compiler (with extra assurances)
could be assumed. But not all undefined behaviour is equal. For
example, I would worry much less about comparing void *s (with >, >=
etc.) that don't point into the same array than I would about the sort
of pointer aliasing issue that started this sub-thread. I don't know
of any compiler that makes dangerous assumptions about the former, but
I do know some that do about the latter.

--
Ben.
.

Relevant Pages

  • Re: Need help to port VAX code to Alpha and to Itaninum
    ... Not really, the original code was wrong, and the compiler was not ... pointer to the start of the array. ... So you are trying to pass a pointer to a pointer to an array where you ... Also start looking at where you can add the "const" modifier to function ...
    (comp.os.vms)
  • Re: decrement past beginning is valid?
    ... > What I meant by legal is that a compiler will compile it. ... > that an array is the same as a pointer. ... behave the same way on all platforms. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: lockless file descriptor lookup
    ... It isn't clear whether you want to refresh the fd_ofiles pointer to the ... the array, or the fd'th element. ... This is actually intended to catch cases where the descriptor array has expanded and the pointer to fd_ofiles has changed, or the file has been closed and the pointer at the fd'th element has changed. ... I'm attempting to force the compiler to reload the fd_ofiles array pointer from the fdp structure. ...
    (freebsd-arch)
  • Re: null terminated strings
    ... pointer + 1 will point to the next element in the array. ... What I don't understand is why such a thing was included in any language that's more than an assembler. ... of structures that are not 'natural' the compiler need to generate ADD instructions using sizeof. ...
    (comp.os.vms)
  • Re: Answer needed
    ... as the last element of the array the data was written outside the allotted ... I re-wrote the offending function with proper checks of the pointer value. ... > including what you expect writing code to see what the result will be ...
    (alt.comp.lang.learn.c-cpp)