On Sat, Apr 10, 2010 at 10:14 PM, Jesus Sanchez <zexel08@gmail.com> wrote:
quoted text
> El 11/04/2010 6:14, Jesus Sanchez escribis:
...
quoted text
>>   Coding some simple stuff in C I ended up having a harmless mistake (I
>> hope) a double-declared variable with different types (char and int for
>> the example) in wich I did assignements beyond the bounds of the type
>> size. Let's call it foo, declared in files compiled separatedly. Also
>> say that everything it's compiled with gcc -c option (exect the final
>> executable) without warnings of any kind:
>>
>>   file a.c  contains "char foo" on the code.
>>   and b.c  contains "int foo" on the code.

It violates a constraint of the C standard for two translation units
of a program to have different tentative definitions for a single
(necessarily external) identifier.  Therefore, the behavior of your
program is NOT DEFINED BY THE C STANDARD.

If you're interested in the chapter-and-verse of this, I suggest you
take it to USENET, comp.lang.c


quoted text
>>   I know the rigth thing is to declare the variable 'foo' on a header
>> file and include it in all my code but I was just curious, what happends
>> to the upper 0x22 ?? Was I accessing to a ilegal zone of memory?? the
>> code executed without any error :o and the compiler showed no warning.

You were doing something that isn't guaranteed by the standard and
whose behavior isn't guaranteed by OpenBSD.  If you ever upgrade your
system or try to compile this software on other systems, it may behave
differently WITH NO WARNING.

Given that, writing such code seems...unwise.  I certainly recommend
against doing so.


...
quoted text
> When using ELF, the .comm directive takes an optional third argument. This
> is the desired alignment of the symbol, specified as a byte boundary (for
> example, an alignment of 16 means that the least significant 4 bits of the
> address should be zero). The alignment must be an absolute expression, and
> it must be a power of two. If ld allocates uninitialized memory for the
> common symbol, it will use the alignment when placing the symbol. If no
> alignment is specified, as will set the alignment to the largest power of
> two less than or equal to the size of the symbol, up to a maximum of 16.
>
> seen on:
> http://stackoverflow.com/questions/501105/gcc-generated-assembly-comm

<sigh>

1) alignment != allocated size.  A one byte variable might have 4 byte
alignment...and yet still share space with another variable with a
less strict alignment!

2) To steal a quote from Blair Houghton: "'I read it on a random web
site' that's sort of like hearsay evidence from Richard Nixon..."
You've quoted a website; do you have a *good* reason for believing
that their quote applies to (1) the software you're running, or (2)
the software you will be running in the future?


quoted text
> so regarding my question, ld will use the largest memory space found as a
> .comm foo,
>  so no harm at all with this mistake :D

The only harm is to your reputation as a C programmer.  For example, I
would not hire a programmer who said "it's okay to have conflicting
variable definitions in different translation units".


Philip Guenther