passing a union's field to a function

[Mikhail Teterin]

Hello!

The sample program below is compiled fine by gcc (with -Wall), but rejected
by Sun's SUNWspro compiler (version 6 update 2).

The point of contention is, whether a value for one of the union's types can
be passed to a function directly -- without creating a separate variable of
the union type and assigning the appropriate field of it.

Is gcc being too liberal, or is this behavior simply part of a newer
C-standard, which Sun's old compiler is not supporting? Thanks!

-mi

[Richard Heathfield]

Mikhail Teterin said:

Hello!

The sample program below is compiled fine by gcc (with -Wall), but
rejected by Sun's SUNWspro compiler (version 6 update 2).

What sample program?

The point of contention is, whether a value for one of the union's types
can be passed to a function directly -- without creating a separate
variable of the union type and assigning the appropriate field of it.

The value of the most recently assigned union member object can be passed to
a function directly. There is no need to copy it out.

Is gcc being too liberal, or is this behavior simply part of a newer
C-standard, which Sun's old compiler is not supporting? Thanks!

Who knows? I don't see your code.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Mikhail Teterin]

Richard Heathfield wrote:

What sample program?

Your news-reader must be doing something nasty with attachments.

The program was attached to the original posting. Here it is inline.

-mi

#include <stdio.h>

typedef union {
ššššššššintšššš ši;
ššššššššvoidššš š*p;
ššššššššstruct {
ššššššššššššššš šintššššši;
ššššššššššššššš šintšššššj;
šššššššš}šššššš šs;
} testunion;

static void
testfunc(testun ion u)
{
ššššššššprintf( "i: %d\np: %p\n", u.i, u.p);
}

int
main()
{
šššššššštestfun c((testunion)3) ;
šššššššštestfun c((testunion)NU LL);
ššššššššreturn 0;
}

[Richard Heathfield]

Mikhail Teterin said:

Richard Heathfield wrote:

>What sample program?

Your news-reader must be doing something nasty with attachments.

Attachments don't happen in comp.lang.c - it's a text-only newsgroup.

#include <stdio.h>

typedef union {
int i;
void *p;
struct {
int i;
int j;
} s;
} testunion;

static void
testfunc(testun ion u)
{
printf("i: %d\np: %p\n", u.i, u.p);

Either you put in an int, in which case it's okay to print the int but not
the void *, or you put in a void *, in which case it's okay to print the
void * but not the int.

}

int
main()
{
testfunc((testu nion)3);

That's not a valid conversion.

testfunc((testu nion)NULL);

Neither is that.

return 0;
}

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Mikhail Teterin]

Richard Heathfield wrote:

Attachments don't happen in comp.lang.c - it's a text-only newsgroup.

Mine was a text-only attachement. And I can see it on my news-server...

Mikhail Teterin said:

>testfunc((test union)3);

That's not a valid conversion.

But gcc has no problem with it, and my question was: "why?" Is gcc too lax,
or is it aware of a newer C-standard that neither then Sun's compiler nor
you are aware of?

If a function expects a union, one of whose fields is `int':

typedef union {
int i;
void *p;
struct {
int i;
int j;
} s;
} testunion;

then passing an integer argument (with or without casting) is quite
unambigious -- gcc's treatment seems perfectly reasonable to me...

-mi

[Keith Thompson]

Mikhail Teterin <us****@aldan.a lgebra.comwrite s:

The sample program below is compiled fine by gcc (with -Wall), but rejected
by Sun's SUNWspro compiler (version 6 update 2).

The point of contention is, whether a value for one of the union's types can
be passed to a function directly -- without creating a separate variable of
the union type and assigning the appropriate field of it.

Is gcc being too liberal, or is this behavior simply part of a newer
C-standard, which Sun's old compiler is not supporting? Thanks!

#include <stdio.h>

typedef union {
int i;
void *p;
struct {
int i;
int j;
} s;
} testunion;

static void
testfunc(testun ion u)
{
printf("i: %d\np: %p\n", u.i, u.p);
}

int
main()
{
testfunc((testu nion)3);
testfunc((testu nion)NULL);
return 0;
}

Your program appeared in my newsreader as an attachment. Please don't
post attachments here; just copy your source code into the text of
your article.

You can't cast to a union type in either C90 or C99. gcc apparently
provides this as an extension. This is mentioned in the "C
Extensions" section of the gcc documentation. That documentation will
also tell you about the "-ansi -pedantic" or, if you prefer, "-std=c99
-pedantic" options, which would have warned you about this.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ian Collins]

Mikhail Teterin wrote:

Richard Heathfield wrote:

>>Attachments don't happen in comp.lang.c - it's a text-only newsgroup.

Mine was a text-only attachement. And I can see it on my news-server...

Doesn't matter, text-only newsgroups don't forward attachments.

>

>>Mikhail Teterin said:

>>>testfunc((te stunion)3);

That's not a valid conversion.

But gcc has no problem with it, and my question was: "why?" Is gcc too lax,
or is it aware of a newer C-standard that neither then Sun's compiler nor
you are aware of?

In default mode, gcc will compile just about anything remotely like C.

gcc -Wall -pedantic -ansi /tmp/x.c
/tmp/x.c: In function `main':
/tmp/x.c:21: warning: ISO C forbids casts to union type
/tmp/x.c:22: warning: ISO C forbids casts to union type

Compile with an appropriate warning level, you'll learn more that way.

--
Ian Collins.

[Ian Collins]

Ian Collins wrote:

Mikhail Teterin wrote:

>>Richard Heathfield wrote:

>>>Attachment s don't happen in comp.lang.c - it's a text-only newsgroup.

Mine was a text-only attachement. And I can see it on my news-server...

Doesn't matter, text-only newsgroups don't forward attachments.

Oops, got that one wrong. It did....

--
Ian Collins.

[Keith Thompson]

Mikhail Teterin <us****@aldan.a lgebra.comwrite s:

Richard Heathfield wrote:

>What sample program?

Your news-reader must be doing something nasty with attachments.

The program was attached to the original posting. Here it is inline.

Ugh, that's worse. In my newsreader, it shows up with a bunch of
non-printable '\232' characters.

I don't know how they got there, but try to use only spaces for
indentation. Copy and paste plain text if you can.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mikhail Teterin]

Ian Collins wrote:

In default mode, gcc will compile just about anything remotely like C.

I'm compiled with -Wall, not default, although I don't use -pedantic.

gcc -Wall -pedantic -ansi /tmp/x.c
/tmp/x.c: In function `main':
/tmp/x.c:21: warning: ISO C forbids casts to union type
/tmp/x.c:22: warning: ISO C forbids casts to union type

Compile with an appropriate warning level, you'll learn more that way.

With -Wall, but without -pedantic, the code still compiles cleanly and works
as expected:

% gcc -Wall -o union union.c
% ./union
i: 3
p: 3
i: 0
p: 0

Adding "-pedantic" does, indeed, elicit warnings you quote. So, is there a
way to pass a value to a union-expecting function, without creating a union
and copying the values around, as in:

testunion t;

t.i = i;
testfunc(t);

Why can't I just do:

testfunc(i)

? Is there any kind of ambiguity here?

The reason, I'm so insistant is not only having to copy values around and
create (seemingly) useless local variables. It is also that Purify reports
such passing of unions as a UMR (Uninitialized Memory Read), because other
(longer) fields of the union remain unitilized (such as the s.j field in my
sample union) and putting them onto stack (for a function call)
means "reading" them...

Thanks,

-mi