Re: [Openexr-devel] Writing a tiled Rgba image file with tiles given

[Florian Kainz]

Hi Kevin,

I would agree with your statement about this being more of a
theoretical concern.  I don't know of any examples where the
pointer arithmetic for addressing pixels in the frame buffer
fails in practice.

As long as a C/C++ program runs in an environment that presents
applications with a linear address space, I don't see what kind
of compiler optimizations could affect the outcome of pointer
arithmetic.  At the machine code level pointers are just unsigned
integers with enough bits to uniquely identify any location in
the address space.  Adding to or subtracting from such an integer
always produces another integer, even though interpreting that
integer as a pointer may not yield the address of a valid object.

With large images it is possible that computing the base pointer
for setFrameBuffer produces a negative address.  However, actual
hardware performs unsigned integer arithmetic modulo 2^32 or 2^64
such that negative addresses wrap around to a large positive ones.
Later, the address calculations during during pixel reads or writes
will wrap around the other way and produce valid pointers to pixels.

It is true that the code relies on properties of pointer arithmetic
that are not guaranteed by the C++ standard.  But then, the
implementation of the "half" data type also relies on features
of the C++ implementation that are not guaranteed by the standard.

The C++ standard states that the results of certain pointer
subtractions and pointer comparisons are "unspecified."
As far as I know there are two reasons for this: first, the
relative memory addresses of objects that are not part of
the same struct or array are not known ahead of time.  The
addresses may even be different in different runs of the
program.  Second, in segmented memory architectures pointers
are (segment id, offset) pairs.  Subtracting two pointers with
different segment ids doesn't produce anything meaningful.
On the other hand, if the implementation of a segmented memory
pointer represents the segment id and the offset as bit fields
in a large integer, with the offset in the low-order bits, then
the setFrameBuffer pointer arithmetic would still work.

Florian



Kevin Wheatley wrote:
> Florian Kainz wrote:
> > memory location where pixel (0,0) would be if it existed.  If your
> > buffer contains only a single tile, and that tile does not include
> > pixel (0,0), then the base pointer just points outside the buffer.
> > This may seem weird, but it works.  For a more detailed explanation
>
> it is also relying on implementation defined/undefined behaviour in
> the language standard - subtracting from the pointer results in a
> location outside an allocated block of memory (give or take the one
> past the end allowance) could result in all sorts of weird behaviour
> depending on implementation by the compiler vendor.
>
> I imagine on embedded systems your more likely to get problems or on
> platforms where the address of the allocated memory block has a
> smaller value vs the offset to base memory that the calculation
> results in. This on some platforms could result in a calculation that
> wraps to a very large memory address which could generare traps or
> exceptions.
>
> But this is a 'theory' rather than 'practice' statement on most
> desktop platforms of course :-)
>
> Kevin