type declaration in declaration of a parameter or return type of a function

[Luca Forlizzi]

hello

is it strictly conforming to declare a type (struct, union or enum)
in the declaration of a parameter
or of the return type of a function?
For instance:
struct s { int a; float b; } f( int ) ;
int g ( enum e { zero, one, two } x ) { enum e y; return x==y; }

 

[Johannes Schaub (litb)]

hello

is it strictly conforming to declare a type (struct, union or enum)
in the declaration of a parameter
or of the return type of a function?
For instance:
struct s { int a; float b; } f( int ) ;
int g ( enum e { zero, one, two } x ) { enum e y; return x==y; }

Yes it is strictly conforming. It should be noted that in the struct/union
case, you should better not include a tag. If you do, you cannot call the
function without invoking undefined behavior across translation units.

In any case with or without a tag, (in the struct/union case) you cannot
call the function from the same translation unit, except when called
directly recursively. And it is not possible for the struct/union case to
split the definition and declaration, when both of them appear in the same
translation unit. For the enum case, you cannot split it if the compiler
decides the underlying type "compatible type" used for the enumeration is
different for the two eumeration specifiers.

I could be wrong on this thoug, I'm only talking from what I recall.

 

[Luca Forlizzi]

Yes it is strictly conforming. It should be noted that in the struct/union
case, you should better not include a tag. If you do, you cannot call the
function without invoking undefined behavior across translation units.

In any case with or without a tag, (in the struct/union case) you cannot
call the function from the same translation unit, except when called
directly recursively. And it is not possible for the struct/union case to
split the definition and declaration, when both of them appear in the same
translation unit. For the enum case, you cannot split it if the compiler
decides the underlying type "compatible type" used for the enumeration is
different for the two eumeration specifiers.

I could be wrong on this thoug, I'm only talking from what I recall.

I think you are right when the new type is declared inside a parameter
declaration, because the scope of the declared type is the function
body (in case of a function definition).
However, if a new type is declared ad return type of the function:
if the type is declared just in the first declaration of the
function, everything is normal because the new type has file scope;
if the type is declared also in the following declaration of the
function it is a constraint violation.

Would you agree?

 

[Johannes Schaub (litb)]

I think you are right when the new type is declared inside a parameter
declaration, because the scope of the declared type is the function
body (in case of a function definition).
However, if a new type is declared ad return type of the function:
if the type is declared just in the first declaration of the
function, everything is normal because the new type has file scope;
if the type is declared also in the following declaration of the
function it is a constraint violation.

Would you agree?

Yes, I should have limited my sayings to the parameter type.

 

[Luca Forlizzi]

re-reading again your precious answer, I don't understand (and would
like to) the following:

Yes it is strictly conforming. It should be noted that in the struct/union
case, you should better not include a tag. If you do, you cannot call the
function without invoking undefined behavior across translation units.

why is it so? If in another translation unit I declare a compatible
struct/union type with identical tag and identical members, where is
the problem?
Reading sec. 6.2.7 I can see no difference between the case of two
structs/unions both without a tag and the case where they have
identical tags.


About the case of a type declaration in the return type of a function,
I remark that there is a "forbidden" case similar to the ones you
pointed out: if a struct/union type is declared in the type specifier
of the function definition, it should have a tag, otherwise you can't
declare any other object of that type so it is not possible to have a
return statement in the function body. I think it's valid not to have
a return in the function body, but the return value is indeterminate
and reading it produces undef. behavior.