#ident (preprocessor directive) 
Author Message
 #ident (preprocessor directive)

I just recently saw this directive for the first time. If anyone can
tell me what it does, I'd be grateful. Thanks.
--
Posted via Talkway - http://www.*-*-*.com/
Exchange ideas on practically anything (tm).
--



Sat, 20 Apr 2002 03:00:00 GMT  
 #ident (preprocessor directive)

Quote:

> I just recently saw this directive for the first time. If anyone can
> tell me what it does, I'd be grateful. Thanks.

It is something compiler-specific; it is not a part of ANSI C.

--

 Alcyone Systems | irc maxxon (efnet) | web http://www.alcyone.com/max/
    San Jose, CA | languages en, eo | icbm 37 20 07 N 121 53 38 W
             USA | 425 days and counting | &tSftDotIotE
 __
/  \ No man who needs a monument ever ought to have one.
\__/ Nathaniel Hawthorne
--



Sun, 21 Apr 2002 03:00:00 GMT  
 #ident (preprocessor directive)

Quote:

> I just recently saw this directive for the first time. If anyone can
> tell me what it does, I'd be grateful. Thanks.

#ident causes the generation of a record in the object module
that contains the identifying information, suitable for use
by de{*filter*}s and especially the UNIX "what" utility.  It is
preferable to the old trick
        static char SCCS_id[] = "whatever";
because it doesn't use space in the executable image itself.
--



Sun, 21 Apr 2002 03:00:00 GMT  
 #ident (preprocessor directive)

Quote:

> I just recently saw this directive for the first time. If anyone can
> tell me what it does, I'd be grateful. Thanks.

This is the first time I've heard of it.  A quick search on Google
turned up the following information:

(from http://www.cl.cam.ac.uk/texinfodoc/cpp.html )

The `#ident' command is supported for compatibility with certain other
systems.  It is followed by a line of text. On some systems, the text is
copied into a special place in the object file; on most systems, the
text is ignored and this command has no effect. Typically `#ident' is
only used in header files supplied with those systems where it is
meaningful.

/peter
--



Sun, 21 Apr 2002 03:00:00 GMT  
 #ident (preprocessor directive)

Quote:


> > I just recently saw this directive for the first time. If anyone can
> > tell me what it does, I'd be grateful. Thanks.

> It is something compiler-specific; it is not a part of ANSI C.

On the other hand, most compilers have implemented the same device using
#pragma ident "somestring"

This is much prefered to #ident (which is not syntactically allowed in
Standard), but #pragma syntax is allowed in Standard:

"6.8.6 Pragma directive

Semantics

A preprocessing directive of the form
  # pragma pp-tokens_opt new-line
causes the implementation to behave in an implementation-defined manner.  Any
pragma that is not recognized by the implementation is ignored."

Note: this does not mean that #pragma ident is standard, or behaves in any
particular fashion!

Generally though, for ident, the idea is to insert some string, usually version
control information, into the executable so that if necessary the versions of
the source files that went into a particualr compilation can be determined
anytime.

--
"I don't know about your brain, but mine is really...bossy."
Mike Percy, Senior Computer Scientist, Scientific Research Corp.
--



Sun, 21 Apr 2002 03:00:00 GMT  
 #ident (preprocessor directive)

Quote:

> On the other hand, most compilers have implemented the same device
> using
> #pragma ident "somestring"

> This is much prefered to #ident (which is not syntactically allowed in
> Standard), but #pragma syntax is allowed in Standard:

No doubt about it.  #pragma is specifically _designed_ to be used for
such implementation-specific things.

--

 Alcyone Systems | irc maxxon (efnet) | web http://www.alcyone.com/max/
    San Jose, CA | languages en, eo | icbm 37 20 07 N 121 53 38 W
             USA | 424 days and counting | &tSftDotIotE
 __
/  \ Punctuality is the virtue of the bored.
\__/ Evelyn Waugh
--



Mon, 22 Apr 2002 03:00:00 GMT  
 #ident (preprocessor directive)
[...]

Quote:
> On the other hand, most compilers have implemented the same device using
> #pragma ident "somestring"

Which, if you think about it for some time, is just about as evil as plain
'#ident' itself. The problem is, exactly you said:

Quote:
> Note: this does not mean that #pragma ident is standard, or behaves in any
> particular fashion!

The behaviour of '#pragma ident' is implementation-defined, which in
itself is not much of a problem. The real problem is another one: two
different compilers might easily interpret the same #pragma statement
in totally incompatible ways. And on top of that, there is *no* way
you can generate a #pragma, nor can you deactivate it, once you've
written it into the source, by use of the preprocessor.

Result: there is no way you can use implementation-defined specialties
via #pragma lines and still keep your program source truly portable to
other ANSI C compilers. So, in the end of the day, #pragma cannot
portably be used for anything. It may have looked like a good idea, at
the time of its invention, but it simply doesn't work.
--

Even if all the snow were burnt, ashes would remain.
--



Mon, 22 Apr 2002 03:00:00 GMT  
 #ident (preprocessor directive)

Quote:


> [...]
> > On the other hand, most compilers have implemented the same device using
> > #pragma ident "somestring"

> Which, if you think about it for some time, is just about as evil as plain
> '#ident' itself. The problem is, exactly you said:

> > Note: this does not mean that #pragma ident is standard, or behaves in any
> > particular fashion!

> The behaviour of '#pragma ident' is implementation-defined, which in
> itself is not much of a problem. The real problem is another one: two
> different compilers might easily interpret the same #pragma statement
> in totally incompatible ways.

Possible, but I find that #pragma ident is either not implemented or is
implemented with the same meaning on my compilers.  I find the utility of it to
be worth the potential danger that someday I may hit a sick and twisted compiler
vendor that uses #pragma ident for some unholy purpose.  So all my code and
libraries have #pragma ident included.

Quote:

> Result: there is no way you can use implementation-defined specialties
> via #pragma lines and still keep your program source truly portable to
> other ANSI C compilers. So, in the end of the day, #pragma cannot
> portably be used for anything. It may have looked like a good idea, at
> the time of its invention, but it simply doesn't work.

Of course not!  As soon as you do anything "implementation defined" you're not
going to be portable.  But at least with pragma you can at least be sure that
the code will be syntactically correct, with unimplemented pragmas being
silently ignored.  You must verify pragma usage when you change compilers.  If
you should hit some compatibility (different semantics for same pragma name)
you've got a problem.  You can easily strip pragmas from code though, grep -v
for example, so I'm not really worried.  Plus I can't recall ever using pragma
other than ident that wasn't grossly non-portable (interrupt handlers, etc.).

Quote:
> --

> Even if all the snow were burnt, ashes would remain.
> --


--
"I don't know about your brain, but mine is really...bossy."
Mike Percy, Senior Computer Scientist, Scientific Research Corp.
--



Tue, 23 Apr 2002 03:00:00 GMT  
 #ident (preprocessor directive)

Quote:


> [...]
> > On the other hand, most compilers have implemented the same device using
> > #pragma ident "somestring"

> Which, if you think about it for some time, is just about as evil as plain
> '#ident' itself. The problem is, exactly you said:

> > Note: this does not mean that #pragma ident is standard, or behaves in any
> > particular fashion!

> The behaviour of '#pragma ident' is implementation-defined, which in
> itself is not much of a problem. The real problem is another one: two
> different compilers might easily interpret the same #pragma statement
> in totally incompatible ways. And on top of that, there is *no* way
> you can generate a #pragma, nor can you deactivate it, once you've
> written it into the source, by use of the preprocessor.

How about the following sort of construct?

#if defined(SOMETHING)
#pragma whatever
#endif

Since, by definition, pragma is a hook that allows a compiler to
implement compile specific features, it makes sense that a programmer
using pragmas would use a construct like the above.

For example, Microsoft compilers under win32 support a pragma that
allows deactivation of certain warning messages.  And they implicitly
#define certain macros (like _WIN32) so you can use constructs like
the above to invoke a compiler specific pragma safely.

To effectively use pragmas you need to delve into documentation
that is specific to your compiler.  I fail to see that finding
a set of predefined macros that are also specific to your compiler
is a big leap from doing that.

Quote:

> Result: there is no way you can use implementation-defined specialties
> via #pragma lines and still keep your program source truly portable to
> other ANSI C compilers. So, in the end of the day, #pragma cannot
> portably be used for anything. It may have looked like a good idea, at
> the time of its invention, but it simply doesn't work.

I beg to differ.  #pragma is not intended to be a portably used for
anything.  If you are using #pragma you are doing something that
is inherently compiler specific.  You could also use things like
command line options to the compiler to do the same thing, and
delegate the responsibility to whoever maintains your build
scripts.  That is feasible, but also leaves your code vulnerable
t5o changes in those scripts.  I once had a function that
tickled optimiser bugs in two compilers, but worked perfectly
with a third.  Since the problem was only with one function
and two compilers, it was more cost effective to use pragmas
surrounded by #if guards than to worry about fine grained issues
of maintaining multiple build scripts for different compilers
and operating systems.

Pragmas are a useful tool, but they need to be used in a disciplined
manner.

-<Automagically included trailer>
Robert O'Dowd                       Ph    +61 (8) 8259 6546
MOD/DSTO                            Fax    +61 (8) 8259 5139
P.O. Box 1500                       Email:

Salisbury, South Australia, 5108

Disclaimer: Opinions above are mine and may be worth what you paid for
them
--



Tue, 23 Apr 2002 03:00:00 GMT  
 #ident (preprocessor directive)

Quote:

>How about the following sort of construct?

>#if defined(SOMETHING)
>#pragma whatever
>#endif

This probably works in practise -- but since "#pragma" is up to the
implementation, *and* resembles a preprocessor directive, who is to
say that "#pragma ident" is not going to mean, in effect, "#endif"
in some compiler?  Then you would have unbalanced #ifdef/#endif pairs.

Quote:
>Since, by definition, pragma is a hook that allows a compiler to
>implement compile specific features, it makes sense that a programmer
>using pragmas would use a construct like the above.

The C9X "_Pragma" construct is, I think, rather better, because:

 - it does not resemble a preprocessor directive
 - it can be produced *via* preprocessor directives

The latter means that, if you want a hook to implement Feature F on
Compiler C, you can do things like:

        #include "cmdef.h"
        USE_FEATURE_F

Now you simply have to arrange for the compiler-dependent definitions
file "cmdef.h" to have the proper contents, i.e., you can factor
the compiler-specific bits out into separate files.  (Source files
turn out, in practise again, to be a wonderful "unit of portability",
as it were.)  Where Feature F is inapplicable, the line:

        #define USE_FEATURE_F /*empty*/

suffices.
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc


--



Thu, 25 Apr 2002 03:00:00 GMT  
 #ident (preprocessor directive)

Quote:

> And on top of that, there is *no* way
> you can generate a #pragma, nor can you deactivate it, once you've
> written it into the source, by use of the preprocessor.

The Jan 1999 C9X draft defines a _Pragma(string-literal) operator
which does the same as #pragma but can be the result of a macro
expansion.
--



Thu, 25 Apr 2002 03:00:00 GMT  
 #ident (preprocessor directive)

Quote:


[...]
> > And on top of that, there is *no* way
> > you can generate a #pragma, nor can you deactivate it, once you've
> > written it into the source, by use of the preprocessor.
> How about the following sort of construct?
> #if defined(SOMETHING)
> #pragma whatever
> #endif

It took me some fiddling with the standard (C9x draft), but I conclude
you're right: this would allow to deactivate a pragma, using an #if
block around it. But the other half of my statement still holds, I
think: you cannot generate a #pragma line (or any preprocessing
directive, for that matter) at compilation time. You cannot #define a
macro that contains a #pragma line and expect it to work. That's why
in C9x, they had to invent the _Pragma() method to do just that.

So what remains is the issue of code bloat: if you want to use pragma,
you have to write code blocks like the one above, verbatim, each and
every time you want to use that pragma in a portable fashion.  Or you
could do something like '#include "pragma_warn456_off.h"', which is
even uglier, IMHO.

Quote:
> To effectively use pragmas you need to delve into documentation
> that is specific to your compiler.  I fail to see that finding
> a set of predefined macros that are also specific to your compiler
> is a big leap from doing that.

The real problem is that, in principle, you have to delve into the
documentation of every existing C compiler to be sure that a given
#pragma doesn't wreak havoc, there. Or you have to protect each and
every one of them by an

        #if defined(MY_COMPILER)&&(MY_COMPILER_VERSION==12345)
        /*...*/
        #endif

block , which would make them very cumbersome to use. Just for the
sake of example, think of '#pragma warn', probably one of the most
widely used pragma statements: How many different meanings can one and
the same '#pragma warn' line take, just by using it with a huge
collection of different compilers? And, more importantly: how can you
ever be sure that you know all of them? Answer: you can't.

Quote:
> I beg to differ.  #pragma is not intended to be a portably used for
> anything.  If you are using #pragma you are doing something that
> is inherently compiler specific.  

But being explicitly and completely compiler specific, anyway, what
right does it have to be part of the ANSI/ISO C Standard, then?

AFAICS, #pragma was invented as a way to bury such
implementation-specific stuff somewhat cleverly, while letting the
source remain portable ANSI C. But of what use is it, if I have to
hide every single use of #pragma in an '#if (this is compiler x,
version yz)' clause, which is about the most explicit way of saying
'This source is inportable' you can write into a C source?

The pre-ANSI method this thread started out with, '#ident' may
actually not have been a bit less portable than '#pragma ident', in
the light of these side issues, I'd say.
--

Even if all the snow were burnt, ashes would remain.
--



Thu, 25 Apr 2002 03:00:00 GMT  
 #ident (preprocessor directive)

Quote:



> > [...]
> > > On the other hand, most compilers have implemented the same device using
> > > #pragma ident "somestring"

> > Which, if you think about it for some time, is just about as evil as plain
> > '#ident' itself. The problem is, exactly you said:

> > > Note: this does not mean that #pragma ident is standard, or behaves in any
> > > particular fashion!

> > The behaviour of '#pragma ident' is implementation-defined, which in
> > itself is not much of a problem. The real problem is another one: two
> > different compilers might easily interpret the same #pragma statement
> > in totally incompatible ways. And on top of that, there is *no* way
> > you can generate a #pragma, nor can you deactivate it, once you've
> > written it into the source, by use of the preprocessor.

> How about the following sort of construct?

> #if defined(SOMETHING)
> #pragma whatever
> #endif

> Since, by definition, pragma is a hook that allows a compiler to
> implement compile specific features, it makes sense that a programmer
> using pragmas would use a construct like the above.

Unfortunately, it doesn't solve the *real* problems.  Say I'm writing
code for 2 platforms, and I have a C compiler on each that can perform
inlining (the example is completely hypothetical, of course -- no
compiler vendor would ever do what I'm describing).  For the first
compiler, I have to say "#pragma inline", and for the second "#pragma
inline_func", in order to inline the next function.

So I have to say:

#ifdef _COMPILER_1
#pragma inline
#elif _COMPILER_2
#pragma inline_func
#endif
int f(int x) {
...

Quote:
}

before *each* function I want to inline.  Now say I port to a third
compiler, with yet another #pragma to specify inlining.  Dead easy --
just search & replace on all my files.

Wouldn't it be nice (r) if I could use some token like "__inline__" to
introduce a function I want to inline?  Now, I can just say

#ifdef _COMPILER_1
#define INLINE __inline__
#elif _COMPILER_2
#define INLINE __inline_func__
#else
#define INLINE
#endif

in *one* header file, and then say

INLINE int f(int x)

whenever I want to.  And when I get that third compiler, I can add
inlining in just *one* place.

Of course, it could be argued that pragmas aren't the right way to
specify such features to the compiler.  Unfortunately, they often are.

Quote:
>[...]
> Pragmas are a useful tool, but they need to be used in a disciplined
> manner.

Unfortunately, here discipline on the part of the user is not enough.

--

Compugen Ltd.          |Tel: +972-2-6795059 (Jerusalem) \  100% recycled bits!
72 Pinhas Rosen St.    |Tel: +972-3-7658520 (Main office)`--------------------
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555  http://3w.compugen.co.il/~ariels
--



Thu, 25 Apr 2002 03:00:00 GMT  
 #ident (preprocessor directive)

Quote:

> Result: there is no way you can use implementation-defined specialties
> via #pragma lines and still keep your program source truly portable to
> other ANSI C compilers. So, in the end of the day, #pragma cannot
> portably be used for anything. It may have looked like a good idea, at
> the time of its invention, but it simply doesn't work.

Actually, #pragma works if correctly conditionalized for the
environment.
In C99 there are even some standard pragmas, to control such things as
the floating-point rounding mode.
--



Thu, 25 Apr 2002 03:00:00 GMT  
 #ident (preprocessor directive)

Quote:



> >How about the following sort of construct?

> >#if defined(SOMETHING)
> >#pragma whatever
> >#endif

> This probably works in practise -- but since "#pragma" is up to the
> implementation, *and* resembles a preprocessor directive, who is to
> say that "#pragma ident" is not going to mean, in effect, "#endif"
> in some compiler?  Then you would have unbalanced #ifdef/#endif pairs.

Interesting point!  Firstly, I would be surprised if such a compiler
would ever come to be.  Anyone with the skills to design/implement
a compiler would probably realise such behaviour would introduce
more trouble than it's worth.  At worst, irate programmers who get
bitten by that sort of behaviour (eg because a lot of existing code
would suddenly break) would probably howl loudly enough to get
that "feature" removed.

And, since no compiler I've ever heard of allows such a thing, I
suspect we're pretty safe for now :-)

Quote:
>[An excellent justification for the C9X _Pragma construct snipped].

-<Automagically included trailer>
Robert O'Dowd                       Ph    +61 (8) 8259 6546
MOD/DSTO                            Fax    +61 (8) 8259 5139
P.O. Box 1500                       Email:

Salisbury, South Australia, 5108

Disclaimer: Opinions above are mine and may be worth what you paid for
them
--



Sat, 27 Apr 2002 03:00:00 GMT  
 
 [ 23 post ]  Go to page: [1] [2]

 Relevant Pages 

1. #ident (preprocessor directive)

2. #ident preprocessor directive in MS C 6.0. What is it?

3. warning generated for using #ident directive

4. preprocessor directives (the code in them)

5. C Macros textually substituting for preprocessor directives.

6. C# preprocessor directives

7. Preprocessor directive to replace with source line number

8. Preprocessor: defining a macro inside a #define directive

9. Is this a standard preprocessor directive?

10. Conditional inclusion of preprocessor directives

11. Able To Use Preprocessor Directives Inside Macros?

12. preprocessor directives across assemblies

 

 
Powered by phpBB® Forum Software