Standards compliance

[ozbear]

In one of the C compilers I use if I declare a static variable
in a translation unit thus:
static short x;

to which there is no subsquent references to x anywhere within the
translation unit, I receive a warning stating that there are no
references to x. That is fine, I realise that the compiler is
free to issue whatever warning messages it pleases.

However, the compiler also suppresses generation of x's "space"
in the resulting executable.

Is this permitted by the Standard (89 or 99)?

Placing a
static char[] version = "version 1.2";
is useful when looking at a dump of a file to see what the version
string has in it, but if this information is suppressed from the
executable because there is no reference to the static var
/version/ then I have to resort to crude means to create an
"artificial" reference to /version/.

Is my compiler broken?

Oz

 

[Martin Dickopp]

In one of the C compilers I use if I declare a static variable
in a translation unit thus:
static short x;

to which there is no subsquent references to x anywhere within the
translation unit, I receive a warning stating that there are no
references to x. That is fine, I realise that the compiler is
free to issue whatever warning messages it pleases.

However, the compiler also suppresses generation of x's "space"
in the resulting executable.

Is this permitted by the Standard (89 or 99)?

Yes. Since a strictly conforming program has no way to find out if space
is reserved for an object that is never referenced, the implementation is
free not reserve the space.

Placing a
static char[] version = "version 1.2";
is useful when looking at a dump of a file to see what the version
string has in it,

This is a kludge, which is not even guaranteed to work, as you've found
out yourself.

<OT>
The correct solution is to embed the version string in a special section
of the object file, instead of hiding it in a data section. Many
implementations provide a way to do the former.
</OT>

Martin

 

[Dan Pop]

In one of the C compilers I use if I declare a static variable
in a translation unit thus:
static short x;

to which there is no subsquent references to x anywhere within the
translation unit, I receive a warning stating that there are no
references to x. That is fine, I realise that the compiler is
free to issue whatever warning messages it pleases.

However, the compiler also suppresses generation of x's "space"
in the resulting executable.

Is this permitted by the Standard (89 or 99)?

Yes, by the as-if rule: this optimisation does not affect the observable
behaviour of your program, as defined in terms of the abstract C machine.

Dan

 

[Dan Pop]

Placing a
static char[] version = "version 1.2";
is useful when looking at a dump of a file to see what the version

It actually renders your code invalid and very unlikely to compile at all.

string has in it, but if this information is suppressed from the
executable because there is no reference to the static var
/version/ then I have to resort to crude means to create an
"artificial" reference to /version/.

Which can be trivially avoided by not making the array static. If it has
external linkage, the compiler can no longer perform the optimisation.
To avoid name conflicts, give the array the name of the source file (minus
the .c extension):

char mylib[] = "mylib version 1.2";

for the file mylib.c. So, even when looking at a dump of the whole
executable, you'll know that it is mylib.c that was version 1.2, while
main.c might be still at version 0.64. In theory, the linker could
optimise the array away, but in practice it is highly uncommon.

Dan

 

[ozbear]

Placing a
static char[] version = "version 1.2";
is useful when looking at a dump of a file to see what the version

It actually renders your code invalid and very unlikely to compile at all.

string has in it, but if this information is suppressed from the
executable because there is no reference to the static var
/version/ then I have to resort to crude means to create an
"artificial" reference to /version/.

Which can be trivially avoided by not making the array static. If it has
external linkage, the compiler can no longer perform the optimisation.
To avoid name conflicts, give the array the name of the source file (minus
the .c extension):

char mylib[] = "mylib version 1.2";

for the file mylib.c. So, even when looking at a dump of the whole
executable, you'll know that it is mylib.c that was version 1.2, while
main.c might be still at version 0.64. In theory, the linker could
optimise the array away, but in practice it is highly uncommon.

Oh dear...yes....I got the [] in the wrong place in my post.

Thanks for the suggestion on using the source file name as the
variable name.

Oz

 

[Dan Pop]

Placing a
static char[] version = "version 1.2";
is useful when looking at a dump of a file to see what the version

It actually renders your code invalid and very unlikely to compile at all.

string has in it, but if this information is suppressed from the
executable because there is no reference to the static var
/version/ then I have to resort to crude means to create an
"artificial" reference to /version/.

Which can be trivially avoided by not making the array static. If it has
external linkage, the compiler can no longer perform the optimisation.
To avoid name conflicts, give the array the name of the source file (minus
the .c extension):

char mylib[] = "mylib version 1.2";

for the file mylib.c. So, even when looking at a dump of the whole
executable, you'll know that it is mylib.c that was version 1.2, while
main.c might be still at version 0.64. In theory, the linker could
optimise the array away, but in practice it is highly uncommon.

Oh dear...yes....I got the [] in the wrong place in my post.

Thanks for the suggestion on using the source file name as the
variable name.

And if you make it const, there is also a chance that it will be allocated
in the text segment and not in the data segment (in case it makes any
difference to you).

Dan