DPRG
DPRG List  



[DPRG] C programming qustion - datestamp ?

Subject: [DPRG] C programming qustion - datestamp ?
From: Shaun Parsons Shaunp at CASHPOWER.CO.ZA
Date: Thu Sep 9 02:41:44 CDT 2004

Good day, here is some info on using GCC predefined macros.

3.7.1 Standard Predefined Macros
The standard predefined macros are specified by the relevant language
standards, so they are available with all compilers that implement those
standards. Older compilers may not provide all of them. Their names all
start with double underscores. 

__FILE__
This macro expands to the name of the current input file, in the form of a C
string constant. This is the path by which the preprocessor opened the file,
not the short name specified in #include or as the input file name argument.
For example, "/usr/local/include/myheader.h" is a possible expansion of this
macro. 

__LINE__
This macro expands to the current input line number, in the form of a
decimal integer constant. While we call it a predefined macro, it's a pretty
strange macro, since its "definition" changes with each new line of source
code. 
__FILE__ and __LINE__ are useful in generating an error message to report an
inconsistency detected by the program; the message can state the source line
at which the inconsistency was detected. For example, 

     fprintf (stderr, "Internal error: "
                      "negative string length "
                      "%d at %s, line %d.",
              length, __FILE__, __LINE__);


A #line directive changes __LINE__, and may change __FILE__ as well. See
Line Control. 

C99 introduces __func__, and GCC has provided __FUNCTION__ for a long time.
Both of these are strings containing the name of the current function (there
are slight semantic differences; see the GCC manual). Neither of them is a
macro; the preprocessor does not know the name of the current function. They
tend to be useful in conjunction with __FILE__ and __LINE__, though. 

__DATE__
This macro expands to a string constant that describes the date on which the
preprocessor is being run. The string constant contains eleven characters
and looks like "Feb 12 1996". If the day of the month is less than 10, it is
padded with a space on the left. 
If GCC cannot determine the current date, it will emit a warning message
(once per compilation) and __DATE__ will expand to "??? ?? ????". 


__TIME__
This macro expands to a string constant that describes the time at which the
preprocessor is being run. The string constant contains eight characters and
looks like "23:59:01". 
If GCC cannot determine the current time, it will emit a warning message
(once per compilation) and __TIME__ will expand to "??:??:??". 


Regards
Shaun Parsons

-----Original Message-----
From: Ken Comer [mailto:me at kencomer.com]
Sent: Thursday, September 09, 2004 4:47 AM
To: Clay Timmons
Cc: DPRG Mailing List
Subject: Re: [DPRG] C programming qustion - datestamp ?


> Does anyone know a way to get the compile date from the compiler?
> I've done this before by using the pre-processor to insert the
current
> date.
> Something like this...
>
> printf(" This program was compiled on __DATE__ \n");

Your question is compiler-specific and sometimes even
implementation-specific, but you haven't said what compiler (etc.)
you are using.  If you are referring to some internally-generated
compile date. I am pretty sure (not certain) that it is not available
in gcc (GNU c compiler).

It is common, however, for programmers to insert #define statements
for this sort of information so that they only have to do in one
place. For example:

vvvvvvvvvvvvvv

#ifndef __VERSION__
#define __VERSION__ 1
#define __REVISION__ 0
#define __AUTHOR__ Ken Comer, Jr.
#define __DATE__ 08-SEP-2004

#define VERSION_REFERENCE "version __VERSION__ \
revision __REVISION__ was compiled on __DATE__ \
by __AUTHOR__\n\n"
#endif

^^^^^^^^^^^^^^

then
vvvvvvvvvvvvvv
printf(VERSION_REFERENCE);
^^^^^^^^^^^^^^
Would result in this being printed:
vvvvvvvvvvvvvv
version 1 revision 0 was compiled on 08-SEP-2004 by Ken Comer, Jr.


^^^^^^^^^^^^^^
There are tricky ways to put this into makefiles for unix systems
(and Windows cygwin systems), but that's a different story. All of
the preceding was written by a guy who hasn't written a whole C
program for years, but I am pretty sure it's right.

Ken
--
The UN, the CDC and the WHO all say in blunt, unequivocal terms, "A
flu pandemic is inevitable." Maybe not to your town and maybe not
this year; but history shows us to expect three per century. The
important hallmarks have already appeared this summer. Get a disaster
kit. Twenty-first century cultures are highly mobile and
Avian/Swine/Human flu hybrids kill even young, healthy people. Get
masks, gloves, no-cook food for 3 days, and easily prepared food for
3 weeks. Do it today. The worst that can happen is you end up with
spare groceries.

The life you save will be someone you kiss, someone you hug, or
someone you see every day. (If your life is so bad you hate all the
people you see every day, then pray for plague.)

_______________________________________________
DPRGlist mailing list
DPRGlist at dprg.org
http://list.dprg.org/mailman/listinfo/dprglist


NOTICE OF CONFIDENTIALITY

The information contained in this e-mail message and in the documents
attached herewith (hereinafter "the message") is intended only for the
individual or the entity named above and is intended to be confidential.

The reading of the message or any retention, copying, dissemination,
distribution, disclosure of the existence of the message or of its contents,
or any other use of the message or any part thereof, by anyone other than
the intended recipient is strictly prohibited.  If you received this message
and you are not the intended recipient or agent responsible for the delivery
of this message to the intended recipient, please refrain from reading it
and notify us immediately by telephone +27 (11) 921-7900, so that we can
co-ordinate with you, erasure of the message.

Although this e-mail and its attachments are believed to be free of any
virus or other defect, it is the responsibility of the recipient to ensure
that they are virus-free, and no responsibility is accepted by this firm for
any loss or damage arising from receipt or use thereof.



More information about the DPRG mailing list