Is an empty translation unit valid?

[Chris Croughton]

Does a translation unit have to have at least one externally visible
declaration or function definition to be valid? As I read the standard,
it doesn't: it must have at least one declaration or function definition,
but they can be static, extern or even a typedef.

6.9 External definitions
1 translation-unit:
external-declaration
translation-unit external-declaration

external-declaration:
function-definition
declaration

6.9.1 Function definitions
1 function-definition:
declaration-specifiers declarator declaration-list(opt)
compound-statement

6.7 Declarations
1 declaration:
declaration-specifiers init-declarator-listopt ;
declaration-specifiers:
storage-class-specifier declaration-specifiers(opt)
type-specifier declaration-specifiers(opt)
type-qualifier declaration-specifiers(opt)
function-specifier declaration-specifiers(opt)

6.7.1 Storage-class specifiers
1 storage-class-specifier:
typedef
extern
static
auto
register

So as I read the standard a translation unit consisting of only

typedef int fred;

would be valid, and a conforming compiler shouldn't complain about it.

Is this correct, or have I missed something?

Chris C

[Lawrence Kirby]

On Tue, 28 Jun 2005 14:09:31 +0100, Chris Croughton wrote:

....

So as I read the standard a translation unit consisting of only

typedef int fred;

would be valid, and a conforming compiler shouldn't complain about it.

Yes, it is valid. However a conforming compiler can complain about
anything it likes. A translation unit with no definition having external
linkage seems to be useless, although correct. It is something that a
compiler could reasonably complain about, as long as it doesn't reject the
program.

Lawrence

[Chris Croughton]

On Wed, 29 Jun 2005 13:48:10 +0100, Lawrence Kirby
<lk****@netactive.co.uk> wrote:

On Tue, 28 Jun 2005 14:09:31 +0100, Chris Croughton wrote:

...

So as I read the standard a translation unit consisting of only

typedef int fred;

would be valid, and a conforming compiler shouldn't complain about it.
Yes, it is valid. However a conforming compiler can complain about
anything it likes.

True, it can complain. However, a compiler which complains about legal
programs too much has quality of implementation problems...
A translation unit with no definition having external
linkage seems to be useless, although correct. It is something that a
compiler could reasonably complain about, as long as it doesn't reject the
program.

Well, it's useless to the compiler, not necessarily useless in the
context of a multi-target build system (where parts of the program may
be not needed for a particular build, so they are conditionally compiled
out, as in the cases I'm dealing with).

I've found that having just a 'useless' typedef does indeed shut up the
compilers I'm using (whereas having an unreferenced static identifier
causes them to complain differently). Probably because it can't
complain reasonably about unused typedefs, there are millions of them in
header files...

Chris C

[Lawrence Kirby]

On Thu, 30 Jun 2005 11:47:48 +0100, Chris Croughton wrote:

On Wed, 29 Jun 2005 13:48:10 +0100, Lawrence Kirby
<lk****@netactive.co.uk> wrote:

On Tue, 28 Jun 2005 14:09:31 +0100, Chris Croughton wrote:

...

So as I read the standard a translation unit consisting of only

typedef int fred;

would be valid, and a conforming compiler shouldn't complain about it.
Yes, it is valid. However a conforming compiler can complain about
anything it likes.

True, it can complain. However, a compiler which complains about legal
programs too much has quality of implementation problems...

Compilers can generate a lot of warnins about technically correct code,
e.g. unused variable warnings. An unusable translation unit isn't an
unreasonable case for a warning.

A translation unit with no definition having external
linkage seems to be useless, although correct. It is something that a
compiler could reasonably complain about, as long as it doesn't reject the
program.

Well, it's useless to the compiler, not necessarily useless in the
context of a multi-target build system (where parts of the program may
be not needed for a particular build, so they are conditionally compiled
out, as in the cases I'm dealing with).

Unused variables can occur in similar circumstances. It may be a useful
diagnostic in other circumstances, this is just an argument for being able
to configure what warnings a compiler will generate.
I've found that having just a 'useless' typedef does indeed shut up the
compilers I'm using (whereas having an unreferenced static identifier
causes them to complain differently). Probably because it can't
complain reasonably about unused typedefs, there are millions of them in
header files...

Yes, it would be unreasonable to warn about an unused typedef.

Lawrence

[Kenny McCormack]

In article <sl******************@ccserver.keris.net>,
Chris Croughton <ch***@keristor.net> wrote:
....

Yes, it is valid. However a conforming compiler can complain about
anything it likes.

True, it can complain. However, a compiler which complains about legal
programs too much has quality of implementation problems...

Yes, but QOI is OT in clc.