how to insert unique ID into binary file that created after compilation?

[pristo]

hello All,
how can i insert unique ID into binary file (that created by compiler)?
(so after compiling i can to identify the src that i use)

thx

[Kenny McCormack]

In article <11************ **********@g43g 2000cwa.googleg roups.com>,
pristo <Ma*******@gmai l.com> wrote:

hello All,
how can i insert unique ID into binary file (that created by compiler)?
(so after compiling i can to identify the src that i use)

Not portable. Can't discuss it here. Blah, blah, blah.

[Eric Sosman]

pristo wrote On 11/08/05 11:36,:

hello All,
how can i insert unique ID into binary file (that created by compiler)?
(so after compiling i can to identify the src that i use)

In portable C, the closest you can come is to create
a static variable initialized with the ID you desire. The
source file name, date, and time are often used for this:

static const char version_info[] =
"@@@ VERSION INFO @@@"
" Compiled from " __FILE__
" on " __DATE__
" at " __TIME__;

Many systems have utilities that can extract and display
the string constants from an executable or object file,
and ways to separate the "@@@ VERSION INFO @@@" strings
from the others (on Unix systems, you could use `strings'
and `grep'). Some source-management systems can be made
to provide part or all of the data, which could automate
the inclusion of a version identifier for each file. Of
course, all such utilities are not part of the C language,
and will vary from system to system.

A disadvantage of this technique is that some compilers
will issue diagnostic messages about variables that are
declared but not used; such compilers are likely to complain
about the `version_info' variable.

--
Er*********@sun .com

[Gordon Burditt]

>how can i insert unique ID into binary file (that created by compiler)?

(so after compiling i can to identify the src that i use)

One common method of inserting an ID is:

static char rcsid[] = "$Id: foo.c,v 1.7 2005/11/08 12:01:32 root Exp $";

A compiler might give a warning about an unreferenced variable (and
might be smart enough to try to discard it): so reference it, for
example, make "foo -V" print out the version string.

The method of INSERTING the id is portable. The method of extracting
it isn't, but locating such a string is fairly easy and makes few
assumptions beyond the file being a raw binary file: scan until
you see a $, followed by a known keyword, followed by a colon, then
output the stuff from a $ to the next $. I think if non-text
characters (whatever that means) or newlines are encountered between
the two $, it's not output. I've never seen the program that
extracts the headers have a false match, although constructing a
failure case is easy.

RCS and CVS (source code control systems) will even maintain the
strings for you with a current version, time stamp, and user who
last checked it in. You actually put in:
static char rcsid[] = "$Id$";
and RCS or CVS will expand it for you.

Gordon L. Burditt

[CarlosB]

If you want to mark the binary file that is generated by more than one
source code: e.g (main.c, other.c, etc.) which will cause more than one
rcsid, and you want one unique mark for the whole binary, a good way to
do this is creating your own marker, something like the piece of code
below: (notice that I'm not testing for i/o, string or any other errors
in this example).

typedef struct tagFooter {
BYTE area1[10];
BYTE area2[10];
} _FOOTER;
#define size_footer sizeof(_FOOTER)

int main(int argc,char **argv)
{
FILE *f;
int size;
_FOOTER myInfo;

if(argc < 3) {
/* we expect to receive at least 2 parameters from command line */
return(1);
}
strcpy(myinfo.a rea1,argv[1]);
strcpy(myinfo.a rea2,argv[2]);

f=fopen("myfile .bin","wb");
fseek(f,0,SEEK_ END);
fwrite(&myinfo, size_footer ,1,f);
fclose(f);
return(0);
}

Instead of getting the values from command line, you could put a CRC
check or anything you desire to use. Also It's pretty easy to create a
program to show the footer information for a marked file.

Hope this can help you.

[pristo]

first thx to all for helping,
i try use your suggestion but its seem that the compiler is optmize the
variable.
i write the code for embdded system and i dont have interface to print
the version out
so how can i cause the compiler think that i use the variable and not
to optmize it?

Pristo

[Gordon Burditt]

>If you want to mark the binary file that is generated by more than one

source code: e.g (main.c, other.c, etc.) which will cause more than one
rcsid,
Nothing wrong with more than one ID, if you make them static.
Often that's the whole point: you get the version number of
everything that was used to create the executable.
and you want one unique mark for the whole binary, a good way to
A common way to deal with this is to use the RCS ID in the version.c
file or the one in the main program as the primary ID, and that's
the one that the -V flag prints.
do this is creating your own marker, something like the piece of code
below: (notice that I'm not testing for i/o, string or any other errors
in this example).
Appending random crap to an executable may destroy it. Particularly
if the executable has a checksum, digital signature, or other
integrity check. Also, the program doing it *SHOULD* be flagged
as a virus.

There's no guarantee that SEEK_END on a binary file will work.
(Some OS such as CP/M only keep file sizes in sectors, so
there may be unwritten stuff at the end of the last sector in
a binary file, with no way to tell how much of it is unwritten.)

Gordon L. Burditt

typedef struct tagFooter {
BYTE area1[10];
BYTE area2[10];
} _FOOTER;
#define size_footer sizeof(_FOOTER)

int main(int argc,char **argv)
{
FILE *f;
int size;
_FOOTER myInfo;

if(argc < 3) {
/* we expect to receive at least 2 parameters from command line */
return(1);
}
strcpy(myinfo.a rea1,argv[1]);
strcpy(myinfo.a rea2,argv[2]);

f=fopen("myfile .bin","wb");
fseek(f,0,SEEK_ END);
fwrite(&myinfo, size_footer ,1,f);
fclose(f);
return(0);
}

Instead of getting the values from command line, you could put a CRC
check or anything you desire to use. Also It's pretty easy to create a
program to show the footer information for a marked file.

Hope this can help you.

[pristo]

thx for helping.
i try use your solution
and its seen that the copiler optimize the variable,
i write for embedded system and i dont have interface for print the
version out
how can i cause the compiler not to optmize this constant?

thx

[Walter Roberson]

In article <11************ *********@g49g2 000cwa.googlegr oups.com>,
pristo <Ma*******@gmai l.com> wrote:

i try use your suggestion but its seem that the compiler is optmize the
variable.
i write the code for embdded system and i dont have interface to print
the version out
so how can i cause the compiler think that i use the variable and not
to optmize it?

Sometimes declaring the variable as volatile is enough to get the
compiler to leave it alone even if it isn't used. Sometimes
simple tricks like taking its strlen() are enough. It depends on
how smart the compiler is about finding "dead code" and "dead variables".
--
If you lie to the compiler, it will get its revenge. -- Eric Sosman

[Skarmander]

pristo wrote:

thx for helping.
i try use your solution
and its seen that the copiler optimize the variable,
i write for embedded system and i dont have interface for print the
version out
how can i cause the compiler not to optmize this constant?

Please quote the relevant parts of posts your reply to.

Your compiler or linker may have an option that tells it to emit statics
even if they're not used. For gcc, it is notable that
-fkeep-static-consts does *not* do the trick in general; this only works
if you're not optimizing. Consult your documentation.

Otherwise, you'll have to try and outsmart your compiler (this is
generally a bad idea, but it may be the only option). That is, involve
the constant in expressions that are too complicated for the compiler to
detect as going unused or evaluating to a constant.

If you find such an expression, it may be a good idea to encapsulate it
in a function, otherwise it'll look very mysterious.

S.