unknown directive

[DevarajA]

What is #pragma used for?

 

[Peter MacMillan]

What is #pragma used for?

compiler specific compilation instructions.

#pragma once

is fairly common and replaces header guarding (#ifdef...#endif)

check the compiler documentation for specific pragmas that it supports.


--
Peter MacMillan
e-mail/msn: (e-mail address removed)
icq: 1-874-927

GCS/IT/L d-(-)>-pu s()-) a- C+++(++++)>$ UL>$ P++ L+ E-(-) W++(+++)>$
N o w++>$ O !M- V PS PE Y+ t++ 5 X R* tv- b++(+) DI D+(++)>$ G e++ h r--
y(--)

 

[CBFalconer]

What is #pragma used for?

Usually to make programs non-portable. Avoid.

 

[Emmanuel Delahaye]

DevarajA wrote on 30/03/05 :

What is #pragma used for?

Nothing.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

..sig under repair

 

[Keith Thompson]

DevarajA wrote on 30/03/05 :

Nothing.

Huh?

C90 6.8.6 says a #pragma directive "causes the implementation to
behave in an implementation-defined manner. Any pragma that is not
recognized by the implementation is ignored."

C99 has similar wording, and additionally defines several standard
forms:

#pragma STDC FP_CONTRACT on-off-switch
#pragma STDC FENV_ACCESS on-off-switch
#pragma STDC CX_LIMITED_RANGE on-off-switch

 

[Emmanuel Delahaye]

Keith Thompson wrote on 30/03/05 :

Huh?

T'was a kinda humour... pragmas make the code not portable

C90 6.8.6 says a #pragma directive "causes the implementation to
behave in an implementation-defined manner. Any pragma that is not
recognized by the implementation is ignored."

This is the point. Two compilers can have the same pragmas with a
different meaning. Hard to find bug...

C99 has similar wording, and additionally defines several standard
forms:

#pragma STDC FP_CONTRACT on-off-switch
#pragma STDC FENV_ACCESS on-off-switch
#pragma STDC CX_LIMITED_RANGE on-off-switch

Ok. Only this form of pragma is acceptable, hoping that no vendor has
used this form previously (there was no 'reserved pragma' in C90). The
STDC trick could work... or not...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"Clearly your code does not meet the original spec."
"You are sentenced to 30 lashes with a wet noodle."
-- Jerry Coffin in a.l.c.c++

 

[Keith Thompson]

Keith Thompson wrote on 30/03/05 :

T'was a kinda humour... pragmas make the code not portable

Right -- and non-portable code isn't the end of the world. Sometimes
it's exactly what you need. The details, of course, are off-topic
here, but the existence of non-portable code is perfectly topical.

An implementation-specific #pragma might be protected by an #ifdef,
such as:

#ifdef __ACME_C__
#pragma ACME optimize(cleverly)
#endif

 

[Dave Vandervies]

Right -- and non-portable code isn't the end of the world. Sometimes
it's exactly what you need. The details, of course, are off-topic
here, but the existence of non-portable code is perfectly topical.

An implementation-specific #pragma might be protected by an #ifdef,
such as:

#ifdef __ACME_C__
#pragma ACME optimize(cleverly)
#endif

....which works fine until you try to build it on the DS9k, which #defines
every symbol starting with __ (most of them to the equivalent of
#define __RHWBVH
, which saves a lot of symbol table space) and blows up the computer
it's running on when it sees a #pragma[1].


dave

[1] The DS9k C99 compiler needed a few special cases for this one.

 

[Keith Thompson]

An implementation-specific #pragma might be protected by an #ifdef,
such as:

#ifdef __ACME_C__
#pragma ACME optimize(cleverly)
#endif

...which works fine until you try to build it on the DS9k, which #defines
every symbol starting with __ (most of them to the equivalent of
#define __RHWBVH
, which saves a lot of symbol table space) and blows up the computer
it's running on when it sees a #pragma[1].

Which means there's one less DS9k in the world for C programmers to
worry about.

 

[CBFalconer]

.... snip ...

Which means there's one less DS9k in the world for C programmers
to worry about.

Even the DS9k shouldn't worry about that #ifdef, because it is
simply interogating a value from the system, not defining it.

 

[Keith Thompson]

Even the DS9k shouldn't worry about that #ifdef, because it is
simply interogating a value from the system, not defining it.

It's not the #ifdef that's a problem, it's the #pragma.

The __ACME_C__ macro was intended by the authors of the Acme C
compiler to indicate that a C program is being compiled by their
compiler. Since any implementation is allowed to define any macros it
likes in the implementation namespace, the evil authors of the DS9k C
compiler chose (in effect) to lie to their users by defining the same
symbol. The #pragma directive is then active, and causes
implementation-defined behavior -- in this case, blowing up the
computer.

(Similarly, the C standard cannot prevent non-conforming
implementations from lying by defining __STDC__ as 1; by definition,
it can't prevent non-conforming implementations from doing
*anything*.)

Such are the risks of writing non-portable code, but I'm not going to
lose any sleep over this particular instance.

 

[Dave Vandervies]

#ifdef __ACME_C__
#pragma ACME optimize(cleverly)
#endif

...which works fine until you try to build it on the DS9k, which #defines
every symbol starting with __ (most of them to the equivalent of
#define __RHWBVH
, which saves a lot of symbol table space) and blows up the computer
it's running on when it sees a #pragma[1].

Which means there's one less DS9k in the world for C programmers to
worry about.

Yep. And, if we're lucky, it'll take the programmer who didn't bother
to familiarize himself with the system he was working with with it.


dave

 

[Joona I Palaste]

Dave Vandervies (e-mail address removed)
It's TRADITIONAL in C for MACROS to HAVE upper-case NAMES, not
PLAIN VARIABLES (IN THEMSELVES).
--Chris Dollin in comp.lang.c

But what if they're PLAIN VARIABLES (FOR THEMSELVES)?

 

[Martin Ambuhl]

But what if they're PLAIN VARIABLES (FOR THEMSELVES)?

Now you've gone and awakened Karl Malbrain.

 

[Emmanuel Delahaye]

Martin Ambuhl wrote on 03/04/05 :

Now you've gone and awakened Karl Malbrain.

Karl "Chair" Malbrain

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"Clearly your code does not meet the original spec."
"You are sentenced to 30 lashes with a wet noodle."
-- Jerry Coffin in a.l.c.c++