preprocessing statements

[Bill Cunningham]

I have been thinking about hiding headers from my compiler's
preprocessor and allowing others to be shown. I want to use the most used
and add others is necessary. Would this be how it is properly done. I want
to ask ahead of time because what I do might work but it might not be the
"correct" or standard way.

#include <stdio.h>
#include <stdlib.h>
#ifdef LINUX
#include <unistd.h>
#include <sys/types>
#include <sys/stats.h>
#include <fctnl.h>
#endif

Is the #endif needed at the end of this case ?

Bill

[Walter Roberson]

In article <vXX_j.5092$nx6.2636@trnddc03>,
Bill Cunningham <no****@nspam.comwrote:

>#include <stdio.h>
#include <stdlib.h>
#ifdef LINUX
#include <unistd.h>
#include <sys/types>
#include <sys/stats.h>
#include <fctnl.h>
#endif

Is the #endif needed at the end of this case ?

Yes. Every #if or #ifdef must have a matching #endif
--
"We may gather out of history a policy, by the comparison and
application of other men's forepassed miseries with our own like
errors and ill deservings." -- Sir Walter Raleigh

[vippstar]

On May 27, 8:56 pm, "Bill Cunningham" <[e-mail]:

I have been thinking about hiding headers from my compiler's
preprocessor and allowing others to be shown. I want to use the most used
and add others is necessary. Would this be how it is properly done. I want
to ask ahead of time because what I do might work but it might not be the
"correct" or standard way.

That doesn't make sense, please re-attempt to explain your intentions,
without being so ambiguous/vague.

#include <stdio.h>
#include <stdlib.h>
#ifdef LINUX
#include <unistd.h>
#include <sys/types>
#include <sys/stats.h>
#include <fctnl.h>

Just what is wrong with you Bill?
Haven't you understood yet such thing is not topical for comp.lang.c?

#endif

Is the #endif needed at the end of this case ?

What's so hard about removing it and trying to compile? Or reading
about #ifdef in your book?
Isn't it the obvious thing to do before asking a group of people about
it?

[Bill Cunningham]

<vi******@gmail.comwrote in message news:175c11eb-5ef5-4c4b-b9bd-

Haven't you understood yet such thing is not topical for comp.lang.c?

Why is precrossing directives OT ?

Bill

[santosh]

Bill Cunningham wrote:

>
<vi******@gmail.comwrote in message news:175c11eb-5ef5-4c4b-b9bd-

>Haven't you understood yet such thing is not topical for comp.lang.c?

Why is precrossing directives OT ?

<clc-mode>
"Precrossing directives" _are_ OT. They aren't mentioned anywhere in the
current and previous C standards. :-)
</clc-mode>

Seriously though, no preprocessing directives are perfectly topical.
vippstar was talking about the various system specific headers that you
had included in your code. Those _are_ OT and I believe better
addressed in comp.unix.programmer. But your actual question can be
answered here and Walter Roberson did so. Also your method to
conditionally compile the include directives is perfectly fine. That's
how it's done.

[vippstar]

On May 27, 9:18 pm, santosh <[e-mail]:

Bill Cunningham wrote:

<[e-mail] in message news:175c11eb-5ef5-4c4b-b9bd-

Haven't you understood yet such thing is not topical for comp.lang.c?

Why is precrossing directives OT ?

<clc-mode>
"Precrossing directives" _are_ OT. They aren't mentioned anywhere in the
current and previous C standards. :-)
</clc-mode>

Seriously though, no preprocessing directives are perfectly topical.
vippstar was talking about the various system specific headers that you
had included in your code. Those _are_ OT and I believe better
addressed in comp.unix.programmer. But your actual question can be
answered here and Walter Roberson did so. Also your method to
conditionally compile the include directives is perfectly fine. That's
how it's done.

Notice that he snipped the part I was addressing to; He *knew* which
part I was talking about, and he *knew* why I called it off-topic.
I'm inclined to believe his typo was intentional as well.
Of course, all these are just assumptions...

[Walter Roberson]

In article <17**********************************@a1g2000hsb.g ooglegroups.com>,
<vi******@gmail.comwrote:

>On May 27, 8:56 pm, "Bill Cunningham" <[e-mail]:

>#ifdef LINUX
#include <unistd.h>
#include <sys/types>
#include <sys/stats.h>
#include <fctnl.h>

>Just what is wrong with you Bill?
Haven't you understood yet such thing is not topical for comp.lang.c?

>#endif

Such things *are* topic to comp.lang.c -- provided that it is
recognized that including any header not defined by the C standard
will result in the inclusion of implementation-defined content,
with implementation-defined results (especially if one of the
C keywords or standard routine names got #define'd into something
unexpected.)

The question posed could be answered just fine under those assumptions.
We don't have to know what is in those headers to answer the question
that was posed: we only have to know what the generic meaning of #include is.

It's not like Bill did something nasty like using #define to try to
splice together a trigraph and use that as part of the target file
name for #include
--
"Okay, buzzwords only. Two syllables, tops." -- Laurie Anderson

[santosh]

vi******@gmail.com wrote:

On May 27, 9:18 pm, santosh <[e-mail]:

>Bill Cunningham wrote:

<[e-mail] in message news:175c11eb-5ef5-4c4b-b9bd-
Haven't you understood yet such thing is not topical for
comp.lang.c?

Why is precrossing directives OT ?

<clc-mode>
"Precrossing directives" _are_ OT. They aren't mentioned anywhere in
the current and previous C standards. :-)
</clc-mode>

Seriously though, no preprocessing directives are perfectly topical.
vippstar was talking about the various system specific headers that
you had included in your code. Those _are_ OT and I believe better
addressed in comp.unix.programmer. But your actual question can be
answered here and Walter Roberson did so. Also your method to
conditionally compile the include directives is perfectly fine.
That's how it's done.

Notice that he snipped the part I was addressing to; He *knew* which
part I was talking about, and he *knew* why I called it off-topic.
I'm inclined to believe his typo was intentional as well.
Of course, all these are just assumptions...

He is by no means a conventional troll and at times he really does seem
genuine enough. He has indicated that he suffers from the after-effects
of some drugs he has been prescribed, and I suppose each respondent has
to accept the explanation or optionally ignore him.

[Keith Thompson]

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
[...]

It's not like Bill did something nasty like using #define to try to
splice together a trigraph and use that as part of the target file
name for #include

Which would be perfectly topical (but the answer would be either "No"
or "Aaaauuuggghhh!").

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Bill Cunningham]

"santosh" <sa*********@gmail.comwrote in message
news:g1**********@registered.motzarella.org...

> Why is precrossing directives OT ?

<clc-mode>
"Precrossing directives" _are_ OT. They aren't mentioned anywhere in
the current and previous C standards. :-)
</clc-mode>

Seriously though, no preprocessing directives are perfectly topical.
vippstar was talking about the various system specific headers that
you had included in your code. Those _are_ OT and I believe better
addressed in comp.unix.programmer. But your actual question can be
answered here and Walter Roberson did so. Also your method to
conditionally compile the include directives is perfectly fine.
That's how it's done.

Notice that he snipped the part I was addressing to; He *knew* which
part I was talking about, and he *knew* why I called it off-topic.
I'm inclined to believe his typo was intentional as well.
Of course, all these are just assumptions...

[snip]

My question was about preprocessor directives. Yes it was a typo. The
headers I posted if they were relevant to the question I understand would be
off topic. They were just an example of using the preprocessor to block out
headers not needed. The question concern #if and #ifdef which seems to be it
looks like now to mean the same thing. #endif also was inquired to.

Bill

[Bill Cunningham]

<vi******@gmail.comwrote in message
news:29**********************************@d45g2000 hsc.googlegroups.com...

Notice that he snipped the part I was addressing to; He *knew* which
part I was talking about, and he *knew* why I called it off-topic.
I'm inclined to believe his typo was intentional as well.
Of course, all these are just assumptions...

irrelevant parts of post deleted. Relevant parts concerning preprocessor
directives included.

Bill

[Bill Cunningham]

"santosh" <sa*********@gmail.comwrote in message
news:g1**********@registered.motzarella.org...

>>Seriously though, no preprocessing directives are perfectly topical.
vippstar was talking about the various system specific headers that
you had included in your code. Those _are_ OT and I believe better
addressed in comp.unix.programmer. But your actual question can be
answered here and Walter Roberson did so. Also your method to
conditionally compile the include directives is perfectly fine.
That's how it's done.

[snip]

So then is it ok to talk about and use examples of #if and #ifdef and so
on. Or is preprocessing directives OT ?

Bill

[Walter Roberson]

In article <y3Z_j.3437$fk.3100@trnddc06>,
Bill Cunningham <no****@nspam.comwrote:

My question was about preprocessor directives. Yes it was a typo. The
headers I posted if they were relevant to the question I understand would be
off topic. They were just an example of using the preprocessor to block out
headers not needed. The question concern #if and #ifdef which seems to be it
looks like now to mean the same thing. #endif also was inquired to.

In this thread you did not ask about #if vs #ifdef . They do not mean
the same thing. For example,

#define FOO 0
#ifdef FOO
/* this section *will* be compiled, because FOO -is- defined. */
#endif
#if FOO
/* this section will *not* be compiled, because FOO's value is 0,
and #if 0 is false */
#endif
#ifdef if
/* this section will *not* be compiled, because the macro if is -not-
defined. */
#endif
#if !if
/* this section *will* be compiled. In a #if line, after all known
macros are expanded, all remaining identifiers have the value 0
substituted, without any consideration as to whether the identifiers
might be C keywords or library functions. With no macro named if,
the line would be equivilent to #if !0 which is #if 1 which is true. */
#endif
--
"The whole history of civilization is strewn with creeds and
institutions which were invaluable at first, and deadly
afterwards." -- Walter Bagehot

[Walter Roberson]

In article <A9Z_j.3439$fk.489@trnddc06>,
Bill Cunningham <no****@nspam.comwrote:

So then is it ok to talk about and use examples of #if and #ifdef and so
on. Or is preprocessing directives OT ?

preprocessing directives are on-topic . There is only a problem if
the specific content of any #include'd non-standard file is relevant
to the question -- though questions about which identifiers are
predefined for specific implementations would also be off-topic
(except for the small number of identifiers documented in the C standard.)
--
"Let me live in my house by the side of the road --
It's here the race of men go by.
They are good, they are bad, they are weak, they are strong
Wise, foolish -- so am I;" -- Sam Walter Foss

[Keith Thompson]

"Bill Cunningham" <no****@nspam.comwrites:
[...]

My question was about preprocessor directives. Yes it was a typo. The
headers I posted if they were relevant to the question I understand would be
off topic. They were just an example of using the preprocessor to block out
headers not needed. The question concern #if and #ifdef which seems to be it
looks like now to mean the same thing. #endif also was inquired to.

No, #if and #ifdef are similar, but they don't mean the same thing.
Consult your text book to learn the difference.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Bill Cunningham]

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote in message
news:g1**********@canopus.cc.umanitoba.ca...

In this thread you did not ask about #if vs #ifdef . They do not mean
the same thing. For example,

#define FOO 0
#ifdef FOO
/* this section *will* be compiled, because FOO -is- defined. */
#endif
#if FOO
/* this section will *not* be compiled, because FOO's value is 0,
and #if 0 is false */
#endif
#ifdef if
/* this section will *not* be compiled, because the macro if is -not-
defined. */
#endif
#if !if
/* this section *will* be compiled. In a #if line, after all known
macros are expanded, all remaining identifiers have the value 0
substituted, without any consideration as to whether the identifiers
might be C keywords or library functions. With no macro named if,
the line would be equivilent to #if !0 which is #if 1 which is true.
*/
#endif

Priceless.

Bill

[Keith Thompson]

"Bill Cunningham" <no****@nspam.comwrites:

I have been thinking about hiding headers from my compiler's
preprocessor and allowing others to be shown. I want to use the most used
and add others is necessary. Would this be how it is properly done. I want
to ask ahead of time because what I do might work but it might not be the
"correct" or standard way.

#include <stdio.h>
#include <stdlib.h>
#ifdef LINUX
#include <unistd.h>
#include <sys/types>
#include <sys/stats.h>
#include <fctnl.h>
#endif

Is the #endif needed at the end of this case ?

One more thing that you didn't ask about (but probably should have):

How do you expect the symbol LINUX to be defined? Since that
identifier must be available for use in programs, an implementation is
not allowed to pre-define it. There may be other symbols that are
predefined (if you're trying to determine whether you're on a Linux
system); which symbols those might be is a question for another forum.

If you're defining it yourself, that's fine, but you didn't show that.

Also, you appear to be trying to write code that will use things
declared in those implementation-defined headers if you're on a Linux
system, but will still compile and work properly otherwise. Such
things are doable, but the nature of the questions you've been asking
here suggest to me that this is a more advanced topic than you're
ready for.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

"Bill Cunningham" <no****@nspam.comwrites:

"santosh" <sa*********@gmail.comwrote in message
news:g1**********@registered.motzarella.org...

>>>Seriously though, no preprocessing directives are perfectly topical.
vippstar was talking about the various system specific headers that
you had included in your code. Those _are_ OT and I believe better
addressed in comp.unix.programmer. But your actual question can be
answered here and Walter Roberson did so. Also your method to
conditionally compile the include directives is perfectly fine.
That's how it's done.

[snip]

So then is it ok to talk about and use examples of #if and #ifdef and so
on. Or is preprocessing directives OT ?

Preprocessing directives are topical. In my opinion, the person who
complained that your orginal post was off-topic overreacted.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[D. Power]

In article <g1**********@canopus.cc.umanitoba.ca>,
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

<snip>

#ifdef if
/* this section will *not* be compiled, because the macro if is -not-
defined. */
#endif

This seems to be an odd use of a keyword, but it seems to work.

#include <stdio.h>

#define if

int main (void)
{
#ifdef if
puts ("It seems to be ok.");
#else
puts ("No go.");
#endif

return 0;
}

Compiles with gcc with the -ansi -pedantic -W -Wall -Wextra switches
with no complaints; it just doesn't look right.

<snip>
--
D. Power
"I hold it to be the inalienable right of anybody to go to hell in his
own way."
-Robert Frost

[Keith Thompson]

"D. Power" <po****@pcisys.net.invalidwrites:

In article <g1**********@canopus.cc.umanitoba.ca>,
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:
<snip>

>#ifdef if
/* this section will *not* be compiled, because the macro if is -not-
defined. */
#endif

This seems to be an odd use of a keyword, but it seems to work.

#include <stdio.h>

#define if

int main (void)
{
#ifdef if
puts ("It seems to be ok.");
#else
puts ("No go.");
#endif

return 0;
}

Compiles with gcc with the -ansi -pedantic -W -Wall -Wextra switches
with no complaints; it just doesn't look right.

"if" isn't a keyword as far as the preprocessor is concerned; it's
just another identifier. Though I agree that the use of "if" in this
context is ugly.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Walter Roberson]

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

>"D. Power" <po****@pcisys.net.invalidwrites:

>In article <g1**********@canopus.cc.umanitoba.ca>,
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

>>#ifdef if
/* this section will *not* be compiled, because the macro if is -not-
defined. */
#endif

>This seems to be an odd use of a keyword, but it seems to work.

>"if" isn't a keyword as far as the preprocessor is concerned; it's
just another identifier. Though I agree that the use of "if" in this
context is ugly.

Keith is correct on both counts -- the preprocesor doesn't know
anything about "keywords" or library functions, or about any of
the types other than the basic arithmetic types of various
sizes (and, I suppose, size_t).

And yes, it is ugly -- its name was chosen specifically to illustrate
the point that *everything* that looks like an identifier (but which
is not a macro), will have 0 substituted in an #if preprocessor statement.

Further example:

#if the + world + is *round* why + do + we + ~ fall + off + while + we + stand + on + our + heads + at + night ? Author : unknown
/* something */
#endif
If I haven't overlooked anything, that should be compilable even if
nothing is #define'd, even though it appears to use the C keywords
if and do and while .
--
"When a scientist is ahead of his times, it is often through
misunderstanding of current, rather than intuition of future truth.
In science there is never any error so gross that it won't one day,
from some perspective, appear prophetic." -- Jean Rostand

[Bill Cunningham]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

"Bill Cunningham" <no****@nspam.comwrites:

> I have been thinking about hiding headers from my compiler's
preprocessor and allowing others to be shown. I want to use the most used
and add others is necessary. Would this be how it is properly done. I
want
to ask ahead of time because what I do might work but it might not be the
"correct" or standard way.

#include <stdio.h>
#include <stdlib.h>
#ifdef LINUX
#include <unistd.h>
#include <sys/types>
#include <sys/stats.h>
#include <fctnl.h>
#endif

Is the #endif needed at the end of this case ?

One more thing that you didn't ask about (but probably should have):

How do you expect the symbol LINUX to be defined? Since that
identifier must be available for use in programs, an implementation is
not allowed to pre-define it. There may be other symbols that are
predefined (if you're trying to determine whether you're on a Linux
system); which symbols those might be is a question for another forum.

If you're defining it yourself, that's fine, but you didn't show that.

Also, you appear to be trying to write code that will use things
declared in those implementation-defined headers if you're on a Linux
system, but will still compile and work properly otherwise. Such
things are doable, but the nature of the questions you've been asking
here suggest to me that this is a more advanced topic than you're
ready for.

Perhaps so but the code above didn't work. This code I wrote did. The
question is did I do it correctly.

#include <stdio.h>
#include <stdlib.h>
#ifdef linux
#ifndef linux
#undef linux
#include <unistd.h>
#include <sys/types.h>
#include <sys/stats.h>
#include <fctnl.h>
#endif
#endif

I compiled a simple program asking sizeof to show through printf the
size of a long double. I haven't defined linux to use those sys call headers
yet though so that part of the header is untested. But the directives
blocked out the mentioned OT headers to compile a simple C program. I
must've did something right.

Bill

[Keith Thompson]

"Bill Cunningham" <no****@nspam.comwrites:

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

>"Bill Cunningham" <no****@nspam.comwrites:

>> I have been thinking about hiding headers from my compiler's
preprocessor and allowing others to be shown. I want to use the most used
and add others is necessary. Would this be how it is properly done. I
want
to ask ahead of time because what I do might work but it might not be the
"correct" or standard way.

#include <stdio.h>
#include <stdlib.h>
#ifdef LINUX
#include <unistd.h>
#include <sys/types>
#include <sys/stats.h>
#include <fctnl.h>
#endif

Is the #endif needed at the end of this case ?

One more thing that you didn't ask about (but probably should have):

How do you expect the symbol LINUX to be defined? Since that
identifier must be available for use in programs, an implementation is
not allowed to pre-define it. There may be other symbols that are
predefined (if you're trying to determine whether you're on a Linux
system); which symbols those might be is a question for another forum.

If you're defining it yourself, that's fine, but you didn't show that.

Also, you appear to be trying to write code that will use things
declared in those implementation-defined headers if you're on a Linux
system, but will still compile and work properly otherwise. Such
things are doable, but the nature of the questions you've been asking
here suggest to me that this is a more advanced topic than you're
ready for.

Perhaps so but the code above didn't work. This code I wrote did. The
question is did I do it correctly.

#include <stdio.h>
#include <stdlib.h>
#ifdef linux
#ifndef linux
#undef linux
#include <unistd.h>
#include <sys/types.h>
#include <sys/stats.h>
#include <fctnl.h>
#endif
#endif

I compiled a simple program asking sizeof to show through printf the
size of a long double. I haven't defined linux to use those sys call headers
yet though so that part of the header is untested. But the directives
blocked out the mentioned OT headers to compile a simple C program. I
must've did something right.

Yes, it should work; it just doesn't make any sense.

You have a "#ifndef linux" nested within a "#ifdef linux". What is
this supposed to accomplish? What is the purpose of the "#undef
linux"?

Under what circumstances, if any, do you expect the symbol "linux" or
"LINUX" to be defined? Do you intend to define it yourself?

Do you intend to write code that uses things declared in those
headers? Is your program going to *depend* on those features?

Based on what you've told us so far, a much simpler solution would be
to omit the #include directives for the system-specific headers,
leaving just this:

#include <stdio.h>
#include <stdlib.h>

What exactly are you trying to accomplish?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Bill Cunningham]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

Yes, it should work; it just doesn't make any sense.

You have a "#ifndef linux" nested within a "#ifdef linux". What is
this supposed to accomplish? What is the purpose of the "#undef
linux"?

Under what circumstances, if any, do you expect the symbol "linux" or
"LINUX" to be defined? Do you intend to define it yourself?

Do you intend to write code that uses things declared in those
headers? Is your program going to *depend* on those features?

Yes I use them too. But they are OT here. I want to write something like
this.

#include "master.h"
#define linux

Then use those non-standard headers with stdio.h and stdlib.h. Otherwise if
linux is not defined.

#include "master.h"

int main(void) {

C code.

}

[Keith Thompson]

"Bill Cunningham" <no****@nspam.comwrites:

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

>Yes, it should work; it just doesn't make any sense.

You have a "#ifndef linux" nested within a "#ifdef linux". What is
this supposed to accomplish? What is the purpose of the "#undef
linux"?

Under what circumstances, if any, do you expect the symbol "linux" or
"LINUX" to be defined? Do you intend to define it yourself?

Do you intend to write code that uses things declared in those
headers? Is your program going to *depend* on those features?

Yes I use them too. But they are OT here. I want to write something like
this.

#include "master.h"
#define linux

Then use those non-standard headers with stdio.h and stdlib.h. Otherwise if
linux is not defined.

#include "master.h"

int main(void) {

C code.

}

Based on what you've told us so far, I'm unable to figure out what
you're trying to do. I asked you several specific questions; you've
answered almost none of them. Rather than telling us what you're
trying to accomplish, you've shown us some pseudo-code of what I
presume is intended to be a solution.

What problem are you trying to solve?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Bill Cunningham]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

What problem are you trying to solve?

In all compilation files include stdio.h and stdlib. When linux is
defined include several non-standard headers at compile time.

Bill

[D. Power]

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

"D. Power" <po****@pcisys.net.invalidwrites:

In article <g1**********@canopus.cc.umanitoba.ca>,
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:
<snip>

#ifdef if
/* this section will *not* be compiled, because the macro if is -not-
defined. */
#endif

This seems to be an odd use of a keyword, but it seems to work.

#include <stdio.h>

#define if

int main (void)
{
#ifdef if
puts ("It seems to be ok.");
#else
puts ("No go.");
#endif

return 0;
}

Compiles with gcc with the -ansi -pedantic -W -Wall -Wextra switches
with no complaints; it just doesn't look right.

"if" isn't a keyword as far as the preprocessor is concerned; it's
just another identifier. Though I agree that the use of "if" in this
context is ugly.

I see, time to read more closely on translation phases in the Standard.
Thank you, and Walter Roberson, for the reply.

--
D. Power
"I hold it to be the inalienable right of anybody to go to hell in his
own way."
-Robert Frost

[Keith Thompson]

"Bill Cunningham" <no****@nspam.comwrites:

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

>What problem are you trying to solve?

In all compilation files include stdio.h and stdlib. When linux is
defined include several non-standard headers at compile time.

No, that's your proposed *solution*. What *problem* are you trying to
solve? How is your program supposed to behave?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Bill Cunningham]

No, that's your proposed *solution*. What *problem* are you trying to

solve? How is your program supposed to behave?

I want one header called master.h that includes all the headers that
have been typed. I am tired of typing them all in one at a time. I wish to
have a header with conditional compilation.

Bill

[vippstar]

On May 28, 4:19 am, "Bill Cunningham" <[e-mail]:

No, that's your proposed *solution*. What *problem* are you trying to
solve? How is your program supposed to behave?

I want one header called master.h that includes all the headers that
have been typed. I am tired of typing them all in one at a time.

Use a proper text editor that does this for you.
clc is not a group to ask about text editors.

[Bill Cunningham]

<vi******@gmail.comwrote in message news:1558c10a-2ddb-4221-a5dc-

Use a proper text editor that does this for you.
clc is not a group to ask about text editors.

huh??

Have you read this thread?

[William Pursell]

On May 28, 2:19 am, "Bill Cunningham" <[e-mail]:

I want one header called master.h that includes all the headers that
have been typed. I am tired of typing them all in one at a time. I wish to
have a header with conditional compilation.

There is a problem with the approach you are taking that should be
considered. It is not really adequate to
use the simple pre-processor check of '#ifdef LINUX'. It would
be more appropriate to do something like: (caveat: it
is IMO totally inappropriate to be doing this at all, but
if you really want to, the following approach will be more
robust)

#ifdef HAVE_SYS_FOO
#include <sys/foo.h>
#endif

The fact that the particular Linux you are using today has
sys/foo.h is not sufficient, and neither you nor the
preprocessor really cares if the system is Linux or not...
only whether or not sys/foo.h can be included. Check for
features, not for the system.

[Keith Thompson]

William Pursell <bi**********@gmail.comwrites:

On May 28, 2:19 am, "Bill Cunningham" <[e-mail]:

> I want one header called master.h that includes all the headers that
have been typed. I am tired of typing them all in one at a time. I wish to
have a header with conditional compilation.

There is a problem with the approach you are taking that should be
considered. It is not really adequate to
use the simple pre-processor check of '#ifdef LINUX'. It would
be more appropriate to do something like: (caveat: it
is IMO totally inappropriate to be doing this at all, but
if you really want to, the following approach will be more
robust)

#ifdef HAVE_SYS_FOO
#include <sys/foo.h>
#endif

The fact that the particular Linux you are using today has
sys/foo.h is not sufficient, and neither you nor the
preprocessor really cares if the system is Linux or not...
only whether or not sys/foo.h can be included. Check for
features, not for the system.

Except that you just might care whether you have the the Linux
sys/foo.h or the Solaris sys/foo.h.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ben Bacarisse]

"Bill Cunningham" <no****@nspam.comwrites:

<vi******@gmail.comwrote in message news:1558c10a-2ddb-4221-a5dc-

>Use a proper text editor that does this for you.
clc is not a group to ask about text editors.

huh??

Have you read this thread?

It is likely he has. He is saying that using conditional compilation
and a big master.h header is not the best way to solve the problem of
being "tired typing all the includes". My editor lets me type #incude
<stdio.husing just a few keys. I can "pull in" an outline C program
to write quick test in just a couple of key strokes[1].

If you go your way, you won't really have a portable programs. There
are too many small differences between in ways systems handle the bit
outside of the C standard.

[1] But since it is Emacs most of my fingers are involved in each
stroke!

--
Ben.

[Bill Cunningham]

"Ben Bacarisse" <be********@bsb.me.ukwrote in >

It is likely he has. He is saying that using conditional compilation

and a big master.h header is not the best way to solve the problem of
being "tired typing all the includes". My editor lets me type #incude
<stdio.husing just a few keys. I can "pull in" an outline C program
to write quick test in just a couple of key strokes[1].

If you go your way, you won't really have a portable programs. There
are too many small differences between in ways systems handle the bit
outside of the C standard.

[1] But since it is Emacs most of my fingers are involved in each
stroke!

I see ok well based on earlier posts in this thread perhaps I
misunderstood. Text editors had not been mentioned to that point in the
thread and I understand they are OT. Unless someone was writing one and they
mentioned their code itself. Then editors would still be OT just not C code.
:)
I was going to use conditional compilation and all these headers as a
learning tool for myself. So I wasn't looking so much at the importance of
portability in the program. The using of non-standard headers itself would
destroy portability.

Bill

[Bill Cunningham]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

>There is a problem with the approach you are taking that should be
considered. It is not really adequate to
use the simple pre-processor check of '#ifdef LINUX'. It would
be more appropriate to do something like: (caveat: it
is IMO totally inappropriate to be doing this at all, but
if you really want to, the following approach will be more
robust)

#ifdef HAVE_SYS_FOO
#include <sys/foo.h>
#endif

The fact that the particular Linux you are using today has
sys/foo.h is not sufficient, and neither you nor the
preprocessor really cares if the system is Linux or not...
only whether or not sys/foo.h can be included. Check for
features, not for the system.

Except that you just might care whether you have the the Linux
sys/foo.h or the Solaris sys/foo.h.

I only wanted to do this conditional compilation thing as a personal
learning tool for preprocessor directives. Even using non-standard headers
destroys portability which is all important we all understand. It was to
learn and save me keystrokes.

Bill

[Keith Thompson]

"Bill Cunningham" <no****@nspam.comwrites:

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

>>There is a problem with the approach you are taking that should be
considered. It is not really adequate to
use the simple pre-processor check of '#ifdef LINUX'. It would
be more appropriate to do something like: (caveat: it
is IMO totally inappropriate to be doing this at all, but
if you really want to, the following approach will be more
robust)

#ifdef HAVE_SYS_FOO
#include <sys/foo.h>
#endif

The fact that the particular Linux you are using today has
sys/foo.h is not sufficient, and neither you nor the
preprocessor really cares if the system is Linux or not...
only whether or not sys/foo.h can be included. Check for
features, not for the system.

Except that you just might care whether you have the the Linux
sys/foo.h or the Solaris sys/foo.h.

I only wanted to do this conditional compilation thing as a personal
learning tool for preprocessor directives. Even using non-standard headers
destroys portability which is all important we all understand. It was to
learn and save me keystrokes.

Saving you keystrokes isn't an issue as long as copy-and-paste exists.

As for portability, there are 3 classes of programs. (I don't claim
this is exhaustive or definitive, just relevant to what you're doing.)

1. Portable programs that depend only on standard headers.

2. Non-portable programs that depend on non-standard headers; these
will compile and run only on a particular system (e.g., Linux).

3. Programs that are a mixture of the above. A program might
conditionally include one or more system-specific headers. Any code
that uses features defined in those headers would itself have to be
conditionalized (surrounded by #if ... #endif or #ifdef ... #endif).
For example, a program might provide a textual interface on all
systems, and additionally provide a GUI only on systems where it's
available.

The stuff you're trying to do:

#include <stdio.h>
#ifdef linux
#include <sys/foo.h>
#endif

makes sense for the third class of programs, but I don't believe
that's what you're trying to do -- and if it is, I suggest that you're
in over your head, given the difficulties you've had mastering the
basic concepts of portable standard C.

Personally, I'm not a big fan of these "everything.h" headers that
just include all the other headers you might or might not need. If a
translation unit uses printf(), then *that* source file should have
"#include <stdio.h>", and likewise for any other standard or
non-standard headers.

Incidentally, portability isn't "all important". It's one among many
important attributes that a program can have. If you need to do
something system-specific, go ahead and do it; your program isn't
going to be portable to other systems, but it doesn't need to be.

Non-portable code isn't necessarily bad, it's just off-topic here,
because we try to discuss portable aspects of the language as defined
by thes standard. If you have Unix-specific questions, for example,
you can ask them in comp.unix.programmer.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Chris Thomasson]

"Bill Cunningham" <no****@nspam.comwrote in message
news:vXX_j.5092$nx6.2636@trnddc03...

I have been thinking about hiding headers from my compiler's
preprocessor and allowing others to be shown. I want to use the most used
and add others is necessary. Would this be how it is properly done. I want
to ask ahead of time because what I do might work but it might not be the
"correct" or standard way.

#include <stdio.h>
#include <stdlib.h>
#ifdef LINUX
#include <unistd.h>
#include <sys/types>
#include <sys/stats.h>
#include <fctnl.h>
#endif

Is the #endif needed at the end of this case ?

yes.
Okay. I don't know if this is what your looking for, but when I need to
create a library that needs to run on several platforms and make use of
system specific API's I generally do something like this:
Lets say that I need to have conditional compilation predicated on what
architecture the code is compiling under... Say x86 and SPARC. I would
create three files... First two arch specific headers:



arch_x86.h
----------------------------
#include <limits.h>

/* System Specific */
#define ARCH_X86_WORD_SIZE (32 / CHAR_BIT)
typedef int arch_x86_word;
typedef char ARCH_X86_STATIC_ASSERT[
sizeof(arch_x86_word) == ARCH_X86_WORD_SIZE ? 1 : -1
];

static arch_x86_word
arch_x86_atomic_swap(
arch_x86_word volatile* const _pthis,
arch_x86_word xchg
) {
[arch specific asm];
}
/* Abstract */
#define ARCH_WORD_SIZE ARCH_X86_WORD_SIZE

typedef arch_x86_word arch_word;

#define arch_atomic_swap arch_x86_atomic_swap


arch_sparc.h
----------------------------
#include <limits.h>

/* System Specific */
#define ARCH_SPARC_WORD_SIZE (32 / CHAR_BIT)
typedef int arch_sparc_word;
typedef char ARCH_SPARC_STATIC_ASSERT[
sizeof(arch_sparc_word) == ARCH_SPARC_WORD_SIZE ? 1 : -1
];

static arch_sparc_word
arch_sparc_atomic_swap(
arch_sparc_word volatile* const _pthis,
arch_sparc_word xchg
) {
[arch specific asm];
}
/* Abstract */
#define ARCH_WORD_SIZE ARCH_SPARC_WORD_SIZE

typedef arch_sparc_word arch_word;

#define arch_atomic_swap arch_sparc_atomic_swap


and finally an abstract header:

arch.h
----------------------------
#if defined(_X86_)
# include "arch_x86.h"
#elif defined(__sparc__)
# include "arch_sparc.h"
#else
# error ARCH NOT SUPPORTED!
#endif



Now a user can just include "arch.h" to get at the architecture dependant
abstraction...
#include "arch.h"
#include <assert.h>

static arch_word volatile g_word = 0;

int main() {
arch_word const old = arch_atomic_swap(&g_word, 1);
assert(old == 0);
return 0;
}

Is that even close to what your trying to do? Please note that this
simplistic technique can also be use to abstract OS specific API's away into
common base...

[Richard Heathfield]

[I know I'm preaching to the choir here, but maybe some non-choristers will
drop by and pick up a few pearls of what I am pleased to call "wisdom".]

Keith Thompson said:

<snip>

Incidentally, portability isn't "all important". It's one among many
important attributes that a program can have.

Right...

If you need to do
something system-specific, go ahead and do it; your program isn't
going to be portable to other systems, but it doesn't need to be.

....and less right. <g>

We can't tell whether a program needs to be portable purely on the basis of
whether we need it to do something system-specific. Rather, what we have
here is two conflicting characteristics:

(a) portability, and
(b) system-specific features.

If the portability requirement is sufficiently high, the program will
simply have to do without the system-specific features (SSFs for short).
Conversely, if the need for those SSFs is sufficiently high, the program
will necessarily be less portable than would otherwise be the case.

It may be that the portability requirement is present but limited - for
example, the program may need to run on both VM/CMS and MacOS, but no
other platform, in which case there is no particular problem with using
SSFs that happen to be available on both platforms.

The problem with using SSFs even with programs for which the portability
need is perceived to be low is simply that useful programs tend to outlive
their platforms - hence the truism that any sufficiently useful program
*will*, one day, be ported. Making this easier is therefore an important
criterion when designing a "sufficiently useful program".

To maximise portability, use only those features of C that are guaranteed
to be available in all implementations, even freestanding implementations.

That is quite a high barrier, of course. If we're prepared to eschew
portability to freestanding implementations, we can extend our range of
features to include those that the Standard guarantees to be available on
all hosted implementations.

If that is still too high a price to pay, we can avail ourselves of
features guaranteed by other standards (e.g. POSIX), knowing as we do that
we are now limiting ourselves to POSIX-conforming systems.

And if that is /still/ too high a price, then we can at least isolate the
system-specific parts of our code, providing an interface to them that can
remain constant across rewrites of the underlying SSF-using code.

>
Non-portable code isn't necessarily bad, it's just off-topic here,

True, but I think it's reasonable to consider as topical the ways in which
we might isolate SSF usage, in ISO C.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

[I know I'm preaching to the choir here, but maybe some non-choristers will
drop by and pick up a few pearls of what I am pleased to call "wisdom".]

Keith Thompson said:

<snip>

>Incidentally, portability isn't "all important". It's one among many
important attributes that a program can have.

Right...

>If you need to do
something system-specific, go ahead and do it; your program isn't
going to be portable to other systems, but it doesn't need to be.

...and less right. <g>

We can't tell whether a program needs to be portable purely on the basis of
whether we need it to do something system-specific. Rather, what we have
here is two conflicting characteristics:

(a) portability, and
(b) system-specific features.

Agreed. My phrase "If you *need* to do something system-specific" was
intended to cover that; thank you for saying more clearly than I did
that it's a tradeoff.

[snip lots of good stuff]

>Non-portable code isn't necessarily bad, it's just off-topic here,

True, but I think it's reasonable to consider as topical the ways in which
we might isolate SSF usage, in ISO C.

Agreed.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Bill Cunningham wrote:

>
I have been thinking about hiding headers from my compiler's
preprocessor and allowing others to be shown. I want to use the
most used and add others is necessary. Would this be how it is
properly done. I want to ask ahead of time because what I do
might work but it might not be the "correct" or standard way.

#include <stdio.h>
#include <stdlib.h>
#ifdef LINUX
#include <unistd.h>
#include <sys/types>
#include <sys/stats.h>
#include <fctnl.h>
#endif

Is the #endif needed at the end of this case ?

Yes, the #endif is needed. No, this is a terrible idea. Only
#include the headers you need. That depends on the routines,
macros, etc. you call. Everything you have listed in the #ifdef
section above is undefined in standard C, and off-topic on this
newsgroup.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

** Posted from http://www.teranews.com **