Re: standard pragma's?

Discussion in 'C Programming' started by Mr. Buffoon, Oct 6, 2010.

  1. Mr. Buffoon

    Mr. Buffoon Guest

    Almost any kompiler has #pragma pack(x);
    so sonsider it a standard-feature!
    Mr. Buffoon, Oct 6, 2010
    #1
    1. Advertising

  2. "Mr. Buffoon" <> writes:
    > Almost any kompiler has #pragma pack(x);
    > so sonsider it a standard-feature!


    You are mistaken; #pragma pack is not a standard feature.

    --
    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, Oct 6, 2010
    #2
    1. Advertising

  3. Mr. Buffoon

    Mr. Buffoon Guest

    Am 06.10.2010 21:16, schrieb Keith Thompson:

    >> Almost any kompiler has #pragma pack(x);
    >> so sonsider it a standard-feature!


    > You are mistaken; #pragma pack is not a standard feature.


    *plonk*
    Mr. Buffoon, Oct 6, 2010
    #3
  4. Mr. Buffoon

    Seebs Guest

    On 2010-10-06, Mr. Buffoon <> wrote:
    > Almost any kompiler has #pragma pack(x);


    That's an interesting claim. Did you have specific compilers in mind
    when you wrote it?

    > so sonsider it a standard-feature!


    This is not good advice. You shouldn't consider something standard because
    several compilers have it, less still because some guy on the Internet tells
    you that "almost any kompiler" has it.

    .... Wait. I'm trying to correct a post by someone called "Mr. Buffoon".

    Clearly, I am not yet recovered from this cold.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
    Seebs, Oct 6, 2010
    #4
  5. Mr. Buffoon

    Default User Guest

    "Seebs" <> wrote in message
    news:...
    > On 2010-10-06, Mr. Buffoon <> wrote:
    >> Almost any kompiler has #pragma pack(x);


    >> so sonsider it a standard-feature!

    >
    > You shouldn't consider something standard because
    > several compilers have it, less still because some guy on the Internet
    > tells
    > you that "almost any kompiler" has it.



    To be fair, he did request that you "sonsider" it.



    Brian
    --
    Day 609 of the "no grouchy usenet posts" project.
    Default User, Oct 6, 2010
    #5
  6. In article <>,
    Default User <> wrote:
    >"Seebs" <> wrote in message
    >news:...
    >> On 2010-10-06, Mr. Buffoon <> wrote:
    >>> Almost any kompiler has #pragma pack(x);

    >
    >>> so sonsider it a standard-feature!

    >>
    >> You shouldn't consider something standard because
    >> several compilers have it, less still because some guy on the Internet
    >> tells
    >> you that "almost any kompiler" has it.

    >
    >
    >To be fair, he did request that you "sonsider" it.


    http://redwing.hutman.net/~mreed/warriorshtm/bigdogmetoo.htm

    --
    Windows 95 n. (Win-doze): A 32 bit extension to a 16 bit user interface for
    an 8 bit operating system based on a 4 bit architecture from a 2 bit company
    that can't stand 1 bit of competition.

    Modern day upgrade --> Windows XP Professional x64: Windows is now a 64 bit
    tweak of a 32 bit extension to a 16 bit user interface for an 8 bit
    operating system based on a 4 bit architecture from a 2 bit company that
    can't stand 1 bit of competition.
    Kenny McCormack, Oct 7, 2010
    #6
  7. Mr. Buffoon

    Default User Guest

    "John Smith" <> wrote in message
    news:...
    > Default User wrote:
    >> "Seebs" <> wrote in message
    >> news:...
    >>> On 2010-10-06, Mr. Buffoon <> wrote:
    >>>> Almost any kompiler has #pragma pack(x);

    >>
    >>>> so sonsider it a standard-feature!
    >>> You shouldn't consider something standard because
    >>> several compilers have it, less still because some guy on the Internet
    >>> tells
    >>> you that "almost any kompiler" has it.

    >>
    >>
    >> To be fair, he did request that you "sonsider" it.


    > Let's hope for 610. We'll C.


    Piece of cake.



    Brian
    --
    Day 610 of the "no grouchy usenet posts" project.
    Default User, Oct 7, 2010
    #7
  8. John Smith wrote:
    > Mr. Buffoon wrote:
    >> Almost any kompiler has #pragma pack(x);
    >> so sonsider it a standard-feature!

    >
    > Sagt man "kom pee' luh" for compiler?


    Here, we say "compiler" (standard English word) or, less frequent,
    "Übersetzer" (German for "translator").


    Stefan
    Stefan Reuther, Oct 7, 2010
    #8
  9. John Smith wrote:

    > Mr. Buffoon wrote:
    >> Almost any kompiler has #pragma pack(x);
    >> so sonsider it a standard-feature!


    IBTD -- RMS, for instance, long resisted to add #pragma to GCC
    for two reasons: you can't write #defines that produce #pragmas,
    and the #pragmas themselves are less than portable and may lead
    to weird results w/out any error or warning message whatsoever.

    This has changed some time ago, since the new keyword "_Pragma"
    has been introduced (so you can now write #defines producing
    _Pragmas), but still, "#pragma pack" isn't part of the official
    C standard (please correct me if I'm wrong). So, while quite a
    few compilers with a considerable market share /do/ support the
    "#pragma pack" directive, many others do /not/ (or provide this
    behaviour through other means), so it's too early to consider it
    a real "standard feature".

    > Sagt man "kom pee' luh" for compiler?


    Not really; it's usually the english word "compiler". Long time
    ago (70s/80s) one could also (rarely!) read the word "Kompiler"
    in certain publications, but I guess the pronouncation was still
    english; it didn't prevail and never made it to the mainstream.
    So, it's either "Compiler" (pronounced as in english, but written
    with a capital "C", as it's a noun), or "Ãœbersetzer", the german
    word for "translator". But we mainly say "Compiler" when we're
    talking about computer languages. However, we call the /process/
    of translating a program written in one computer language to some
    other computer language (incl. assembler or actual machine code)
    "Kompilieren" ("'com'pee'lee-ren" -- the apostrophes denote where
    to stress the parts of the word; "ren" just as in "renegade").

    > The first C texts that I read in German used the word "Kompilator."


    I've never actually heard that word, but it sounds funny! To the
    typical German it wouldn'n make any sense, but it rhymes to, e.g.,
    "Ventilator" (fan) -- which would be especially confusing if you'd
    say "Ich habe gerade den Kompilator angeworfen" ("I've just started
    the kompilator") -- but nothing really happens... ;-)

    > I very much enjoy the Janich and Schreiner translation of K&R2.
    > One thing that's different about the "reservierte Worte," is that
    > they're all in a different language: english.


    Yes, they indeed did a really good job! But given "Axel T's" Unix/C
    experience and being a german professor in the U.S., this is not too
    much of a surprise, or is it? :)

    > Gruss aus New Mexiko,


    Viele Grüße zurück aus Deutschland!

    |Oh, BTW: as this is both, about C and the German language w/ repect
    to C, I've omitted the F2-header; please feel free to adjust it for
    f'ups, if any. To further discuss the "german aspects" of this
    matter, I'd suggest posting a F2/XP to "de.etc.sprache.misc".]


    Cheers,
    mike
    Michael Schumacher, Oct 7, 2010
    #9
  10. Mr. Buffoon

    Mr. Buffoon Guest

    Am 08.10.2010 00:10, schrieb Michael Schumacher:

    > This has changed some time ago, since the new keyword "_Pragma"
    > has been introduced (so you can now write #defines producing
    > _Pragmas), but still, "#pragma pack" isn't part of the official
    > C standard (please correct me if I'm wrong). So, while quite a
    > few compilers with a considerable market share /do/ support the
    > "#pragma pack" directive, many others do /not/ (or provide this
    > behaviour through other means), so it's too early to consider it
    > a real "standard feature".


    Falsch, setzen, sechs!!!
    Mr. Buffoon, Oct 7, 2010
    #10
  11. Dropping de.comp.lang.c

    Michael Schumacher <> writes:
    [...]
    > IBTD -- RMS, for instance, long resisted to add #pragma to GCC
    > for two reasons: you can't write #defines that produce #pragmas,
    > and the #pragmas themselves are less than portable and may lead
    > to weird results w/out any error or warning message whatsoever.
    >
    > This has changed some time ago, since the new keyword "_Pragma"
    > has been introduced (so you can now write #defines producing
    > _Pragmas), but still, "#pragma pack" isn't part of the official
    > C standard (please correct me if I'm wrong).


    You're right, "#pragma pack" is not defined by any version of the
    C standard.

    Apparently gcc supports it "[f]or compatibility with Win32". It takes
    an argument, a small power of two that specifies the alignment
    (I wouldn't be surprised if other compilers support an incompatible
    #pragma with the same name).

    All standard-defined #pragmas are of the form:

    #pragma STDC ...

    As of C99, the standard pragmas are:
    #pragma STDC FP_CONTRACT on-off-switch
    #pragma STDC FENV_ACCESS on-off-switch
    #pragma STDC CX_LIMITED_RANGE on-off-switch
    where on-off-switch is one of:
    ON OFF DEFAULT

    > So, while quite a
    > few compilers with a considerable market share /do/ support the
    > "#pragma pack" directive, many others do /not/ (or provide this
    > behaviour through other means), so it's too early to consider it
    > a real "standard feature".


    Agreed -- except that I wouldn't say it's "too early". The
    "#pragma pack" directive is simply non-standard. Something like
    it *might* be added to a future standard, but I know of no serious
    proposals to do so. In particular, the latest C201x draft N1494)
    doesn't mention it.

    [...]

    --
    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, Oct 7, 2010
    #11
  12. Mr. Buffoon wrote:

    > Am 08.10.2010 00:10, schrieb Michael Schumacher:
    >
    >> This has changed some time ago, since the new keyword "_Pragma"
    >> has been introduced (so you can now write #defines producing
    >> _Pragmas), but still, "#pragma pack" isn't part of the official
    >> C standard (please correct me if I'm wrong). So, while quite a
    >> few compilers with a considerable market share /do/ support the
    >> "#pragma pack" directive, many others do /not/ (or provide this
    >> behaviour through other means), so it's too early to consider it
    >> a real "standard feature".

    >
    > Falsch, setzen, sechs!!!


    Du möchtest etwas Sinnvolles zu diesem Thema beitragen? Nur zu...!


    mike
    Michael Schumacher, Oct 8, 2010
    #12
  13. Keith Thompson wrote:

    > Michael Schumacher <> writes:
    > [...]
    >> So, while quite a
    >> few compilers with a considerable market share /do/ support the
    >> "#pragma pack" directive, many others do /not/ (or provide this
    >> behaviour through other means), so it's too early to consider it
    >> a real "standard feature".

    >
    > Agreed -- except that I wouldn't say it's "too early". The
    > "#pragma pack" directive is simply non-standard. Something like
    > it *might* be added to a future standard, but I know of no serious
    > proposals to do so. In particular, the latest C201x draft N1494)
    > doesn't mention it.


    And I'd be as surprised as my neighbor's dog if it ever will... ;-)
    That's because I simply can't imagine a portable "pack" directive-

    Frankly & IMNSHO, using "pack" (where it's available) is pretty much
    of a hack -- sure, it might come in handy when you have to deal with
    a given problem on a particular platform, but it's also almost /never/
    portable, plus it doesn't fix potential byte-sex problems, so you're
    probably better off writing specialized "access functions" for these
    purposes. Well, that's at least /my/ experience -- YMMV... :)


    mike
    Michael Schumacher, Oct 8, 2010
    #13
  14. On 7 Oct, 23:50, Keith Thompson <> wrote:
    > Dropping de.comp.lang.c
    > Michael Schumacher <> writes:


    <snip>

    > >                                               So, while quite a
    > > few compilers with a considerable market share /do/ support the
    > > "#pragma pack" directive, many others do /not/ (or provide this
    > > behaviour through other means), so it's too early to consider it
    > > a real "standard feature".

    >
    > Agreed -- except that I wouldn't say it's "too early".  The
    > "#pragma pack" directive is simply non-standard.  Something like
    > it *might* be added to a future standard, but I know of no serious
    > proposals to do so.  In particular, the latest C201x draft N1494)
    > doesn't mention it.


    isn't #pragma pack hard (or very expensive) to implement on some
    architectures?
    Nick Keighley, Oct 8, 2010
    #14
  15. Michael Schumacher <> writes:
    > Keith Thompson wrote:
    >> Michael Schumacher <> writes:
    >> [...]
    >>> So, while quite a
    >>> few compilers with a considerable market share /do/ support the
    >>> "#pragma pack" directive, many others do /not/ (or provide this
    >>> behaviour through other means), so it's too early to consider it
    >>> a real "standard feature".

    >>
    >> Agreed -- except that I wouldn't say it's "too early". The
    >> "#pragma pack" directive is simply non-standard. Something like
    >> it *might* be added to a future standard, but I know of no serious
    >> proposals to do so. In particular, the latest C201x draft N1494)
    >> doesn't mention it.

    >
    > And I'd be as surprised as my neighbor's dog if it ever will... ;-)
    > That's because I simply can't imagine a portable "pack" directive-
    >
    > Frankly & IMNSHO, using "pack" (where it's available) is pretty much
    > of a hack -- sure, it might come in handy when you have to deal with
    > a given problem on a particular platform, but it's also almost /never/
    > portable, plus it doesn't fix potential byte-sex problems, so you're
    > probably better off writing specialized "access functions" for these
    > purposes. Well, that's at least /my/ experience -- YMMV... :)


    In principle, C *could* add a "#pragma pack" or similar feature whose
    purpose is to give a hint to the compiler that it should optimize
    layouts for space rather than speed of access. That's what Pascal's
    "packed record" and Ada's "pragma Pack(Type_Name)" do.

    Such a feature would not be particularly useful for imposing a specified
    layout, and on many implementations it would probably be ignored (since
    compilers often choose the tightest layout compatible with alignment
    requirements anyway). It might make be useful on platforms where
    misaligned accesses are merely slower than aligned access.

    --
    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, Oct 8, 2010
    #15
  16. Nick Keighley <> writes:
    > On 7 Oct, 23:50, Keith Thompson <> wrote:
    >> Dropping de.comp.lang.c
    >> Michael Schumacher <> writes:

    >
    > <snip>
    >
    >> >                                               So, while quite a
    >> > few compilers with a considerable market share /do/ support the
    >> > "#pragma pack" directive, many others do /not/ (or provide this
    >> > behaviour through other means), so it's too early to consider it
    >> > a real "standard feature".

    >>
    >> Agreed -- except that I wouldn't say it's "too early".  The
    >> "#pragma pack" directive is simply non-standard.  Something like
    >> it *might* be added to a future standard, but I know of no serious
    >> proposals to do so.  In particular, the latest C201x draft N1494)
    >> doesn't mention it.

    >
    > isn't #pragma pack hard (or very expensive) to implement on some
    > architectures?


    It depends on what it's defined to do. If it just means "optimize
    layout for space rather than time", it's trivial: just ignore it.

    If it requires, for example:

    offsetof(struct {char c; int i;}, i)) == 1

    then it becomes much more difficult on some platforms. If the member
    i is misaligned, think about passing its address to a function that
    takes an int* argument; that function has no way of knowing that
    its argument might be misaligned, and has to assume the worst.

    I just tried at test case with gcc on SPARC, which has strict
    alignment requirements. The compiler quietly accepted a
    "#pragma pack(1)" and put the int member at an offset of 1; the
    program died at run time with a bus error. I'd be much happier if
    it just rejected the #pragma.

    I think that particular form of #pragma was designed for x86-like
    systems, where misaligned accesses just slow things down.

    --
    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, Oct 8, 2010
    #16
  17. Mr. Buffoon

    FredK Guest

    "Keith Thompson" <> wrote in message
    news:...
    > Michael Schumacher <> writes:
    >> Keith Thompson wrote:
    >>> Michael Schumacher <> writes:
    >>> [...]
    >>>> So, while quite a
    >>>> few compilers with a considerable market share /do/ support the
    >>>> "#pragma pack" directive, many others do /not/ (or provide this
    >>>> behaviour through other means), so it's too early to consider it
    >>>> a real "standard feature".
    >>>
    >>> Agreed -- except that I wouldn't say it's "too early". The
    >>> "#pragma pack" directive is simply non-standard. Something like
    >>> it *might* be added to a future standard, but I know of no serious
    >>> proposals to do so. In particular, the latest C201x draft N1494)
    >>> doesn't mention it.

    >>
    >> And I'd be as surprised as my neighbor's dog if it ever will... ;-)
    >> That's because I simply can't imagine a portable "pack" directive-
    >>
    >> Frankly & IMNSHO, using "pack" (where it's available) is pretty much
    >> of a hack -- sure, it might come in handy when you have to deal with
    >> a given problem on a particular platform, but it's also almost /never/
    >> portable, plus it doesn't fix potential byte-sex problems, so you're
    >> probably better off writing specialized "access functions" for these
    >> purposes. Well, that's at least /my/ experience -- YMMV... :)

    >
    > In principle, C *could* add a "#pragma pack" or similar feature whose
    > purpose is to give a hint to the compiler that it should optimize
    > layouts for space rather than speed of access. That's what Pascal's
    > "packed record" and Ada's "pragma Pack(Type_Name)" do.
    >
    > Such a feature would not be particularly useful for imposing a specified
    > layout, and on many implementations it would probably be ignored (since
    > compilers often choose the tightest layout compatible with alignment
    > requirements anyway). It might make be useful on platforms where
    > misaligned accesses are merely slower than aligned access.
    >


    Actually, it serves several purposes.

    1) To be able to define a structure that is already carved in stone, for
    example a network packet format that was designed for space. Or a legacy
    structure that is shared with legacy code. Before RISC hardware exposed the
    inherent problems with poorly aligned data, there were compilers and
    programmers who didn't pay any attention to alignment and generated
    unaligned structure layouts.

    2) Creating structures to map hardware registers. Usually old hardware,
    since today hardware registers tend to be at least 32-bit aligned and well
    aligned. Nonetheless there are many old cards that were a hodge podge. I
    seldom used this, because there can be other restrictions that make it hard
    to use.

    3) Making sure that the layout of a shared structure is exact - because it
    will be accessed by things not written in C or compiled by the same C
    compiler for example. This requires the programmer to take on the
    responsibility for proper alignment. Of course, in those cases I use a
    seperate tool that is language independent and can generate the proper
    definitions for multiple languages.

    For a generic C program that isn't doing any of this, packing is silly. Let
    the compiler handle it and optimize the layout.
    FredK, Oct 8, 2010
    #17
  18. Mr. Buffoon

    FredK Guest

    "Keith Thompson" <> wrote in message
    news:...
    > Nick Keighley <> writes:
    >> On 7 Oct, 23:50, Keith Thompson <> wrote:
    >>> Dropping de.comp.lang.c
    >>> Michael Schumacher <> writes:


    [...]

    >
    > I just tried at test case with gcc on SPARC, which has strict
    > alignment requirements. The compiler quietly accepted a
    > "#pragma pack(1)" and put the int member at an offset of 1; the
    > program died at run time with a bus error. I'd be much happier if
    > it just rejected the #pragma.
    >


    It's a bad compiler that knows it has a misaligned int, and yet doesn't
    generate the proper code to extract it or write it (in the absence of
    volatile). Perhaps it's just a very old compiler. I knew of a UNIX kernel
    that used a very old compiler for it's drivers just because their "current"
    compiler didn't have a proper hardware-specific volatile implementation and
    would act just like you report.
    FredK, Oct 8, 2010
    #18
  19. Mr. Buffoon

    Ian Collins Guest

    On 10/ 9/10 08:23 AM, Keith Thompson wrote:
    > Nick Keighley<> writes:
    >>
    >> isn't #pragma pack hard (or very expensive) to implement on some
    >> architectures?

    >
    > It depends on what it's defined to do. If it just means "optimize
    > layout for space rather than time", it's trivial: just ignore it.
    >
    > If it requires, for example:
    >
    > offsetof(struct {char c; int i;}, i)) == 1
    >
    > then it becomes much more difficult on some platforms. If the member
    > i is misaligned, think about passing its address to a function that
    > takes an int* argument; that function has no way of knowing that
    > its argument might be misaligned, and has to assume the worst.
    >
    > I just tried at test case with gcc on SPARC, which has strict
    > alignment requirements. The compiler quietly accepted a
    > "#pragma pack(1)" and put the int member at an offset of 1; the
    > program died at run time with a bus error. I'd be much happier if
    > it just rejected the #pragma.
    >
    > I think that particular form of #pragma was designed for x86-like
    > systems, where misaligned accesses just slow things down.


    This (odd alignments on Sparc) is a classic case where packing is
    possible, but expensive. There are compiler options (at least with Sun
    cc) to get the correct behaviour, ranging form generating the
    appropriate load/store sequences to installing a handler for bus error
    traps.

    --
    Ian Collins
    Ian Collins, Oct 8, 2010
    #19
  20. Mr. Buffoon

    Ian Collins Guest

    On 10/ 9/10 10:44 AM, FredK wrote:
    > "Keith Thompson"<> wrote:
    >>
    >> In principle, C *could* add a "#pragma pack" or similar feature whose
    >> purpose is to give a hint to the compiler that it should optimize
    >> layouts for space rather than speed of access. That's what Pascal's
    >> "packed record" and Ada's "pragma Pack(Type_Name)" do.
    >>
    >> Such a feature would not be particularly useful for imposing a specified
    >> layout, and on many implementations it would probably be ignored (since
    >> compilers often choose the tightest layout compatible with alignment
    >> requirements anyway). It might make be useful on platforms where
    >> misaligned accesses are merely slower than aligned access.
    >>

    >
    > Actually, it serves several purposes.
    >
    > 1) To be able to define a structure that is already carved in stone, for
    > example a network packet format that was designed for space. Or a legacy
    > structure that is shared with legacy code. Before RISC hardware exposed the
    > inherent problems with poorly aligned data, there were compilers and
    > programmers who didn't pay any attention to alignment and generated
    > unaligned structure layouts.
    >
    > 2) Creating structures to map hardware registers. Usually old hardware,
    > since today hardware registers tend to be at least 32-bit aligned and well
    > aligned. Nonetheless there are many old cards that were a hodge podge. I
    > seldom used this, because there can be other restrictions that make it hard
    > to use.
    >
    > 3) Making sure that the layout of a shared structure is exact - because it
    > will be accessed by things not written in C or compiled by the same C
    > compiler for example. This requires the programmer to take on the
    > responsibility for proper alignment. Of course, in those cases I use a
    > seperate tool that is language independent and can generate the proper
    > definitions for multiple languages.


    I'd add

    4) Testing (embedded) code on a platform with a different native
    alignment (desktop) where the tested code exchanges data with the target
    platform.

    --
    Ian Collins
    Ian Collins, Oct 8, 2010
    #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. Rick

    #pragma once in ISO standard yet?

    Rick, Dec 12, 2007, in forum: C Programming
    Replies:
    33
    Views:
    1,205
    CBFalconer
    Dec 15, 2007
  2. Rick
    Replies:
    4
    Views:
    421
    Pete Becker
    Dec 13, 2007
  3. Lew Pitcher

    Re: standard pragma's?

    Lew Pitcher, Oct 6, 2010, in forum: C Programming
    Replies:
    0
    Views:
    431
    Lew Pitcher
    Oct 6, 2010
  4. Joachim Schmitz

    Re: standard pragma's II

    Joachim Schmitz, Oct 13, 2010, in forum: C Programming
    Replies:
    57
    Views:
    1,313
    Keith Thompson
    Nov 9, 2010
  5. Re: standard pragma's II

    , Oct 21, 2010, in forum: C Programming
    Replies:
    31
    Views:
    858
    William Hughes
    Oct 24, 2010
Loading...

Share This Page