Syntax for union parameter

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

  1. Ah, I see. Your "must be uncommented" confused me. There is no need to
    un-comment that line to define _TEST_ME.

    Sure. I thought you'd want to call it C since you've been talking about
    C all this time. Anyway, just replace C with C++:

    Does that make it not C++ anymore? I.e. is there some stuff related to
    VS that makes it compile there when it won't just by giving the file to
    a compiler?

    You've answered this elsewhere. For some odd reason, this code in not
    intended to be compiler like any other translation unit, but it is to be
    #included. Obviously that can provide the code with almost any possible
    environment, so the fact that is does not compile directly is
    irrelevant. I won't comment on the merits of this, I'm sure it's right
    for you.

    <snip>
     
    Ben Bacarisse, Feb 11, 2014
    1. Advertisements

  2. (snip, someone wrote)
    Even without it, programs have to be careful with that value.
    Among others, -x or abs(x) gives a negative result.
    The possibility of trap representations and negative zero are
    good reasons to avoid signed types for bit manipulation.

    Maybe someone should start building more such machines to
    force C programmers to shape up and code right.

    -- glen
     
    glen herrmannsfeldt, Feb 11, 2014
    1. Advertisements

  3. Rick C. Hodgin

    James Kuyper Guest

    No, you get 3, 2, or 1 depending upon whether intmax_t is 2's
    complement, 1's complement, or sign-magnitude. In principle, 'int' can
    be different. The only types who's properties can be tested directly in
    the preprocessor are intmax_t and uintmax_t.

    It's not a big issue in real life, of course. Anything other than 2's
    complement is very rare these days, and systems where two signed types
    are supported that handle negative values differently are even rarer.
     
    James Kuyper, Feb 11, 2014
  4. Ah yes, of course. Curiously I checked that with the other posted
    solutions and the forgot for my own suggestion!
    Non 2's complement implementations are peculiar enough and rare enough
    that that I think one should be prepared for the worst. For example, a
    32 bit 1's complement machine has not 64 bit ints and to satisfy C99 the
    implementation just uses a simple software implementation using 32 bit
    unsigned ints. If it were mine to write, I'd implement 2's complement
    arithmetic.
     
    Ben Bacarisse, Feb 11, 2014
  5. Rick C. Hodgin

    Ike Naar Guest

    The behaviour of abs(x) is undefined for that value:

    7.22.6.1 The abs, labs and llabs functions
    [...]
    Description
    2 The abs, labs, and llabs functions compute the absolute value of an
    integer j. If the result cannot be represented, the behavior is
    undefined. 304)
    [...]
    304) The absolute value of the most negative number cannot be
    represented in two's complement.
     
    Ike Naar, Feb 11, 2014
  6. (snip, I wrote)
    OK, but yes, the most natural value (complement all bits and add
    one) you get the original value back, and you also get overflow.

    As well as I remember, the effects of overflow are always
    undefined.

    In any case, and especially in the case of UB, you might
    get a negative value from abs(x).

    -- glen

    -- glen
     
    glen herrmannsfeldt, Feb 11, 2014
  7. Rick C. Hodgin

    David Brown Guest

    It might be a waste of time for /your/ sort of programming, but it is
    not a waste of time in embedded systems. I don't often need to convert
    endianness, but it certainly happens on occasion - and compilers that
    have extensions allowing data to be declared in a particular format make
    it easier to write clearer code in such cases. It means the format
    choice is made at the declaration of the data (or data types), avoiding
    extra function call syntax when the data is used, and avoiding the
    possibility that the function call syntax is forgotten. It also means
    that you write more portable code, because it is easy and cheap to
    declare the endianness of transferred data even if you know it is the
    same as your current target.

    Posix functions don't help here - we are a /long/ way from posix on such
    systems. And the necessity of specifying the sizes in the posix
    functions is an extra layer of complication on embedded systems, where
    such transferred data often has varying data sizes. And of course,
    there are plenty of times when you might want to access little-endian on
    big-endian architectures, for which Posix does not help.

    Different types of programming needs (or wants) different features - a
    standards defined way of declaring the endianness of data and types
    would be a useful feature for many people, and save a lot of
    roll-your-own solutions.
     
    David Brown, Feb 11, 2014
  8. Rick C. Hodgin

    Jorgen Grahn Guest

    But I'm thinking to myself: "well, maybe he was damaged by the
    'undefined' scare people without actually being one of them ..."

    I don't know ... I think worrying about it (especially when security
    is involved) is a honorable thing to do. And painful.

    I don't worry too much, but I don't know if it's because I've amassed
    20 years of experience so I'm now a C demi-god, or if I'm simply a bit
    more sloppy than you.

    If
    - my code compiles without warnings with 'gcc -W -Wall -pedantic
    -std=c99'
    - I've reviewed all casts and uses of void*
    - I'm happy with it in general
    - it runs well in practice and produces no Valgrind warnings

    then I'm happy with it. As an extra bonus I can run it on both
    AMD64 and PowerPC.

    And in the end, code doesn't usually have to be free from bugs.
    You can almost always apologize, and fix them.
    *shrug* That's their problem -- and unrelated to what we're discussing
    here, I think. I was merely trying to explain what kind of
    environment C grew up in.
    Replacement is the best solution, I think. But it will not happen
    anytime soon.

    /Jorgen
     
    Jorgen Grahn, Feb 12, 2014
  9. Rick C. Hodgin

    James Kuyper Guest

    On 02/09/2014 11:51 AM, Robbie Brown wrote:
    ....
    I don't think so - I doubt that it's supported now. :) You might be
    thinking of his Analytical Engine? It's Turing complete, so it might be
    possible, but there's probably some requirement of the C standard it
    would have difficulty meeting.
     
    James Kuyper, Feb 12, 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.