Syntax for union parameter

Discussion in 'C Programming' started by Rick C. Hodgin, Jan 29, 2014.

  1. Rick C. Hodgin

    Eric Sosman Guest

    (1) "Allowed today" does not imply "allowed tomorrow." In
    particular, you needn't change the compiler even one little bit
    to get into trouble: Just #include a header you didn't use before,
    and all of a sudden the fertilizer hits the fan.

    (2) If your identifiers conflict with those used by the
    implementation, there might be no effect on the executable: If
    the source doesn't compile, there's no executable for it to affect.
    On the other hand, the source might compile anyhow, but produce
    an executable that is defective or behaves in mysterious ways.

    (3) Discussing RDC in a C forum makes as much sense as
    discussing Algol in an Esperanto forum.

    (4) A toolchain that cannot deal properly with the languages
    in use is not a tool, just a chain.
    Eric Sosman, Jan 29, 2014
    1. Advertisements

  2. You might have portability issues then. Certainly older ARM processors
    (you cite ARM as an example) don't like arbitrary alignments. The new
    ones might sill for types, but I don't know. In general, I think it's
    better to write C without such settings, and to check, with an assert
    (static or otherwise), that the structure is the size you expect.

    Also, keep in mind that software often lives longer than hardware. You
    can't be sure what architectures will be important to you during the
    lifetime of a large piece of software.

    Those are "reserved for any use". Using trailing underscore instead is
    always safe (thought you still have be take care with the first part of
    the name).

    Is ARM not one of those bi-endian CPUs that needs support from its
    surrounding chip set to be one or other endian? This is a vague memory
    and I may be wrong, but if not there might be ARM systems that are
    big-endian "in hardware" and can't be switched.
    That can be a right pain. At the very least, I think it's a good idea
    to flag up endian assumptions during writing because finding them all
    later can be tricky.

    Ben Bacarisse, Jan 29, 2014
    1. Advertisements

  3. My purposes in referencing RDC are to explain, when asked, why I personally
    do not use C standards.

    Once, when I was in England, and we left the house at 7am local time (2am
    my time) I drove on the wrong side of the road, but only for a few hundred
    feet because the people who were with me were screaming "WRONG SIDE! WRONG
    SIDE!" The loud unison nature of their chorus (a) woke me up and (b) had
    me laughing so hard immediately thereafter that I almost couldn't drive. :)

    A funny memory.

    Best regards,
    Rick C. Hodgin
    Rick C. Hodgin, Jan 29, 2014
  4. All good points.

    Unfortunately, they fall on deaf ears around here.

    What it boils down to is this: If you want (for some reason, although
    I can't imagine why) to communicate with the thugs of CLC, then you must
    speak their language. If you don't, they will either endlessly nitpick you
    about stupid stuff (see below for a list) or end up branding you a "troll"
    and ignoring you.

    A list of things to avoid in any posted code (or else all you'll get in
    response is stupid nitpicks):

    1) (incorrectly) Prototyping main.
    2) Casting the return value of malloc()
    3) Using leading underscores in your variable names.
    4) etc, etc
    Kenny McCormack, Jan 29, 2014
  5. I understand. The data my compilers generate will be appropriately
    aligned for the target hardware. As of my desire and goals, they will
    be byte packed (though possibly aligned on a boundary for the start).
    I would pursue multiple aligned reads and subsequent bit shifts to
    access cross-boundary packed data before I would enforce an alignment
    in data however.
    I've tried that before. I do not appreciate it.
    Newer ARM chips can work with either endian. I will not be supporting
    older ARM chips. There is a cutoff I have in mind. I don't remember
    what it is, but it's a version from mid-2000s.
    Yes. I think I would look for << or >> operators in my code. Those
    should be the only place where endian issues arise because as the
    compiler author I will always ensure that:

    typedef unsigned char u8
    struct SBGRA { u8 blu, u8 grn; u8 red; u8 alp; }; always loaded the same way regardless of how it's stored in
    memory. When it is loaded, it will be in little endian format.

    Best regards,
    Rick C. Hodgin
    Rick C. Hodgin, Jan 29, 2014
  6. Rick C. Hodgin

    Eric Sosman Guest

    Then you're in the wrong newsgroup.
    Endangering the lives of dozens of perfect strangers is
    a funny notion of "funny."
    Eric Sosman, Jan 29, 2014

  7. Understood. Thank you, Kenny.

    Best regards,
    Rick C. Hodgin
    Rick C. Hodgin, Jan 29, 2014
  8. My responses are when I'm asked why I do this or that.
    I see your point. It was funny though. It was the loud unison nature
    of their shouting. It was almost like a rehearsed chant it was so
    perfectly timed. Still makes me laugh thinking about it. :)

    Best regards,
    Rick C. Hodgin
    Rick C. Hodgin, Jan 29, 2014
  9. [...]


    typedef unsigned char byte;

    would be better. (Or you could just use unsigned char directly.)
    Keith Thompson, Jan 29, 2014
  10. "int main(void)" is even shorter, and has the considerable virtue of
    being correct. (One could quibble that "void main(void)" isn't exactly
    *incorrect*, but it's close enough.)
    Keith Thompson, Jan 29, 2014
  11. I wasn't aware you could surround function definitions in quotes. Awesome!
    "...isn't exactly incorrect, but it's close enough" can be taken two ways.

    Best regards,
    Rick C. Hodgin
    Rick C. Hodgin, Jan 29, 2014
  12. `int main(void)` is better (and is still shorter than `void
    main(void)`). `int main()` is an old-style definition, which is
    an obsolescent feature. (A very strict reading of the standard
    implies that `int main()` has undefined behavior, but I don't
    believe any C compiler would reject it or handle it in other
    than the expected manner. The ANSI C committee surely *intended*
    `int main()` to continue to be valid; they just didn't quite say so.)

    Using prototypes for all function declarations and definitions,
    including the definition of main, is IMHO a good habit.

    Probably because he continues to get attention here.
    Keith Thompson, Jan 29, 2014
  13. To quote Dr. Pulaski, chief medical officer on board the U.S.S. Enterprise
    (in the episode entitled "The Measure of a Man," in response to a gift given
    to Lt. Commander Data as part of his presumed going away party, by Worf,
    who stated that the novel "The Dream of the Fire," by K'Rata, attained its
    full stature in the hands of the Klingons), "I couldn't disagree more. But, I'll save that argument for another day."
    Truthfully, it's been kind of exciting and invigorating. It's like I
    stand at the circle, the host quizzing me just before stating, "You are
    the weakest link. Good bye," to which I am forced to leave because we
    are standing upon the sands of the C shore. :) Still, I've had all of
    these ideas twoddling around in my head for a long time and now. It's
    good to get some feedback.

    I also enjoy the witty repartee ... though not as much as I might otherwise
    were it more prevalent from all parties concerned.

    Best regards,
    Rick C. Hodgin
    Rick C. Hodgin, Jan 29, 2014
  14. Ah, that's philosophy. What syntax a compiler knows I leave to you.
    What syntax it accepts is more matter of fact, and it appears that this
    old compiler accepts this new C11 syntax. A common enough occurrence --
    many features got into C after being implemented as extensions.
    Ben Bacarisse, Jan 29, 2014
  15. Rick C. Hodgin

    David Brown Guest

    Anonymous structs or unions within other structs and unions has been
    accepted as a gcc extension for ages, and I've seen it on other
    compilers too. So this does appear to be a commonly implemented
    extension that made it into the standards eventually.
    David Brown, Jan 29, 2014
  16. Keith, I've been thinking about this ... how do you conclude that using
    prototype definitions is, in all cases, a good idea?

    I would argue they have their place, but only their place. In a
    modern IDE, and under the N-pass nature of modern compiler theory,
    there is no need for any prototyping whatsoever.

    Best regards,
    Rick C. Hodgin
    Rick C. Hodgin, Jan 29, 2014
  17. As I'm sure you're aware, I just used the quotation marks to distinguish
    the C code from the surrounding text. I more often use markdown syntax,
    surrounding code snippets with backticks.
    Yes, I was unclear. Saying it's incorrect is close enough. The full
    truth is that it has undefined behavior for implementations that do
    not explicitly document that they support it, implementation-defined
    behavior for implementations that do document it. A conforming
    compiler is free to reject `void main(void)` -- and I frankly wish
    that more compilers did so, since it would help weed out code that
    uses it. See in the C standard.
    Keith Thompson, Jan 29, 2014
  18. That's a very long-winded way of saying practically nothing. If you
    have an actual counterargument to my recommendation to use prototypes,
    I'd be interested in seeing it; one of us might learn something.
    (And it's actually about C.)
    Keith Thompson, Jan 29, 2014
  19. Ah, another C terminology problem. A function definition may or may not
    provide a prototype. If you image a C-like language where forward
    declaration is not needed, you are still using prototypes if the
    function definitions include the parameter types.

    Not using prototypes looks like this:

    void f(a)
    int a;
    extern int printf();
    printf("%d\n", a);

    int main() { f(4.2); }

    and is universally not missed.
    Ben Bacarisse, Jan 29, 2014
  20. Non-prototype function declarations and definitions are an
    obsolescent feature that could be removed in a future edition of
    the C standard.

    Using non-prototype declarations runs a considerable risk of writing
    a function call with the wrong number or type(s) of arguments,
    and not having the compiler catch it. Sure, a sufficiently clever
    compiler could warn you about it, but it would be foolish to count
    on that.

    I first learned C before prototypes were added to the language.
    When I accidentally wrote a call that passed the wrong number of
    arguments to a function, I was horrified that the compiler didn't
    diagnose it.

    Let's be sure that you know what the word means. A prototype is
    a function declaration that specifies the type(s) of the parameters.

    I can think of no good reason to use non-prototype declarations
    or definitions. (Saving a few characters is not IMHO a good reason.)

    Why would you ever want to use a non-prototype function declaration
    or definition?
    Keith Thompson, Jan 29, 2014
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.