resolving a warning error

[michael potter]

I would like to code a prototype that returns an enum, but not declare
the enum.

This works on several systems and compilers, but fails on aix xlc.

Here is the sample code:

enum anEnum someFunc(void);

when i run:
xlc -c someFunc.c
i get
1506-103 (W) Tag anEnum requires a complete definition before it is
used.

Obviously, I could declare the enum, but
I would like to avoid declaring the enum as I would like
to hide the values of the enum from functions that don't need it.

I use a similar technique to hide the members of a struct; I just pass
the pointer to the struct and the compiler does not require a full
definition
of the struct.

How can I eliminate that warning message without eliminating other
warning messages and without declaring the enum?

[Eric Sosman]

Re: resolving a warning error

michael potter wrote:[color=blue]
> I would like to code a prototype that returns an enum, but not declare
> the enum.
>
> This works on several systems and compilers, but fails on aix xlc.
>
> Here is the sample code:
>
> enum anEnum someFunc(void);
>
> when i run:
> xlc -c someFunc.c
> i get
> 1506-103 (W) Tag anEnum requires a complete definition before it is
> used.
>
> Obviously, I could declare the enum, but
> I would like to avoid declaring the enum as I would like
> to hide the values of the enum from functions that don't need it.
>
> I use a similar technique to hide the members of a struct; I just pass
> the pointer to the struct and the compiler does not require a full
> definition
> of the struct.
>
> How can I eliminate that warning message without eliminating other
> warning messages and without declaring the enum?[/color]

By using `int someFunc(void); ' instead.

"But I'll lose type safety!" Well, no. In the first
place, there's almost no type safety to begin with: C's
enums are pretty weak. In the second place, if you intend
to hide the enum's values from someFunc(), what will its
`return' statements look like? Where are you going to get
a known-to-be-valid value? Copy it from a global? Bah!

Or perhaps you intend to reveal the enum values to
someFunc() but hide them from someFunc()'s callers. What's
the point of that? It means that all the callers can do
with someFunc()'s returned value is pass it around among
themselves without understanding: They can't perform a
meaningful test with an `if' or a `switch' or any such;
all they can do is hand it from place to place as an
"opaque" value. An `int' is perfectly suited to such use.

`enum anEnum' doesn't seem to add value here.

--
Eric.Sosman@sun .com

[Michael Wojcik]

Re: resolving a warning error


In article <2379dacc.04102 71530.531989ef@ posting.google. com>, pottmi@gmail.co m (michael potter) writes:[color=blue]
> I would like to code a prototype that returns an enum, but not declare
> the enum.
>
> I use a similar technique to hide the members of a struct; I just pass
> the pointer to the struct and the compiler does not require a full
> definition of the struct.
>
> How can I eliminate that warning message without eliminating other
> warning messages and without declaring the enum?[/color]

You can't. Well, you may be able to do specifically what you ask
in your final question - eliminate one diagnostic from one particular
implementation - but that's off-topic here. What you cannot do is
use an enum without declaring it, in C. C permits incomplete structs
in various contexts; it does not permit incomplete enums. Some
implementations may allow the latter, but it is an extension.

There's a good reason for not allowing incomplete enums - the
implementation is allowed to pick any integral type for an enum,
provided that type can represent all the values of the enum. The
latter are always of type int, but they may fit in the range of, say,
unsigned char, in which case the implementation could use unsigned
char for that enum type.

If the implementation doesn't have a complete definition of the enum,
it may not know what integral type to use for it.

Of course, that doesn't preclude pointers to incomplete enums, just
as you can have pointers to incomplete structs. Why those were
omitted is a mystery to me; I suppose no one on the committee thought
they were sufficiently important.

--
Michael Wojcik michael.wojcik@ microfocus.com

Pocket #16: A Ventriloquist's "Helper" -- Recordings for Divers Occasions,
especially cries to put in the mouths of enemies -- "God Bless Captain
Vere!" "Les jeux sont faits!" &c. -- Joe Green

[Dan Pop]

Re: resolving a warning error

In <2379dacc.04102 71530.531989ef@ posting.google. com> pottmi@gmail.co m (michael potter) writes:
[color=blue]
>I would like to code a prototype that returns an enum, but not declare
>the enum.
>
>This works on several systems and compilers, but fails on aix xlc.[/color]

Not if you invoke them in conforming mode:

fangorn:~/tmp 200> gcc test.c
fangorn:~/tmp 201> icc test.c
fangorn:~/tmp 202> gcc -ansi -pedantic test.c
test.c: In function `main':
test.c:8: warning: ISO C forbids forward references to `enum' types
fangorn:~/tmp 203> icc -Xc test.c
test.c(8): warning #102: forward declaration of enum type is nonstandard
enum anEnum someFunc(void);
^
The diagnostic is *required* by the C standard:

6.7.2.3 Tags

Constraints

1 A specific type shall have its content defined at most once.

2 A type specifier of the form

enum identifier

without an enumerator list shall only appear after the type it
specifies is complete.
[color=blue]
>How can I eliminate that warning message without eliminating other
>warning messages and without declaring the enum?[/color]

Your only chance is to find a way of invoking xlc in nonconforming mode,
because a conforming compiler MUST generate it, but you *really* don't
want to do that.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union

[Dan Pop]

Re: resolving a warning error

In <clr2s8$f0s$1@n ews1brm.Central .Sun.COM> Eric Sosman <eric.sosman@su n.com> writes:
[color=blue]
>michael potter wrote:[color=green]
>> I would like to code a prototype that returns an enum, but not declare
>> the enum.
>>
>> This works on several systems and compilers, but fails on aix xlc.
>>
>> Here is the sample code:
>>
>> enum anEnum someFunc(void);
>>
>> when i run:
>> xlc -c someFunc.c
>> i get
>> 1506-103 (W) Tag anEnum requires a complete definition before it is
>> used.
>>
>> Obviously, I could declare the enum, but
>> I would like to avoid declaring the enum as I would like
>> to hide the values of the enum from functions that don't need it.
>>
>> I use a similar technique to hide the members of a struct; I just pass
>> the pointer to the struct and the compiler does not require a full
>> definition
>> of the struct.
>>
>> How can I eliminate that warning message without eliminating other
>> warning messages and without declaring the enum?[/color]
>
> By using `int someFunc(void); ' instead.[/color]

Can I have the chapter and verse stating that enumerated types are
compatible with type int?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union

[Eric Sosman]

Re: resolving a warning error

Dan Pop wrote:[color=blue]
> In <clr2s8$f0s$1@n ews1brm.Central .Sun.COM> Eric Sosman <eric.sosman@su n.com> writes:
>[color=green]
>>michael potter wrote:
>>[color=darkred]
>>>I would like to code a prototype that returns an enum, but not declare
>>>the enum.
>>> [...]
>>>How can I eliminate that warning message without eliminating other
>>>warning messages and without declaring the enum?[/color]
>>
>> By using `int someFunc(void); ' instead.[/color]
>
> Can I have the chapter and verse stating that enumerated types are
> compatible with type int?[/color]

No, of course not: 6.7.2.2/4 lists the allowable
types, and not all are necessarily compatible with `int'
on all implementations . However, any of the enumerated
values is compatible with `int' because each *is* an `int'.

It is, of course, possible to store a non-enumerated
value in an enum variable:

enum { FOO = 1, BAR = 3, BAZ = 5 } x = 2;

is legal C, unfortunately. (Note that if 2 were replaced
with 128 or -300 this would not be legal C: the compiler
might have chosen an integer type too narrow for these
non-enumerated values.) But I don't think that's a serious
objection -- after all, what the O.P. wants to do is already
a violation of C's rules, and substituting `int' seems a
reasonable way to begin a return to legality.

--
Eric.Sosman@sun .com

[Keith Thompson]

Re: resolving a warning error

Dan.Pop@cern.ch (Dan Pop) writes:[color=blue]
> In <clr2s8$f0s$1@n ews1brm.Central .Sun.COM> Eric Sosman
> <eric.sosman@su n.com> writes:[color=green]
>>michael potter wrote:[/color][/color]
[...][color=blue][color=green][color=darkred]
>>> How can I eliminate that warning message without eliminating other
>>> warning messages and without declaring the enum?[/color]
>>
>> By using `int someFunc(void); ' instead.[/color]
>
> Can I have the chapter and verse stating that enumerated types are
> compatible with type int?[/color]

They're assignment-compatible, which is good enough for the problem
under discussion.

Declaring

int someFunc(void);

in foo.h and

enum anEnum someFunc(void) { /* blah blah */ }

in foo.c could cause problems, particularly on systems where the types
have different sizes, but I don't think that's what Eric was
suggesting.

If you consistently treat someFunc as a function returning int, you
can still use enum anEnum internally.

--
Keith Thompson (The_Other_Keit h) kst-u@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.

[Dan Pop]

Re: resolving a warning error

In <clrhlg$4vs$1@n ews1brm.Central .Sun.COM> Eric Sosman <eric.sosman@su n.com> writes:
[color=blue]
>Dan Pop wrote:[color=green]
>> In <clr2s8$f0s$1@n ews1brm.Central .Sun.COM> Eric Sosman <eric.sosman@su n.com> writes:
>>[color=darkred]
>>>michael potter wrote:
>>>
>>>>I would like to code a prototype that returns an enum, but not declare
>>>>the enum.
>>>> [...]
>>>>How can I eliminate that warning message without eliminating other
>>>>warning messages and without declaring the enum?
>>>
>>> By using `int someFunc(void); ' instead.[/color]
>>
>> Can I have the chapter and verse stating that enumerated types are
>> compatible with type int?[/color]
>
> No, of course not: 6.7.2.2/4 lists the allowable
>types, and not all are necessarily compatible with `int'
>on all implementations .[/color]

Free clue: the concept of compatible types is NOT implementation
dependent. It is the C standard itself that specifies what types are
compatible:

1 Two types have compatible type if their types are the
same. Additional rules for determining whether two types are
compatible are described in 6.7.2 for type specifiers, in 6.7.3
for type qualifiers, and in 6.7.5 for declarators.
[color=blue]
>However, any of the enumerated
>values is compatible with `int' because each *is* an `int'.[/color]

Which is entirely irrelevant here: if the function declaration doesn't
match the function definition, the behaviour is undefined:

2 All declarations that refer to the same object or function shall
have compatible type; otherwise, the behavior is undefined.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union

[Dan Pop]

Re: resolving a warning error

In <clr2s8$f0s$1@n ews1brm.Central .Sun.COM> Eric Sosman <eric.sosman@su n.com> writes:
[color=blue]
>michael potter wrote:[color=green]
>> I would like to code a prototype that returns an enum, but not declare
>> the enum.
>>
>> This works on several systems and compilers, but fails on aix xlc.
>>
>> Here is the sample code:
>>
>> enum anEnum someFunc(void);
>>
>> when i run:
>> xlc -c someFunc.c
>> i get
>> 1506-103 (W) Tag anEnum requires a complete definition before it is
>> used.
>>
>> Obviously, I could declare the enum, but
>> I would like to avoid declaring the enum as I would like
>> to hide the values of the enum from functions that don't need it.
>>
>> I use a similar technique to hide the members of a struct; I just pass
>> the pointer to the struct and the compiler does not require a full
>> definition
>> of the struct.
>>
>> How can I eliminate that warning message without eliminating other
>> warning messages and without declaring the enum?[/color]
>
> By using `int someFunc(void); ' instead.
>
> "But I'll lose type safety!" Well, no. In the first
>place, there's almost no type safety to begin with: C's
>enums are pretty weak. In the second place, if you intend
>to hide the enum's values from someFunc(), what will its
>`return' statements look like? Where are you going to get
>a known-to-be-valid value? Copy it from a global? Bah!
>
> Or perhaps you intend to reveal the enum values to
>someFunc() but hide them from someFunc()'s callers.[/color]

Or neither. He may intend to hide the actual enum definition from
third party entities that neither define nor call someFunc(), they
merely pass its address to functions that have access to the actual
definition of enum anEnum. The logical equivalent of type FILE in
<stdio.h>.

It would be nice if that were possible, but it isn't. He must *define*
someFunc() as returning int, not only declare it as such.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union

[Dan Pop]

Re: resolving a warning error

In <lnekjishjn.fsf @nuthaus.mib.or g> Keith Thompson <kst-u@mib.org> writes:
[color=blue]
>Dan.Pop@cern.c h (Dan Pop) writes:[color=green]
>> In <clr2s8$f0s$1@n ews1brm.Central .Sun.COM> Eric Sosman
>> <eric.sosman@su n.com> writes:[color=darkred]
>>>michael potter wrote:[/color][/color]
>[...][color=green][color=darkred]
>>>> How can I eliminate that warning message without eliminating other
>>>> warning messages and without declaring the enum?
>>>
>>> By using `int someFunc(void); ' instead.[/color]
>>
>> Can I have the chapter and verse stating that enumerated types are
>> compatible with type int?[/color]
>
>They're assignment-compatible, which is good enough for the problem
>under discussion.[/color]

Maybe, but not for the suggested solution.
[color=blue]
>Declaring
>
> int someFunc(void);
>
>in foo.h and
>
> enum anEnum someFunc(void) { /* blah blah */ }
>
>in foo.c could cause problems, particularly on systems where the types
>have different sizes,[/color]

It invokes undefined behaviour (unless enum anEnum happens to be
compatible with type int, but no program can make this assumption in
c.l.c):

2 All declarations that refer to the same object or function shall
have compatible type; otherwise, the behavior is undefined.

so I have no idea where you got your "could" and the nonsense about
different sizes from. But maybe you can provide some chapter and verse
that I have missed....
[color=blue]
>but I don't think that's what Eric was suggesting.[/color]

This is effectively what he wrote. He didn't suggest *any* change in the
function definition, did he?
[color=blue]
>If you consistently treat someFunc as a function returning int, you
>can still use enum anEnum internally.[/color]

This is true, if by "consistent ly treat" you mean also defining it like
this.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union

[Eric Sosman]

Re: resolving a warning error

Dan Pop wrote:[color=blue]
> In <clrhlg$4vs$1@n ews1brm.Central .Sun.COM> Eric Sosman <eric.sosman@su n.com> writes:
>[color=green]
>>Dan Pop wrote:
>>[color=darkred]
>>>In <clr2s8$f0s$1@n ews1brm.Central .Sun.COM> Eric Sosman <eric.sosman@su n.com> writes:
>>>
>>>>michael potter wrote:
>>>>
>>>>>I would like to code a prototype that returns an enum, but not declare
>>>>>the enum.
>>>>>[...]
>>>>>How can I eliminate that warning message without eliminating other
>>>>>warning messages and without declaring the enum?
>>>>
>>>> By using `int someFunc(void); ' instead.
>>>
>>>Can I have the chapter and verse stating that enumerated types are
>>>compatible with type int?[/color]
>>
>> No, of course not: 6.7.2.2/4 lists the allowable
>>types, and not all are necessarily compatible with `int'
>>on all implementations .[/color]
>
> Free clue: the concept of compatible types is NOT implementation
> dependent. It is the C standard itself that specifies what types are
> compatible:
>
> 1 Two types have compatible type if their types are the
> same. Additional rules for determining whether two types are
> compatible are described in 6.7.2 for type specifiers, in 6.7.3
> for type qualifiers, and in 6.7.5 for declarators.
>[color=green]
>>However, any of the enumerated
>>values is compatible with `int' because each *is* an `int'.[/color]
>
> Which is entirely irrelevant here: if the function declaration doesn't
> match the function definition, the behaviour is undefined:
>
> 2 All declarations that refer to the same object or function shall
> have compatible type; otherwise, the behavior is undefined.[/color]

Aha! I think I understand the confusion, and my
elliptical advice was at least partly responsible for
it. I did not mean to suggest that the O.P should
declare his function as returning an int while defining
it to return an enum, but to declare and define it as
returning an int. I didn't say so explicitly, for much
the same reason I don't tell grownups to look both ways
when crossing streets.

Declarations and definitions should agree, hence,
a (substantive) change to one should imply a corresponding
change to the other.

--
Eric.Sosman@sun .com

[Dan Pop]

Re: resolving a warning error

In <clttmu$b7v$1@n ews1brm.Central .Sun.COM> Eric Sosman <eric.sosman@su n.com> writes:
[color=blue]
> Aha! I think I understand the confusion, and my
>elliptical advice was at least partly responsible for
>it. I did not mean to suggest that the O.P should
>declare his function as returning an int while defining
>it to return an enum, but to declare and define it as
>returning an int.[/color]

The bit about defining it as returning an int was completely missing
from your post.
[color=blue]
>I didn't say so explicitly, for much
>the same reason I don't tell grownups to look both ways
>when crossing streets.[/color]

Yet, you treated the OP as a "kid" all over your post, all the points
you've made being trivial for "grownups".

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Currently looking for a job in the European Union