By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,949 Members | 1,086 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,949 IT Pros & Developers. It's quick & easy.

Is this legal ?

P: n/a
Hi all,

I wanted to have a union which has two structures in it.
So i did this,

union {
struct{
int a;
int b;
};
struct{
float c;
};
}un;

I did not want to name the two inner structures, because i wanted to
access the members like this,
<union name>.<member name>
instead of
<union name>.<structure name>.<member name>

My question is, Is this valid C?

I also observed that if i have a union like this ,

union {
struct{
int a;
int b;
};
struct{
float a;
float b;
};
}un;

Compiler doesn't give me any error.
If i say, 'un.a' how will it know whether i'm using float a or int
a ?
Thanks for your time,
Yugi.

Sep 15 '06 #1
Share this Question
Share on Google+
47 Replies


P: n/a
main() wrote:
Hi all,

I wanted to have a union which has two structures in it.
So i did this,

union {
struct{
int a;
int b;
};
struct{
float c;
};
}un;

I did not want to name the two inner structures, because i wanted to
access the members like this,
<union name>.<member name>
instead of
<union name>.<structure name>.<member name>

My question is, Is this valid C?
No. The compiler cannot read your mind and realize
that when you write <union name>.<member name>
you really mean <union name>.<some structure>.<member name>
>
I also observed that if i have a union like this ,

union {
struct{
int a;
int b;
};
struct{
float a;
float b;
};
}un;

Compiler doesn't give me any error.
If i say, 'un.a' how will it know whether i'm using float a or int
a ?
It won't. Hence your definition is useless even if it
doesn't cause your compiler to complain. For the
programme

int main(void) {
union {
struct{
int a;
int b;
};
struct{
float a;
float b;
};
}un;
}

Sun compiler gives
"b.c", line 6: warning: unnamed union member
"b.c", line 10: warning: unnamed union member
"b.c", line 11: zero-sized struct/union
cc: acomp failed for b.c

gcc -Wall -ansi -pedantic b.c gives
b.c: In function `main':
b.c:6: warning: ANSI C forbids member declarations with no members
b.c:6: warning: unnamed struct/union that defines no instances
b.c:10: warning: ANSI C forbids member declarations with no members
b.c:10: warning: unnamed struct/union that defines no instances
b.c:11: warning: union has no members
b.c:11: warning: unused variable `un'
b.c:12: warning: control reaches end of non-void function

I would suggest that you turn your compiler's warning
levels up. If you still don't get a warning then it's time
to switch to a new compiler.
>

Thanks for your time,
Yugi.
Sep 15 '06 #2

P: n/a

Spiros Bousbouras wrote:
main() wrote:
Hi all,

I wanted to have a union which has two structures in it.
So i did this,

union {
struct{
int a;
int b;
};
struct{
float c;
};
}un;

I did not want to name the two inner structures, because i wanted to
access the members like this,
<union name>.<member name>
instead of
<union name>.<structure name>.<member name>

My question is, Is this valid C?

No. The compiler cannot read your mind and realize
that when you write <union name>.<member name>
you really mean <union name>.<some structure>.<member name>

I also observed that if i have a union like this ,

union {
struct{
int a;
int b;
};
struct{
float a;
float b;
};
}un;

Compiler doesn't give me any error.
If i say, 'un.a' how will it know whether i'm using float a or int
a ?

It won't. Hence your definition is useless even if it
doesn't cause your compiler to complain. For the
programme

int main(void) {
union {
struct{
int a;
int b;
};
struct{
float a;
float b;
};
}un;
}

Sun compiler gives
"b.c", line 6: warning: unnamed union member
"b.c", line 10: warning: unnamed union member
"b.c", line 11: zero-sized struct/union
cc: acomp failed for b.c

gcc -Wall -ansi -pedantic b.c gives
b.c: In function `main':
b.c:6: warning: ANSI C forbids member declarations with no members
b.c:6: warning: unnamed struct/union that defines no instances
b.c:10: warning: ANSI C forbids member declarations with no members
b.c:10: warning: unnamed struct/union that defines no instances
b.c:11: warning: union has no members
b.c:11: warning: unused variable `un'
b.c:12: warning: control reaches end of non-void function

I would suggest that you turn your compiler's warning
levels up. If you still don't get a warning then it's time
to switch to a new compiler.


Thanks for your time,
Yugi.

The main usage of Annonymous Union is to limit scope of some name
space. If you are defining Anno. union, you have to take care scope of
variable yourself.

Sep 15 '06 #3

P: n/a
This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code, and it is practical since
it allows you to avoid specifying the whole "path" to
the member and giving you more flexibility in the
layout of the structire without changing the code.

jacob
Sep 15 '06 #4

P: n/a
jacob navia wrote:
This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code, and it is practical since
it allows you to avoid specifying the whole "path" to
the member and giving you more flexibility in the
layout of the structire without changing the code.
lcc will accept which code ? How are you going to
refer to members ? Examples please.

Sep 15 '06 #5

P: n/a
Spiros Bousbouras wrote:
jacob navia wrote:

>>This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code, and it is practical since
it allows you to avoid specifying the whole "path" to
the member and giving you more flexibility in the
layout of the structire without changing the code.


lcc will accept which code ? How are you going to
refer to members ? Examples please.
union {
struct{
int a;
int b;
};
struct{
float c;
};
}un;

int main(void)
{

un.a = 1;
return 0;
}
Sep 15 '06 #6

P: n/a
jacob navia said:
This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code,
How can that possibly be relevant to the OP? Please keep your spam to
yourself.

--
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)
Sep 15 '06 #7

P: n/a
Richard Heathfield wrote:
jacob navia said:

>>This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code,


How can that possibly be relevant to the OP? Please keep your spam to
yourself.
It is a COMMON extension heathfield
Sep 15 '06 #8

P: n/a
Richard Heathfield wrote:
jacob navia said:

>>This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code,

MSVC will accept this code too.

gcc (in its normal, non pedantic configuration) will accept
this code too.

This means in almost ANY workstation today (windows, microsoft, or Mac)
this code is portable and will be accepted.

Only people that insist in restricting themselves to ISO C will
(after some effort) be unable to compile that code.

Sep 15 '06 #9

P: n/a
jacob navia wrote:
Spiros Bousbouras wrote:
jacob navia wrote:

>This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code, and it is practical since
it allows you to avoid specifying the whole "path" to
the member and giving you more flexibility in the
layout of the structire without changing the code.

lcc will accept which code ? How are you going to
refer to members ? Examples please.

union {
struct{
int a;
int b;
};
struct{
float c;
};
}un;

int main(void)
{

un.a = 1;
return 0;
}
Interesting. Can you say a bit about what
algorithm you use ? I mean does the compiler
search in arbitrary depth in structures/unions
which contain structures/unions as fields which
contain structures/unions as fields and so on, to
see if a field is uniquely named and if it is then it
will assume that this is the field which is being referred ?

How will the compiler react to the following ?

union {
struct{
int a;
int b;
};
struct{
float a;
float b;
};
}un;

Sep 15 '06 #10

P: n/a
jacob navia <ja***@jacob.remcomp.frwrote:
This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code,
Yeah, but then, if you spit on a floppy disk your toy will probably
accept the result as perfectly good C with a boatload of happy happy
extensions, so that means nothing.

What the OP posted, and what you conveniently but luserishly snipped
completely, is not just "not strictly valid C"; it's strictly not valid
C. That's all he asked for. Advertisements were not requested.

Richard
Sep 15 '06 #11

P: n/a
Spiros Bousbouras wrote:
jacob navia wrote:

>>Spiros Bousbouras wrote:
>>>jacob navia wrote:

This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code, and it is practical since
it allows you to avoid specifying the whole "path" to
the member and giving you more flexibility in the
layout of the structire without changing the code.
lcc will accept which code ? How are you going to
refer to members ? Examples please.

union {
struct{
int a;
int b;
};
struct{
float c;
};
}un;

int main(void)
{

un.a = 1;
return 0;
}


Interesting. Can you say a bit about what
algorithm you use ? I mean does the compiler
search in arbitrary depth in structures/unions
which contain structures/unions as fields which
contain structures/unions as fields and so on, to
see if a field is uniquely named and if it is then it
will assume that this is the field which is being referred ?

How will the compiler react to the following ?

union {
struct{
int a;
int b;
};
struct{
float a;
float b;
};
}un;
The algorithm is simple:

It requires that all field names (at any depths) are UNIQUE,
so your example will NOT work. The compiler will start a depth first
search in the whole nested structures with a field for that
name, and if it finds it it will automatically generate the
path to it.

I have the idea of this extensions from the Plan9 compiler
by Dennis Ritchie.

jacob
Sep 15 '06 #12

P: n/a
Richard Bos wrote:
jacob navia <ja***@jacob.remcomp.frwrote:

>>This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code,


Yeah, but then, if you spit on a floppy disk your toy will probably
accept the result as perfectly good C with a boatload of happy happy
extensions, so that means nothing.

What the OP posted, and what you conveniently but luserishly snipped
completely, is not just "not strictly valid C"; it's strictly not valid
C. That's all he asked for. Advertisements were not requested.

Richard
Mr traffic cop:

The subject of the quetion was answered with my FIRST sentence:

"This is not strictly valid C".

Since most compilers in the workstation level (windows, unix, mac)
accept this code. MSVC AND GCC will accept it, maybe not in the
same level as lcc-win32 but this code below will be accepted by
all:
union {
struct{
int a;
int b;
};
struct{
float c;
};
}un;

int main(void)
{
un.a = 1;
return 0;
}

So, it is my right to express my opinion that this is a VERY common
extension.
Sep 15 '06 #13

P: n/a
jacob navia wrote:
Spiros Bousbouras wrote:
jacob navia wrote:

>Spiros Bousbouras wrote:

jacob navia wrote:

This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code, and it is practical since
it allows you to avoid specifying the whole "path" to
the member and giving you more flexibility in the
layout of the structire without changing the code.
lcc will accept which code ? How are you going to
refer to members ? Examples please.
union {
struct{
int a;
int b;
};
struct{
float c;
};
}un;

int main(void)
{

un.a = 1;
return 0;
}

Interesting. Can you say a bit about what
algorithm you use ? I mean does the compiler
search in arbitrary depth in structures/unions
which contain structures/unions as fields which
contain structures/unions as fields and so on, to
see if a field is uniquely named and if it is then it
will assume that this is the field which is being referred ?

How will the compiler react to the following ?

union {
struct{
int a;
int b;
};
struct{
float a;
float b;
};
}un;

The algorithm is simple:

It requires that all field names (at any depths) are UNIQUE,
so your example will NOT work.
I meant will the compiler complain where the structure is declared
or will it complain at the point where the code tries to access some
member that the member name is not unique ?

Sep 15 '06 #14

P: n/a
Spiros Bousbouras wrote:
jacob navia wrote:

>>Spiros Bousbouras wrote:
>>>jacob navia wrote:

Spiros Bousbouras wrote:
>jacob navia wrote:
>
>
>
>
>>This is not strictly valid C but it is a common extension.
>>lcc-win32 will accept this code, and it is practical since
>>it allows you to avoid specifying the whole "path" to
>>the member and giving you more flexibility in the
>>layout of the structire without changing the code.
>
>
>lcc will accept which code ? How are you going to
>refer to members ? Examples please.
>

union {
struct{
int a;
int b;
};
struct{
float c;
};
}un;

int main(void)
{

un.a = 1;
return 0;
}
Interesting. Can you say a bit about what
algorithm you use ? I mean does the compiler
search in arbitrary depth in structures/unions
which contain structures/unions as fields which
contain structures/unions as fields and so on, to
see if a field is uniquely named and if it is then it
will assume that this is the field which is being referred ?

How will the compiler react to the following ?

union {
struct{
int a;
int b;
};
struct{
float a;
float b;
};
}un;

The algorithm is simple:

It requires that all field names (at any depths) are UNIQUE,
so your example will NOT work.


I meant will the compiler complain where the structure is declared
or will it complain at the point where the code tries to access some
member that the member name is not unique ?
It will complain at the point of the declaration.
Your example will produce with lcc-win32:
Error tanonymous.c: 10 ambiguous field 'a' of 'union defined at
d:\lcc\mc66\test\tanonymous.c 1' from 'struct defined at
d:\lcc\mc66\test\tanonymous.c 6'
Error tanonymous.c: 10 ambiguous field 'b' of 'union defined at
d:\lcc\mc66\test\tanonymous.c 1' from 'struct defined at
d:\lcc\mc66\test\tanonymous.c 6'
Sep 15 '06 #15

P: n/a
jacob navia said:
Richard Bos wrote:
>jacob navia <ja***@jacob.remcomp.frwrote:

>>>This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code,


Yeah, but then, if you spit on a floppy disk your toy will probably
accept the result as perfectly good C with a boatload of happy happy
extensions, so that means nothing.

What the OP posted, and what you conveniently but luserishly snipped
completely, is not just "not strictly valid C"; it's strictly not valid
C. That's all he asked for. Advertisements were not requested.

Richard

Mr traffic cop:

The subject of the quetion was answered with my FIRST sentence:

"This is not strictly valid C".
And that should have been your *only* sentence. Everything after it was
utterly irrelevant to the OP's question.
So, it is my right to express my opinion that this is a VERY common
extension.
And it's my right to express my opinion that you seem to be desperate for
any chance to promote your squalid little implementation, because if you
don't, people might forget it's there.

So let's keep our opinions to ourselves and just talk about C, shall we?

And for the record, lcc-win32 is *not* C, and C is *not* lcc-win32. C, the
subject of this newsgroup, is a *language*, not an implementation.

--
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)
Sep 15 '06 #16

P: n/a
jacob navia <ja***@jacob.remcomp.frwrites:
Spiros Bousbouras wrote:
>jacob navia wrote:
>>>This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code, and it is practical since
it allows you to avoid specifying the whole "path" to
the member and giving you more flexibility in the
layout of the structire without changing the code.
lcc will accept which code ? How are you going to
refer to members ? Examples please.

union {
struct{
int a;
int b;
};
struct{
float c;
};
}un;

int main(void)
{

un.a = 1;
return 0;
}
lcc-win32 doesn't accept this code in conforming mode, does it?

--
Keith Thompson (The_Other_Keith) 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.
Sep 15 '06 #17

P: n/a
Richard Heathfield wrote:
>
And it's my right to express my opinion that you seem to be desperate for
any chance to promote your squalid little implementation, because if you
don't, people might forget it's there.

We hit for the first time a download rate of
more than 1 000 downloads per day yesterday.

This rate was measured in one of our download sites
(www-q-software-solutions.de) without adding the
downloads from
http://www.cs.virginia.edu/~lcc-win32.

Thanks to all for this support.

:-)
jacob
Sep 15 '06 #18

P: n/a
Keith Thompson wrote:
jacob navia <ja***@jacob.remcomp.frwrites:
>>Spiros Bousbouras wrote:
>>>jacob navia wrote:
This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code, and it is practical since
it allows you to avoid specifying the whole "path" to
the member and giving you more flexibility in the
layout of the structire without changing the code.

lcc will accept which code ? How are you going to
refer to members ? Examples please.

union {
struct{
int a;
int b;
};
struct{
float c;
};
}un;

int main(void)
{

un.a = 1;
return 0;
}


lcc-win32 doesn't accept this code in conforming mode, does it?
The problem is that all windows header files use this. I DID emit an
error for this, but people complained that then you could NOT
compile a windows program in conforming mode, what made the
conforming mode useless for all practical purposes.

Then, I took out the error and made this exception. I do not
see any way out of this dilemma.

jacob
Sep 15 '06 #19

P: n/a
jacob navia said:
Richard Heathfield wrote:
>>
And it's my right to express my opinion that you seem to be desperate for
any chance to promote your squalid little implementation, because if you
don't, people might forget it's there.

We hit for the first time a download rate of
more than 1 000 downloads per day yesterday.
Gosh. Your mouse-finger must be all worn out.

--
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)
Sep 15 '06 #20

P: n/a
jacob navia said:
Keith Thompson wrote:
<snip>
>lcc-win32 doesn't accept this code in conforming mode, does it?

The problem is that all windows header files use this. I DID emit an
error for this, but people complained that then you could NOT
compile a windows program in conforming mode, what made the
conforming mode useless for all practical purposes.

Then, I took out the error and made this exception. I do not
see any way out of this dilemma.
So lcc-win32 has no conforming mode? Interesting. So it's not a C compiler
after all.

--
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)
Sep 15 '06 #21

P: n/a
Richard Heathfield wrote:
jacob navia said:

>>Keith Thompson wrote:


<snip>
>>>lcc-win32 doesn't accept this code in conforming mode, does it?

The problem is that all windows header files use this. I DID emit an
error for this, but people complained that then you could NOT
compile a windows program in conforming mode, what made the
conforming mode useless for all practical purposes.

Then, I took out the error and made this exception. I do not
see any way out of this dilemma.


So lcc-win32 has no conforming mode? Interesting. So it's not a C compiler
after all.
I prefer keeping the conforming mode for windows programs
than making a 100% conforming mode that can't be used in
practice and is only useful to satisfy the
requirements of the few "regulars" in comp.lang.c.

Sep 15 '06 #22

P: n/a
jacob navia wrote:
Richard Heathfield wrote:
>jacob navia said:

>>Keith Thompson wrote:

<snip>
>>>lcc-win32 doesn't accept this code in conforming mode, does it?
The problem is that all windows header files use this. I DID emit an
error for this, but people complained that then you could NOT
compile a windows program in conforming mode, what made the
conforming mode useless for all practical purposes.

Then, I took out the error and made this exception. I do not
see any way out of this dilemma.

So lcc-win32 has no conforming mode? Interesting. So it's not a C
compiler after all.

I prefer keeping the conforming mode for windows programs
than making a 100% conforming mode that can't be used in
practice and is only useful to satisfy the
requirements of the few "regulars" in comp.lang.c.
P.S. The same problem appears with the _stdcall extension
and the windows headers. _stdcall WILL be accepted in
conforming mode.
Sep 15 '06 #23

P: n/a
jacob navia wrote:
Keith Thompson wrote:
>jacob navia <ja***@jacob.remcomp.frwrites:
>>Spiros Bousbouras wrote:

jacob navia wrote:
This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code, and it is practical since
it allows you to avoid specifying the whole "path" to
the member and giving you more flexibility in the
layout of the structire without changing the code.

lcc will accept which code ? How are you going to
refer to members ? Examples please.
union {
struct{
int a;
int b;
};
struct{
float c;
};
}un;

int main(void)
{

un.a = 1;
return 0;
}


lcc-win32 doesn't accept this code in conforming mode, does it?

The problem is that all windows header files use this. I DID emit an
error for this, but people complained that then you could NOT
compile a windows program in conforming mode, what made the
conforming mode useless for all practical purposes.

Then, I took out the error and made this exception. I do not
see any way out of this dilemma.
The canonical way of approaching this is by inserting compiler magic into
the header which will turn on extensions without triggering errors, but only
for that header -- this is how C library headers ensure they compile no
matter how the compiler's invoked.

Unfortunately, although Win32 can be said to constitute a platform, the
Win32 headers themselves are often third-party, so this technique may not
always be usable.

The correct solution then, however, is simply to *not compile Win32
programs* in conforming mode. Your claim that this makes conforming mode
useless puts the cart before the horse: it's Win32's fault for forcing the
compiler to be put in a non-conforming mode, not strictly conforming C's
fault that you can't write Win32 programs in it. You can't have your cake
and eat it too.

What you are offering your users is an "almost conforming" mode, which is
fine, but pretending that this is actually the conforming mode when you
don't have one is disingenuous.

S.
Sep 15 '06 #24

P: n/a
Skarmander wrote:
jacob navia wrote:
>Keith Thompson wrote:
>>jacob navia <ja***@jacob.remcomp.frwrites:

Spiros Bousbouras wrote:

jacob navia wrote:
>
>
>This is not strictly valid C but it is a common extension.
>lcc-win32 will accept this code, and it is practical since
>it allows you to avoid specifying the whole "path" to
>the member and giving you more flexibility in the
>layout of the structire without changing the code.
>
>
lcc will accept which code ? How are you going to
refer to members ? Examples please.
>

union {
struct{
int a;
int b;
};
struct{
float c;
};
}un;

int main(void)
{

un.a = 1;
return 0;
}

lcc-win32 doesn't accept this code in conforming mode, does it?

The problem is that all windows header files use this. I DID emit an
error for this, but people complained that then you could NOT
compile a windows program in conforming mode, what made the
conforming mode useless for all practical purposes.

Then, I took out the error and made this exception. I do not
see any way out of this dilemma.
The canonical way of approaching this is by inserting compiler magic
into the header which will turn on extensions without triggering errors,
but only for that header -- this is how C library headers ensure they
compile no matter how the compiler's invoked.

Unfortunately, although Win32 can be said to constitute a platform, the
Win32 headers themselves are often third-party, so this technique may
not always be usable.

The correct solution then, however, is simply to *not compile Win32
programs* in conforming mode. Your claim that this makes conforming mode
useless puts the cart before the horse: it's Win32's fault for forcing
the compiler to be put in a non-conforming mode, not strictly conforming
C's fault that you can't write Win32 programs in it. You can't have your
cake and eat it too.

What you are offering your users is an "almost conforming" mode, which
is fine, but pretending that this is actually the conforming mode when
you don't have one is disingenuous.

S.
Well I could add a

-pedantic

flag like another well known compiler...

Maybe that is the solution. You would have

-ansic (conforming except _stdcall and anonymous structures)

-pedantic (100% heathfield compatible)
Sep 15 '06 #25

P: n/a
jacob navia <ja***@jacob.remcomp.frwrites:
Keith Thompson wrote:
>jacob navia <ja***@jacob.remcomp.frwrites:
[...]
>> union {
struct{
int a;
int b;
};
struct{
float c;
};
}un;

int main(void)
{

un.a = 1;
return 0;
}
lcc-win32 doesn't accept this code in conforming mode, does it?

The problem is that all windows header files use this. I DID emit an
error for this, but people complained that then you could NOT
compile a windows program in conforming mode, what made the
conforming mode useless for all practical purposes.

Then, I took out the error and made this exception. I do not
see any way out of this dilemma.
So lcc-win32's "conforming mode" is not conforming.

(It can't recognize when it's processing a Windows header file?)

--
Keith Thompson (The_Other_Keith) 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.
Sep 15 '06 #26

P: n/a
jacob navia wrote:
Spiros Bousbouras wrote:
>jacob navia wrote:
>>Spiros Bousbouras wrote:
jacob navia wrote:

This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code, and it is practical since
it allows you to avoid specifying the whole "path" to
the member and giving you more flexibility in the
layout of the structire without changing the code.

lcc will accept which code ? How are you going to
refer to members ? Examples please.

union {
struct{
int a;
int b;
};
struct{
float c;
};
}un;

int main(void)
{
un.a = 1;
return 0;
}

Interesting. Can you say a bit about what
algorithm you use ? I mean does the compiler
search in arbitrary depth in structures/unions
which contain structures/unions as fields which
contain structures/unions as fields and so on, to
see if a field is uniquely named and if it is then it
will assume that this is the field which is being referred ?

How will the compiler react to the following ?

union {
struct{
int a;
int b;
};
struct{
float a;
float b;
};
}un;

The algorithm is simple:

It requires that all field names (at any depths) are UNIQUE,
so your example will NOT work. The compiler will start a depth first
search in the whole nested structures with a field for that
name, and if it finds it it will automatically generate the
path to it.

I have the idea of this extensions from the Plan9 compiler
by Dennis Ritchie.
Which, in turn, is basically what Pascal has done for roughly the
past 40 years. It is still not legal C, and to suggest that it is
does a disservice to all.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

Sep 15 '06 #27

P: n/a
On 15/9/06 09:57, Richard Heathfield wrote:
jacob navia said:
>Richard Heathfield wrote:
>>And it's my right to express my opinion that you seem to be desperate for
any chance to promote your squalid little implementation, because if you
don't, people might forget it's there.
We hit for the first time a download rate of
more than 1 000 downloads per day yesterday.

Gosh. Your mouse-finger must be all worn out.
Lummy. I thought I'd walked into c.l.objective-c by mistake reading
this thread :-)
Sep 15 '06 #28

P: n/a
jacob navia <ja***@jacob.remcomp.frwrote:
Keith Thompson wrote:
jacob navia <ja***@jacob.remcomp.frwrites:
union {
struct{
int a;
int b;
};
struct{
float c;
};
}un;

int main(void)
{

un.a = 1;
return 0;
}
lcc-win32 doesn't accept this code in conforming mode, does it?

The problem is that all windows header files use this.
In other words, lcc-win32 is not a C implementation. Film at eleven...

Richard
Sep 15 '06 #29

P: n/a
Keith Thompson wrote:
jacob navia <ja***@jacob.remcomp.frwrites:
>>Keith Thompson wrote:
>>>jacob navia <ja***@jacob.remcomp.frwrites:

[...]
>>> union {
struct{
int a;
int b;
};
struct{
float c;
};
}un;

int main(void)
{

un.a = 1;
return 0;
}

lcc-win32 doesn't accept this code in conforming mode, does it?

The problem is that all windows header files use this. I DID emit an
error for this, but people complained that then you could NOT
compile a windows program in conforming mode, what made the
conforming mode useless for all practical purposes.

Then, I took out the error and made this exception. I do not
see any way out of this dilemma.


So lcc-win32's "conforming mode" is not conforming.

(It can't recognize when it's processing a Windows header file?)
No it can't because they could have *any* name.

I have just introduced a

-pedantic

option that will be 100% ped^h^h^h conforming.
:-)

Sep 15 '06 #30

P: n/a
jacob navia wrote:
Richard Heathfield wrote:
.... snip ...
>>
So lcc-win32 has no conforming mode? Interesting. So it's not a
C compiler after all.

I prefer keeping the conforming mode for windows programs
than making a 100% conforming mode that can't be used in
practice and is only useful to satisfy the
requirements of the few "regulars" in comp.lang.c.
Since it only compiles Navia-C, and cannot detect errors in C
source code, it should never even be mentioned on c.l.c. You
should consider taking your comments to a Windows newsgroup, where
they might be topical.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

Sep 15 '06 #31

P: n/a
jacob navia <ja***@jacob.remcomp.frwrote:
Richard Bos wrote:
jacob navia <ja***@jacob.remcomp.frwrote:
>This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code,
Yeah, but then, if you spit on a floppy disk your toy will probably
accept the result as perfectly good C with a boatload of happy happy
extensions, so that means nothing.

What the OP posted, and what you conveniently but luserishly snipped
completely, is not just "not strictly valid C"; it's strictly not valid
C. That's all he asked for. Advertisements were not requested.
The subject of the quetion was answered with my FIRST sentence:

"This is not strictly valid C".
And had you left it at that, you would have been almost correct.

But no, you had to advertise your broken, not even remotely C pet
project again. If you could learn not to do that, you might even grow up
to be a man some day.

Richard
Sep 15 '06 #32

P: n/a
Spiros Bousbouras wrote:
How will the compiler react to the following ?

union {
struct{
int a;
int b;
};
struct{
float a;
float b;
};
}un;
that extension originates in the plan9 compiler, and
was adopted (bastardized & with many limitations)
first by MSVC, then by gcc.

it's actually a very useful extensions; you can do with that
everything you can do with inheritance in C++, and more.

in this case, unlike gcc, the plan9 compiler will complain about
'ambiguous structure element' and give up if you try to access
either un.a or un.b.

Sep 15 '06 #33

P: n/a
Richard Bos wrote:
jacob navia <ja***@jacob.remcomp.frwrote:
>>The subject of the quetion was answered with my FIRST sentence:

"This is not strictly valid C".


And had you left it at that, you would have been almost correct.

But no, you had to advertise your broken, not even remotely C pet
project again. If you could learn not to do that, you might even grow up
to be a man some day.

Richard
I am "not a man"...

GOSH !!!

My virility depends on the conforming mode of my
compiler system :-)

Mr Bos, you are A MAN!!!

I would never doubt it, even if you use a castrated
C compiler that can't do anything else than ISO C.

jacob
Sep 15 '06 #34

P: n/a
Racaille wrote:
Spiros Bousbouras wrote:
>>How will the compiler react to the following ?

union {
struct{
int a;
int b;
};
struct{
float a;
float b;
};
}un;


that extension originates in the plan9 compiler, and
was adopted (bastardized & with many limitations)
first by MSVC, then by gcc.

it's actually a very useful extensions; you can do with that
everything you can do with inheritance in C++, and more.

in this case, unlike gcc, the plan9 compiler will complain about
'ambiguous structure element' and give up if you try to access
either un.a or un.b.
Salut Racaille!

I have followed exactly the same behavior as that compiler.

jacob

P.S. lcc-win32 est a Villetaneuse, 93430.

Sep 15 '06 #35

P: n/a
jacob navia wrote:
Keith Thompson wrote:
<snip>
>So lcc-win32's "conforming mode" is not conforming.

(It can't recognize when it's processing a Windows header file?)

No it can't because they could have *any* name.
Not true. The Win32 API requires headers to have certain names, just like
the C library does.

In particular, windef.h must exist, and any program that #includes
<windows.hwill pull in <windef.hvery early on, which will #define WIN32
if the user hasn't already done so. User programs are not expected to
include this file directly (and if they do they presumably don't care about
conformity).

Checking for this would be a fairly reliable way of detecting a Win32
header. Of course, you do need to invest a bit of work to get the
compiler/preprocessor to recognize such an include chain, and you must take
care not to trigger on just any old windef.h (it would be sufficient to
check if WIN32 is defined after windef.h has been preprocessed).

Failing that, GCC (rather MinGW) uses its own copies of the Win32 headers
with "#pragma GCC system_header" to invoke a non-conforming mode for just
those headers, an approach which is even more reliable, though it requires
you to distribute your own headers, which is not attractive.

Failing *that*, you could have your compiler differentiate between system
header includes and just any old includes based on file system path and
options, so that it knows when it's reading such a header file and should
invoke non-conforming mode.

It's useful to have some sort of mechanism for this anyway, because it
allows you to write system headers without worrying about what options the
user has set that might affect compilation.

S.
Sep 15 '06 #36

P: n/a
I have added a -pedantic option
that will solve this problem.

With that option, _stdcall, and anonymous structures are
forbidden. No windows programs then. But then, that is
no longer *my* problem :-)

Sep 15 '06 #37

P: n/a
jacob navia wrote:
Spiros Bousbouras wrote:
>jacob navia wrote:

>>This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code, and it is practical since
it allows you to avoid specifying the whole "path" to
the member and giving you more flexibility in the
layout of the structire without changing the code.


lcc will accept which code ? How are you going to
refer to members ? Examples please.

union {
struct{
int a;
int b;
};
struct{
float c;
};
}un;

int main(void)
{

un.a = 1;
return 0;
}
K. Thompson implemented this in his "C" compiler
for Plan 9 too, btw :-)
Sep 15 '06 #38

P: n/a
jacob navia posted:
It will complain at the point of the declaration.

At which point, I'd like to complain about the lack of quote snippage being
undertaken by the two of you.

--

Frederick Gotham
Sep 15 '06 #39

P: n/a
Frederick Gotham wrote:
jacob navia posted:
It will complain at the point of the declaration.


At which point, I'd like to complain about the lack of quote snippage being
undertaken by the two of you.
Jacob and Navia are just one person :-D

Sep 15 '06 #40

P: n/a
Spiros Bousbouras wrote:
jacob navia wrote:

>>This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code, and it is practical since
it allows you to avoid specifying the whole "path" to
the member and giving you more flexibility in the
layout of the structire without changing the code.


lcc will accept which code ? How are you going to
refer to members ? Examples please.
Like we have done for years,just do not
use conflicting names, and it works fine
(for some compilers, like MS,watcom,bc,tc....)
Sep 15 '06 #41

P: n/a
jacob navia <ja***@jacob.remcomp.frwrites:
[...]
Well I could add a

-pedantic

flag like another well known compiler...

Maybe that is the solution. You would have

-ansic (conforming except _stdcall and anonymous structures)

-pedantic (100% heathfield compatible)
Yes, you could. But since such a mode would conform to the ISO C
standard, not to anything having directly to do with Mr. Heathfield,
your "100% heathfield compatible" remark is gratuitous and insulting.

--
Keith Thompson (The_Other_Keith) 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.
Sep 15 '06 #42

P: n/a
Sjouke Burry wrote:
Spiros Bousbouras wrote:
jacob navia wrote:

>This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code, and it is practical since
it allows you to avoid specifying the whole "path" to
the member and giving you more flexibility in the
layout of the structire without changing the code.

lcc will accept which code ? How are you going to
refer to members ? Examples please.
Like we have done for years,just do not
use conflicting names, and it works fine
(for some compilers, like MS,watcom,bc,tc....)
Who's "we" ? It's not something *I* would do because
to have at several places in my code something like
str_name.field_name when in reality it's
str_name....intermediate_stuff...field_name sounds like
flirting with disaster. If I wanted to save keystrokes I
would either use vim's abbreviations feature or assign
the field values I'm interested in to temporary variables.

Sep 15 '06 #43

P: n/a
Spiros Bousbouras wrote:
Sjouke Burry wrote:

>>Spiros Bousbouras wrote:
>>>jacob navia wrote:

This is not strictly valid C but it is a common extension.
lcc-win32 will accept this code, and it is practical since
it allows you to avoid specifying the whole "path" to
the member and giving you more flexibility in the
layout of the structire without changing the code.
lcc will accept which code ? How are you going to
refer to members ? Examples please.

Like we have done for years,just do not
use conflicting names, and it works fine
(for some compilers, like MS,watcom,bc,tc....)


Who's "we" ? It's not something *I* would do because
to have at several places in my code something like
str_name.field_name when in reality it's
str_name....intermediate_stuff...field_name sounds like
flirting with disaster. If I wanted to save keystrokes I
would either use vim's abbreviations feature or assign
the field values I'm interested in to temporary variables.
It is not to save keystrokes. It is for giving you the
flexibility of changing the "inheritance" path as requirements
change.

instead of
CustomerInfo->struct_a->struct_b->struct_c->CustomerBalance

you write
CustomerInfo->CustomerBalance

and you are free to REARRANGE the intermediate structures as you wish,
and as changing requirements need.
Sep 15 '06 #44

P: n/a
jacob navia <ja***@jacob.remcomp.frwrites:
[...]
It is not to save keystrokes. It is for giving you the
flexibility of changing the "inheritance" path as requirements
change.

instead of
CustomerInfo->struct_a->struct_b->struct_c->CustomerBalance

you write
CustomerInfo->CustomerBalance

and you are free to REARRANGE the intermediate structures as you wish,
and as changing requirements need.
Great. I'm very happy that you're able to do this in your own
language. It cannot be done in standard C which, for the Nth time, is
what we discuss in this newsgroup. As you know perfectly well.

--
Keith Thompson (The_Other_Keith) 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.
Sep 15 '06 #45

P: n/a
jacob navia wrote:
[...]
It is not to save keystrokes. It is for giving you the
flexibility of changing the "inheritance" path as requirements
change.

instead of
CustomerInfo->struct_a->struct_b->struct_c->CustomerBalance

you write
CustomerInfo->CustomerBalance

and you are free to REARRANGE the intermediate structures as you wish,
and as changing requirements need.
At the expense of maintainability, as you have hidden what, and where,
CustomerBalance is. I'd hate to have to search through who knows how
many header files, hoping to track down the path to CustomerBalance.

And, what happens when some structure, which is contained in some
structure, which is pointed to by another structure within CustomerInfo
adds a pointer to a structure which contains a pointer to a structure
which has a CustomerBalance member?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

Sep 16 '06 #46

P: n/a
On 14 Sep 2006 22:54:10 -0700, "Naresh" <nk*********@gmail.comwrote
in comp.lang.c:
The main usage of Annonymous Union is to limit scope of some name
space. If you are defining Anno. union, you have to take care scope of
variable yourself.
There is no "main use" of anonymous unions in C, because there are no
anonymous unions in C. Not at all. Period.

If you have a compiler that accepts this, either it is not a C
compiler, or perhaps it is not being invoked in a manner that would
cause it to be a C compiler.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Sep 16 '06 #47

P: n/a
Jack Klein wrote:
On 14 Sep 2006 22:54:10 -0700, "Naresh" <nk*********@gmail.comwrote
in comp.lang.c:
The main usage of Annonymous Union is to limit scope of some name
space. If you are defining Anno. union, you have to take care scope of
variable yourself.

There is no "main use" of anonymous unions in C, because there are no
anonymous unions in C. Not at all. Period.

If you have a compiler that accepts this, either it is not a C
compiler, or perhaps it is not being invoked in a manner that would
cause it to be a C compiler.
Or it is a C compiler supporting anonymous unions as an extension. As
long as a diagnostic is issued, there is no problem. This diagnostic
may be an error, a warning, a notice, a remark, or almost anything
else, and the standard does not require implementations to refuse to
translate any program (with an exception for #error).

Sep 16 '06 #48

This discussion thread is closed

Replies have been disabled for this discussion.