unknown directive

[DevarajA]

What is #pragma used for?

[Peter MacMillan]

DevarajA wrote:

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: pe***@writeopen.com
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]

DevarajA wrote:

What is #pragma used for?

Usually to make programs non-portable. Avoid.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[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]

"Emmanuel Delahaye" <em***@YOURBRAnoos.fr> writes:

DevarajA wrote on 30/03/05 :

What is #pragma used for?

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Emmanuel Delahaye]

Keith Thompson wrote on 30/03/05 :

"Emmanuel Delahaye" <em***@YOURBRAnoos.fr> writes:

DevarajA wrote on 30/03/05 :

What is #pragma used for?
Nothing.

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]

"Emmanuel Delahaye" <em***@YOURBRAnoos.fr> writes:

Keith Thompson wrote on 30/03/05 :

"Emmanuel Delahaye" <em***@YOURBRAnoos.fr> writes:

DevarajA wrote on 30/03/05 :
What is #pragma used for?
Nothing.

Huh?

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Dave Vandervies]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

"Emmanuel Delahaye" <em***@YOURBRAnoos.fr> writes:

Keith Thompson wrote on 30/03/05 :

"Emmanuel Delahaye" <em***@YOURBRAnoos.fr> writes:
DevarajA wrote on 30/03/05 :
> What is #pragma used for?
Nothing.

Huh?

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

....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.

--
Dave Vandervies dj******@csclub.uwaterloo.ca
It's TRADITIONAL in C for MACROS to HAVE upper-case NAMES, not
PLAIN VARIABLES (IN THEMSELVES).
--Chris Dollin in comp.lang.c

[Keith Thompson]

dj******@csclub.uwaterloo.ca (Dave Vandervies) writes:

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

[...]

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[CBFalconer]

Keith Thompson wrote:

dj******@csclub.uwaterloo.ca (Dave Vandervies) writes:

Keith Thompson <ks***@mib.org> wrote: [...]

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

.... 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.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Keith Thompson]

CBFalconer <cb********@yahoo.com> writes:

Keith Thompson wrote:

dj******@csclub.uwaterloo.ca (Dave Vandervies) writes:

Keith Thompson <ks***@mib.org> wrote:

[...]

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

... 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.

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Joona I Palaste]

Dave Vandervies <dj******@csclub.uwaterloo.ca> scribbled the following:

Dave Vandervies dj******@csclub.uwaterloo.ca
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)?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"The question of copying music from the Internet is like a two-barreled sword."
- Finnish rap artist Ezkimo

[Martin Ambuhl]

Joona I Palaste wrote:

Dave Vandervies <dj******@csclub.uwaterloo.ca> scribbled the following:

Dave Vandervies dj******@csclub.uwaterloo.ca
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)?

Now you've gone and awakened Karl Malbrain.

[Emmanuel Delahaye]

Martin Ambuhl wrote on 03/04/05 :

Joona I Palaste wrote:

Dave Vandervies <dj******@csclub.uwaterloo.ca> scribbled the following:

Dave Vandervies dj******@csclub.uwaterloo.ca
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)?

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++