Re: to give files unique no

On Mon, 23 Mar 2009 03:10:04 -0700 (PDT), sinbad
<sinbad.sinbad@xxxxxxxxx> wrote in comp.lang.c:

To give all the *.c files in a program a unique number, and this
number has to
be automatically assigned to some file local variable or macro so that
it can be used in
the functions of the file. and this information should get stored in
some
global data structure so that it can be referenced later.

1.c
---
int my_api (int data, int fileno){
node_t *node;
...
..
node->data = data;
node->fileno = fileno;
listadd(node);
...
..
}

int fun_1() {
...
..
my_api(data,__FILE_NO__);
...
..
}

2.c
---

int fun_2() {
...
..
my_api(data,__FILE_NO__);
...
..
}
I could've used __FILE__ built-in macro but storing file_name is
expensive
and if my_api() has to run faster obviously string operations are not
a good
choice. I want the fileno to filename information to be stored so that
fileno
can be correlated with filename for later use.How can this be done.

Here is something that we have used for more than 12 years in
production embedded C applications, to provide non-conflicting numbers
for a variety of purposes.

In the original application, 32-bit embedded controller running a 486
processor, there were about 30 "tasks" that were significant modules
containing multiple source files. In fact, most of them were separate
tasks under a multitasking real time OS, but that is not necessary.

In a separate system include directory, which contained all headers
files that were included by more than one task, we had a file like
this (the tool chain only supported MS-DOS 8.3 file names, even on
Windows 95 and NT):

sub_sys.h

....which basically looked something like this, ignoring include
guards:

#define T1_MSG_BASE 0x100
#define T2_MSG_BASE 0x200
/* ... */
#define T30_MSG_BASE 0x1E00

....the compiler, the first ever Win32 port of Unix product had some
problems with enumerations. The T1, T2, etc., were actually replaced
by the two, three, or four character mnemonic identifying the task.

Then there was file_ids.h:

#define C_T1_MAIN T1_MSG_BASE
#define C_T1_QUERY T1_MSG_BASE+1
#define C_T1_VALID T1_MSG_BASE+2

....where the token was based on the actual file name, converted to
upper case, with the extension C_ replacing the .c extension and
ensuring that no token started with E followed by something that
violated the implementation reserved name space.

There was also sys_err.h, where task specific error codes were
defined:

#define T1_PARAMETER_OUT_OF_RANGE T1_MSG_BASE
#define T1_INCORRECT_STATE T1_MSG_BASE+1

....and so on.

Then in each source file, at the top after #include directives, was:

#define FNAME C_T1_MAIN

....in the source file t1_main.c. In the code, calls to a logging
function like this:

Logging_Function(FNAME, __LINE__,T1_INCORRECT_STATE);

The redefinition of FNAME to the file ID token and using FNAME in all
the places where it was needed, instead of having to use C_T1_MAIN in
every notification, cut down on a lot of cut-and-paste errors when a
logging call was copied from one source file to another and changing
the programmer forgot to change C_T2_CALC to C_T1_MAIN.

Fortunately, all later projects had tool chains that handled
enumeration types properly, making a lot of the manual macro
definitions go away.

So file_id.h now looks like this:

enum /* name less */
{
C_T1_MAIN = T1_MSG_BASE,
C_T1_QUERY,
C_T1_VALID,

C_T2_MAIN = T2_MSG_BASE,
C_T2_CALC,

/*...*/

C_T30_MAIN = T30_MSG_BASE,
C_T30_INPUT,
/*...*/
C_T30_LAST
};

As for a debugging display, on every call to the logging function it
dumps error code in hex, file id in hex, line number in decimal, and
system timer value to a serial port that is not connected to anything
in the product, but to a computer running a communications program for
debugging.

If an executable is built with a particular symbol #defined, a large
table is included in a file that associates a string literal
containing the real base file name ("t1_main.c") with the file id. And
the macro also causes the logging task to reprint the same information
as above, with the string replacing the file id, to the same serial
port after extracting the queued message and sending on to a computer
higher up the line.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
.

Relevant Pages
Loading