union field access and compatible types

Discussion in 'C Programming' started by nicolas.sitbon, Jan 8, 2010.

  1. Hi all,
    My question is simple but I can't find the answer in the standard (C99
    TC3).
    is this permitted?

    union
    {
    const void * ro;
    void * rw;
    }
    variant;

    void * buf = strdup("bla");
    /* check allocation success */
    variant.rw = buf.
    puts(variant.ro);

    Thanks by advance.
     
    nicolas.sitbon, Jan 8, 2010
    #1
    1. Advertising

  2. "nicolas.sitbon" <> writes:

    > My question is simple but I can't find the answer in the standard (C99
    > TC3).
    > is this permitted?
    >
    > union
    > {
    > const void * ro;
    > void * rw;
    > }
    > variant;
    >
    > void * buf = strdup("bla");
    > /* check allocation success */
    > variant.rw = buf.
    > puts(variant.ro);


    Yes. Pointers to const and non-const versions of the same type have
    the same alignment and representation (6.2.5 p27). I don't see any
    other pitfalls but maybe you were worrying about some other aspect of
    the code.

    How did this come up? I'd prefer to use a cast if I needed to change
    the qualifiers on the target of a pointer. It makes this significant
    change so much more apparent in the code so I imagine that this effect
    is not the main purpose of this code fragment.

    --
    Ben.
     
    Ben Bacarisse, Jan 8, 2010
    #2
    1. Advertising

  3. On Jan 8, 12:13 pm, Ben Bacarisse <> wrote:
    > "nicolas.sitbon" <> writes:
    > > My question is simple but I can't find the answer in the standard (C99
    > > TC3).
    > > is this permitted?

    >
    > > union
    > > {
    > >    const void * ro;
    > >    void * rw;
    > > }
    > > variant;

    >
    > > void * buf = strdup("bla");
    > > /* check  allocation success */
    > > variant.rw = buf.
    > > puts(variant.ro);

    >
    > Yes.  Pointers to const and non-const versions of the same type have
    > the same alignment and representation (6.2.5 p27).  I don't see any
    > other pitfalls but maybe you were worrying about some other aspect of
    > the code.
    >
    > How did this come up?  I'd prefer to use a cast if I needed to change
    > the qualifiers on the target of a pointer.  It makes this significant
    > change so much more apparent in the code so I imagine that this effect
    > is not the main purpose of this code fragment.
    >
    > --
    > Ben.


    thanks for your answer, in fact, I don't need to change the
    qualifiers, rather I'm looking for a way to create a generic data
    structure that can can be used with const generic pointer or non const
    generic pointer, preventing the user from casting if I would hard code
    the qualifier. Think of a generic linked list where you can put const
    data or variable data without casting because I would code void * data
    and the user want to put a const char *. I hope it is clear, english
    is not my mother tongue.
     
    nicolas.sitbon, Jan 8, 2010
    #3
  4. "nicolas.sitbon" <> writes:

    > On Jan 8, 12:13 pm, Ben Bacarisse <> wrote:
    >> "nicolas.sitbon" <> writes:

    <snip>
    >> > union
    >> > {
    >> >    const void * ro;
    >> >    void * rw;
    >> > }
    >> > variant;

    <snip>
    >> How did this come up?

    <snip>
    >> --
    >> Ben.


    It is best to snip sigs unless you are commenting on them.

    > thanks for your answer, in fact, I don't need to change the
    > qualifiers, rather I'm looking for a way to create a generic data
    > structure that can can be used with const generic pointer or non const
    > generic pointer, preventing the user from casting if I would hard code
    > the qualifier.


    If you hard-code the const, why does the user have to cast?

    > Think of a generic linked list where you can put const
    > data or variable data without casting because I would code void * data
    > and the user want to put a const char *.


    As a rule, generic container structures don't know enough about the
    data to do anything much with it (they may pass it to a function but
    that is about it). That makes me wonder why you need the non-const
    data variant.

    > I hope it is clear, english is not my mother tongue.


    Yes, perfectly clear. Your English is excellent. While on the
    subject of language, pointers are problematic. You talk about a
    "const generic pointer or non const generic pointer" but in fact the
    pointer is not const qualified in either case, it is the data pointed
    *to* that is marked const. This is not a complaint -- everyone drops
    into shorthands like this all the time -- but sometimes it matters and
    it pays to be vigilant for those cases where they might be a
    misunderstanding.

    --
    Ben.
     
    Ben Bacarisse, Jan 8, 2010
    #4
  5. On Jan 8, 1:45 pm, Ben Bacarisse <> wrote:
    > > thanks for your answer, in fact, I don't need to change the
    > > qualifiers, rather I'm looking for a way to create a generic data
    > > structure that can can be used with const generic pointer or non const
    > > generic pointer, preventing the user from casting if I would hard code
    > > the qualifier.

    >
    > If you hard-code the const, why does the user have to cast?


    If I hard-code the const and the user put a non const data, it makes
    no problem, but if he wants to get back his data that is now stored in
    a pointer to const, he is forced to cast.

    > > Think of a generic linked list where you can put const
    > > data or variable data without casting because I would code void * data
    > > and the user want to put a const char *.

    >
    > As a rule, generic container structures don't know enough about the
    > data to do anything much with it (they may pass it to a function but
    > that is about it).  That makes me wonder why you need the non-const
    > data variant.


    see above, when you want to get back your data in a pointer to non
    const data, you are forced to cast.

    > > I hope it is clear, english is not my mother tongue.

    >
    > Yes, perfectly clear.  Your English is excellent.  While on the
    > subject of language, pointers are problematic.  You talk about a
    > "const generic pointer or non const generic pointer" but in fact the
    > pointer is not const qualified in either case, it is the data pointed
    > *to* that is marked const.  This is not a complaint -- everyone drops
    > into shorthands like this all the time -- but sometimes it matters and
    > it pays to be vigilant for those cases where they might be a
    > misunderstanding.

    You're right, it's a bad shorthand.
     
    nicolas.sitbon, Jan 8, 2010
    #5
  6. "nicolas.sitbon" <> writes:

    > On Jan 8, 1:45 pm, Ben Bacarisse <> wrote:
    >> > thanks for your answer, in fact, I don't need to change the
    >> > qualifiers, rather I'm looking for a way to create a generic data
    >> > structure that can can be used with const generic pointer or non const
    >> > generic pointer, preventing the user from casting if I would hard code
    >> > the qualifier.

    >>
    >> If you hard-code the const, why does the user have to cast?

    >
    > If I hard-code the const and the user put a non const data, it makes
    > no problem, but if he wants to get back his data that is now stored in
    > a pointer to const, he is forced to cast.


    True, but I see that as an advantage. I'd like to see the end result
    using your idea before deciding, but I /think/ it will obfuscate when
    the data is and is not const. Do you have any working code yet?

    <snip>
    --
    Ben.
     
    Ben Bacarisse, Jan 8, 2010
    #6
  7. nicolas.sitbon

    Tim Rentsch Guest

    "nicolas.sitbon" <> writes:

    > Hi all,
    > My question is simple but I can't find the answer in the standard (C99
    > TC3).
    > is this permitted?
    >
    > union
    > {
    > const void * ro;
    > void * rw;
    > }
    > variant;
    >
    > void * buf = strdup("bla");
    > /* check allocation success */
    > variant.rw = buf.
    > puts(variant.ro);


    The short answer is yes. The two members involved have types
    that are guaranteed to have the same representation and alignment
    requirements. This is covered in section 6.2.5 paragraph 27.
     
    Tim Rentsch, Jan 13, 2010
    #7
    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. Matt Garman
    Replies:
    1
    Views:
    691
    Matt Garman
    Apr 25, 2004
  2. Peter Dunker

    union in struct without union name

    Peter Dunker, Apr 26, 2004, in forum: C Programming
    Replies:
    2
    Views:
    928
    Chris Torek
    Apr 26, 2004
  3. Edward Rutherford

    union field access

    Edward Rutherford, May 27, 2011, in forum: C Programming
    Replies:
    13
    Views:
    572
    Tim Rentsch
    Jun 1, 2011
  4. pantagruel
    Replies:
    0
    Views:
    271
    pantagruel
    Feb 17, 2006
  5. Sound
    Replies:
    2
    Views:
    500
    Randy Webb
    Sep 28, 2006
Loading...

Share This Page