#2173 Valid Data pointer may be indistinguishible from NULL. (with possible workaround))

[Sergey]

There are some minor trouble with x51 port:

As known, XRAM addresses starts from 0.
Therefore, pointer to first data item, placed to XRAM, has zero numerical value, and indistiguishible from "empty" (==NULL) pointer.
Possible workaround: declaration of dummy variable to XRAM, placed to zero address.

Wrong example:
...

__xdata U8 Xbuffer[Xbuflen];

__xdata U8 TPointer;
...
/ NO other XRAM variables */
....

TPointer = Xbuffer;
...
if (TPointer != NULL)
{
....
}
else
{
.... / this branch will performs, despite to valid pointer /
};

Cure: Add additional, "dummy" byte for shift start address values from zero:

...

__xdata __at (0x0000) U8 Dummy_byte;

__xdata U8 Xbuffer[Xbuflen];

__xdata U8 TPointer;
...
/ NO other XRAM variables */

It works OK.

[Maarten Brock]

Another alternative is to link with --xram-loc 0x0001 to ignore address 0.
Besides the example suffers from retyping as this will not compile without severe warning indicating a real problem: TPointer is not a pointer.
Did you mean an xdata pointer or a generic pointer?

[Maarten Brock]

Unfortunately using __at(0) without an initializer does not work as it will not allocate memory. So the conclusion 'It works OK' is wrong.

And we can't fix this by adding an initialized __at(0) because someone might not want to touch address zero at all. I think we must leave this for the user to fix, using --xram-loc to whereever he wants his xdata to start.

[Maarten Brock]

On second thought we might opt to change the default to --xram-loc 0x0001
I will implement this if no objections arise.

[Sergey]

On second thought we might opt to change the default to
--xram-loc 0x0001
I will implement this if no objections arise.

In my opinion, it will be very simple and elegant solution.
The loss of only a single XRAM byte is immaterial to 99.9% of cases.
Thanks!

[Maarten Brock]

Fixed in SDCC 3.3.2 #8922.

[Jack Mitchell]

The change made in this bug has bitten me today when I upgraded to SDCC 3.4.0 as we memory map a structure driectly from an 8051 in our system, which is presumed to start at 0x0000. We have fixed the issue by setting --xram-loc=0x0000 at compile time, but the manual still states that xram starts at 0 (pg. 34), could the documentation be updated to reflect that it now starts at 1?