This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Is this expected gcc behaviour?


On Tue, Aug 03, 2004 at 02:07:31AM -0400, Peter Barada wrote:
> then I think the compiler would load the *value* of ptr instead of the
> *address* of ptr and then test the *value* for NULL, not test its
> *address* for NULL.
> 
> I don't think there is any case where an *address* of a pointer(not
> its value) can be NULL?

it gets strange when linker scripts.  suppose we have the following in
the linker script:

_HeapSize = DEFINED(_HeapSize) ? _HeapSize : 0x10000;

it's my understanding that the linker assigns this as an untyped symbol
at the specified address.  so if we want to use the address as a number
(in this case the number of bytes in the heap) we have to cast it, take
its address, and cast to an integer.

RTEMS uses this to allow setting the heap size at link time.  if
_HeapSize is set to 0 via -Wl,--defsym,_HeapSize=0 , RTEMS will
calculate the heapsize at runtime.  it's espcially useful if you're
producing RAM vs ROM versions of the same program; all you have to do is
relink to change the memory sizes and locations.

if newer versions of gcc are optimizing this out (and according to C
standard that's OK), how else can this be accomplished?  a "magic
number" for the _HeapSize symbol, like 0xffffffff or something?

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  aaron@frye.com

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]