Hi Michael, On Fri, 10 May 2013 13:02:57 -0400, Michael Cashwell <mboa...@prograde.net> wrote:
> On May 10, 2013, at 11:09 AM, Albert ARIBAUD <albert.u.b...@aribaud.net> > wrote: > > > The compiler considers the name/symbol to be value, not the address of the > > corresponding object... at least most of the time: as you indicate, when > > the symbol denotes a C array, then the C compiler understand the symbol as > > the address of the array. > > I ran into a case one on Codewarrior Mac PPC tools where there was a subtle > different here. In an existing body of code there was originally a global > char[] defined with a matching extern char[] declared in a header. > > At some point the definition was changed to char* because the size of the > array grew and we wanted it out of the global section. I traced an obscure > crash to some assembly code that had worked when the definition was char[] > but needed an extra level of indirection when it was char *. Well, of course it did! char* is a pointer to char, with syntactic facilities to use it as a pointer to char array, but char* is not an array. The value of a pointer to char is a (probably 32-bit) address, and you need to dereferenc it to get a char. > During that debugging I found that the declaration had not been changed to > char * but the C compiler hadn't cared. It handled the mixed forms just fine > despite the clear difference in the code. Well, the compiler would not care that one C module would know the symbol as char* and another one would know it as char[], since the compiler treats compilation units completely independently. You would end up using the same address space area for two different objects: an array of chars, overlapped with a (probably 32-bit) pointer to char. Where I worked up until recently, we had a 'coding rule' that required us to always #include a module's .h file (its public interface) from within its .c file (its implementation) if only to make sure the compiler saw both the declarations and the definitions in a single compilation unit, and would thus bark at us for screwing up between declaration and definition. > I surmised it was some subtle issue around PPC's handling of global data > (or the Codewarrior PPC ABI) but still don't really know. This has nothing to do with PPC or CW; this is just C working as designed. > -Mike Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot