preprocessing statements

Discussion in 'C Programming' started by Bill Cunningham, May 27, 2008.

  1. 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
     
    Bill Cunningham, May 27, 2008
    #1
    1. Advertising

  2. In article <vXX_j.5092$nx6.2636@trnddc03>,
    Bill Cunningham <> 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
     
    Walter Roberson, May 27, 2008
    #2
    1. Advertising

  3. Bill Cunningham

    Guest

    On May 27, 8:56 pm, "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.

    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?
     
    , May 27, 2008
    #3
  4. <> 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, May 27, 2008
    #4
  5. Bill Cunningham

    santosh Guest

    Bill Cunningham wrote:

    >
    > <> 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.
     
    santosh, May 27, 2008
    #5
  6. Bill Cunningham

    Guest

    On May 27, 9:18 pm, santosh <> wrote:
    > Bill Cunningham wrote:
    >
    > > <> 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...
     
    , May 27, 2008
    #6
  7. Bill Cunningham

    santosh Guest

    wrote:

    > On May 27, 9:18 pm, santosh <> wrote:
    >> Bill Cunningham wrote:
    >>
    >> > <> 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.
     
    santosh, May 27, 2008
    #7
  8. In article <>,
    <> wrote:
    >On May 27, 8:56 pm, "Bill Cunningham" <> 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
     
    Walter Roberson, May 27, 2008
    #8
  9. -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) <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, May 27, 2008
    #9
  10. "santosh" <> wrote in message
    news:g1hl26$rje$...

    >>> > 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, May 27, 2008
    #10
  11. <> wrote in message
    news:...

    > 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, May 27, 2008
    #11
  12. "santosh" <> wrote in message
    news:g1hl26$rje$...

    >>> 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
     
    Bill Cunningham, May 27, 2008
    #12
  13. In article <y3Z_j.3437$fk.3100@trnddc06>,
    Bill Cunningham <> wrote:

    > 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, May 27, 2008
    #13
  14. In article <A9Z_j.3439$fk.489@trnddc06>,
    Bill Cunningham <> wrote:

    > 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
     
    Walter Roberson, May 27, 2008
    #14
  15. "Bill Cunningham" <> writes:
    [...]
    > 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) <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, May 27, 2008
    #15
  16. "Walter Roberson" <-cnrc.gc.ca> wrote in message
    news:g1hn6u$nhj$...

    > 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
     
    Bill Cunningham, May 27, 2008
    #16
  17. "Bill Cunningham" <> writes:
    > 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) <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, May 27, 2008
    #17
  18. "Bill Cunningham" <> writes:
    > "santosh" <> wrote in message
    > news:g1hl26$rje$...
    >
    >>>> 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) <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, May 27, 2008
    #18
  19. "D. Power" <> writes:
    > In article <g1hn6u$nhj$>,
    > -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) <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, May 27, 2008
    #19
  20. In article <>,
    Keith Thompson <> wrote:
    >"D. Power" <> writes:
    >> In article <g1hn6u$nhj$>,
    >> -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
     
    Walter Roberson, May 27, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Neil Zanella
    Replies:
    8
    Views:
    1,236
    mfmehdi
    Oct 20, 2006
  2. Dave
    Replies:
    2
    Views:
    362
    Jack Klein
    Nov 3, 2003
  3. Harry George
    Replies:
    6
    Views:
    446
    Bart Nessux
    Feb 23, 2004
  4. Vince
    Replies:
    12
    Views:
    779
    Martin Gregorie
    Jan 21, 2008
  5. John Crichton
    Replies:
    6
    Views:
    290
    John Crichton
    Jul 12, 2010
Loading...

Share This Page