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

In article <vXX_j.5092$nx6.2636@trnddc03>,
Bill Cunningham <nospam@nspam.com> wrote:

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

On May 27, 8:56 pm, "Bill Cunningham" <nos...@nspam.com> 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.
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?

<vippstar@gmail.com> wrote 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

Bill Cunningham wrote:

>
> <vippstar@gmail.com> wrote 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.

On May 27, 9:18 pm, santosh <santosh....@gmail.com> wrote:
> Bill Cunningham wrote:
>
> > <vipps...@gmail.com> wrote 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...

vippstar@gmail.com wrote:

> On May 27, 9:18 pm, santosh <santosh....@gmail.com> wrote:
>> Bill Cunningham wrote:
>>
>> > <vipps...@gmail.com> wrote 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.

In article <175c11eb-5ef5-4c4b-b9bd-8732f61584fa@a1g2000hsb.googlegroups.com>,
<vippstar@gmail.com> wrote:
>On May 27, 8:56 pm, "Bill Cunningham" <nos...@nspam.com> wrote:

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