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]

#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

 

[vippstar]

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]

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

Why is precrossing directives OT ?

Bill

 

[santosh]

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]

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

 

[santosh]

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.

 

[Walter Roberson]

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

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

 

[Keith Thompson]

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!").

 

[Bill Cunningham]

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

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]

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

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

 

[Walter Roberson]

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

 

[Keith Thompson]

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.

 

[Bill Cunningham]

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]

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]

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

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.

 

[Walter Roberson]

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