[sdcc-devel] [ sdcc-Bugs-1357332 ] Bad data pointers for literal values

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

Bugs item #1357332, was opened at 2005-11-15 12:37
Message generated for change (Comment added) made by tecodev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1357332&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: pic16 target
>Group: fixed
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Alexander R. Enzmann (xan-der)
>Assigned to: Raphael Neider (tecodev)
Summary: Bad data pointers for literal values

Initial Comment:
SDCC : pic16/pic14 2.5.4 #1152 (Nov 14 2005) (MSVC)

Problem 1334191 was closed a little prematurely - while 
some problems were corrected, a new one cropped up 
with the fix.  The following code:
        stdin = STREAM_USART;
nolonger works.  I've tried rewriting the definition of 
STREAM_USART (from stdio.h) to use __data or 
__code like the warning from sdcc suggests, but no joy.

In this particular case, the I/O routines are expecting 
the pointer to have a specific literal value.  The fix for 
pointers now modifies the value of the literal when 
building the pointer.

stdio functions are now hard broke - had to back up to 
earlier version.

Xander


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

>Comment By: Raphael Neider (tecodev)
Date: 2005-11-16 14:29

Message:
Logged In: YES 
user_id=1115835

Hopefully fixed in SDCC #1154.
Sorry for the inconvenience, but this is a bit tricky.
When assigning to a generic pointer (cases (d) and (h) are
probably unexpected!)...
(a) (char*)0x123456 yields generic pointer 0x123456
    --> fixes the new issue
(b) (__data char*)0x123456 yields genptr 0x803456
(c) (__code char*)0x123456 yields genptr 0x003456
(d) (char*)i yields genptr to (0x800000 | i)
    i.e. the same as (__data char*)i for `int i'
(f) (__code char*)i and (__data char*)i append the
    appropriate tag for __code or __data space
(g) (char*)l yields genptr with the tag taken from l's
    third byte---no messing about for `long l'
(h) (__code char*)l does *NOT* force the pointer to
    __code space but rather takes l's 3rd byte as tag,
    i.e. this works just like (char*)l
(i) (__data char*)l only takes two address bytes from l
    and appends a __data space tag

I hope this does the job.

Regards,
Raphael

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

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