[sdcc-devel] [ sdcc-Bugs-1012147 ] incorrect pointer address

[SourceForge.net <no...@so...>]

Bugs item #1012147, was opened at 2004-08-19 14:33
Message generated for change (Comment added) made by evert
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1012147&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: msc51(8051) target
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect pointer address

Initial Comment:
Hi,
I have found what appears to be a bug to do with pointers.
I casted to long do i could use the cygnal IDE to trace
this sample.  The problem cropped up in code without
the long and resulted in incorrect data being
processed.  This code snippet demonstrates the problem.

the line ptr = (&s)+1 is the one that gives the
incorrect result



SDCC :
mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08
2.4.3 #7
97 (Aug 14 2004) (MINGW32)


sdcc --debug ptr_bug.c

// ptr_bug.c
typedef struct
{
	char a;
	char b;
} TEST;

xdata TEST s;
volatile unsigned long addr;

void main(void)
{
	unsigned char *ptr;

	s.a = 1;
	s.b = 2;
	ptr = (&s)+1;
	addr = (unsigned long)ptr;    // addr received 0x02000100
	ptr = &s;
	ptr = ptr+1;
	addr = (unsigned long)ptr; // addr received 0x01000100
}


----------------------------------------------------------------------

Comment By: evert vrieze (evert)
Date: 2005-07-27 02:10

Message:
Logged In: YES 
user_id=77566

Looks all OK. That's not a bug.

Pointer address arithmatic is based on the assumption that 
pointers often point to arrays of elements. Depending on the 
size of the elements, calculations of the n-th element should 
produce the correct memory address, whatever the size of 
the elements.

Your example:
The first expression calculates the address of the [base+1]'s 
element of the data refered to by &s. As the compiler sees 
that the bytesize of structure s is sizeof(s) = 2, it will set the 
ptr to the address AFTER the the structure.

In the second instance it STARTs from the base of structure 
s (should give a warning of invalid ptr assignment, unless 
casted). When incremented, it is a char pointer, so 
incrementing with the sizeof(char).


----------------------------------------------------------------------

Comment By: Maarten Brock (maartenbrock)
Date: 2004-08-19 20:51

Message:
Logged In: YES 
user_id=888171

Mathias and anonymous,

A warning would be apropriate as a "pointer to TEST" is 
assigned to a "pointer to char". Nevertheless it's not bad 
code, it's perfectly correct.

Greets,
Maarten

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2004-08-19 17:54

Message:
Logged In: NO 

Hi,

the code generated is correct in both cases.
The compiler has no reason to issue a warning.

The pointer is in both cases incremented by sizeof (type).
In your 1st example sizeof (TEST) == 2 is used, whereas in 
your 2nd example (cast to char*) sizeof (char) == 1 is used.


bis die Tage...
. Mathias

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2004-08-19 14:55

Message:
Logged In: NO 

Oops, looks like I was a bit hasty with the bug report.  I just 
found the code works correctly if 
ptr = (&s)+1;
is replaced by:
ptr = (char*)(&s)+1;

I hadn't put the cast in but I think there should be a warning 
of some sort rather than just generating bad code

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1012147&group_id=599