is "typedef int int;" illegal????

[jacob navia]

Hi

Suppose you have somewhere

#define BOOL int

and somewhere else

typedef BOOL int;

This gives

typedef int int;

To me, this looks like a null assignment:

a = a;

Would it break something if lcc-win32 would accept that,
maybe with a warning?

Is the compiler *required* to reject that?

Microsoft MSVC: rejects it.
lcc-win32 now rejects it.
gcc (with no flags) accepts it with some warnnings.

Thanks

jacob
---
A free compiler system for windows:
http://www.cs.virginia.edu/~lcc-win32

[Robert Gamble]

jacob navia wrote:

Hi

Suppose you have somewhere

#define BOOL int

and somewhere else

typedef BOOL int;

This gives

typedef int int;
The typedef name must be an identifier, here you have a keyword.
To me, this looks like a null assignment:

a = a;
Maybe from an implementor's point of view but the Standard does not
allow it.
Would it break something if lcc-win32 would accept that,
maybe with a warning?
A diagnostic would be required, after that you can do anything you
want, including continuing to compile the program as you normally
would.
Is the compiler *required* to reject that?
Define reject. You are required to produce a diagnostic, that's it.
Microsoft MSVC: rejects it.
Good.
lcc-win32 now rejects it.
Good.
gcc (with no flags) accepts it with some warnnings.

It fails to compile for me (gcc 4.0.2):
error: two or more data types in declaration specifiers

Robert Gamble

[jacob navia]

Robert Gamble a écrit :

jacob navia wrote:

Hi

Suppose you have somewhere

#define BOOL int

and somewhere else

typedef BOOL int;

This gives

typedef int int;

The typedef name must be an identifier, here you have a keyword.

To me, this looks like a null assignment:

a = a;

Maybe from an implementor's point of view but the Standard does not
allow it.

Would it break something if lcc-win32 would accept that,
maybe with a warning?

A diagnostic would be required, after that you can do anything you
want, including continuing to compile the program as you normally
would.

OK, that is what I had in mind.

Is the compiler *required* to reject that?

Define reject. You are required to produce a diagnostic, that's it.

Reject means the program fails to compile. A warning is not a reject
since the program compiles.

Microsoft MSVC: rejects it.

Good.

lcc-win32 now rejects it.

Good.

gcc (with no flags) accepts it with some warnnings.

It fails to compile for me (gcc 4.0.2):
error: two or more data types in declaration specifiers

Strange, I get the following:

[root@gateway root]# gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/specs
gcc version 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)
[root@gateway root]# cat tint.c
typedef int int;
[root@gateway root]# gcc -c tint.c
tint.c:1: warning: useless keyword or type name in empty declaration
tint.c:1: warning: empty declaration
[root@gateway root]# ls -l tint.o
-rw-r--r-- 1 root root 703 Mar 24 16:17 tint.o
[root@gateway root]#

Program is not rejected.
Robert Gamble

[Robert Gamble]

jacob navia wrote:

Robert Gamble a écrit :

jacob navia wrote:

Hi

Suppose you have somewhere

#define BOOL int

and somewhere else

typedef BOOL int;

This gives

typedef int int;

The typedef name must be an identifier, here you have a keyword.

To me, this looks like a null assignment:

a = a;

Maybe from an implementor's point of view but the Standard does not
allow it.

Would it break something if lcc-win32 would accept that,
maybe with a warning?

A diagnostic would be required, after that you can do anything you
want, including continuing to compile the program as you normally
would.

OK, that is what I had in mind.

Is the compiler *required* to reject that?

Define reject. You are required to produce a diagnostic, that's it.

Reject means the program fails to compile. A warning is not a reject
since the program compiles.

With that definition no, you are not required to reject such a program
but you are certainly free to do so.

Microsoft MSVC: rejects it.

Good.

lcc-win32 now rejects it.

Good.

gcc (with no flags) accepts it with some warnnings.

It fails to compile for me (gcc 4.0.2):
error: two or more data types in declaration specifiers

Strange, I get the following:

[root@gateway root]# gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/specs
gcc version 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)
[root@gateway root]# cat tint.c
typedef int int;
[root@gateway root]# gcc -c tint.c
tint.c:1: warning: useless keyword or type name in empty declaration
tint.c:1: warning: empty declaration
[root@gateway root]# ls -l tint.o
-rw-r--r-- 1 root root 703 Mar 24 16:17 tint.o
[root@gateway root]#

Program is not rejected.

Quite a bit has changed since gcc 2.96 including the strictness of the
syntax and type checking. Note though that a diagnostic was still
produced.

Robert Gamble

[James Dennett]

jacob navia wrote:

Robert Gamble a écrit :

jacob navia wrote:

Hi

Suppose you have somewhere

#define BOOL int

and somewhere else

typedef BOOL int;

This gives

typedef int int;

The typedef name must be an identifier, here you have a keyword.

To me, this looks like a null assignment:

a = a;

Maybe from an implementor's point of view but the Standard does not
allow it.

Would it break something if lcc-win32 would accept that,
maybe with a warning?

A diagnostic would be required, after that you can do anything you
want, including continuing to compile the program as you normally
would.

OK, that is what I had in mind.

Is the compiler *required* to reject that?

Define reject. You are required to produce a diagnostic, that's it.

Reject means the program fails to compile. A warning is not a reject
since the program compiles.

The standard doesn't ever require a compiler to reject
code; it's quite legal for a C compiler to accept Fortran
code, so long as it prints out a diagnostic (maybe
"This looks like Fortran, not C... compiling it anyway...").

There is a common notion among compilers that a "warning" is
a non-fatal diagnostic and an "error" is a fatal diagnostic
(i.e., one which causes no object code to be produced), but
that is not standardised.

Microsoft MSVC: rejects it.

Good.

lcc-win32 now rejects it.

Good.

gcc (with no flags) accepts it with some warnnings.

It fails to compile for me (gcc 4.0.2):
error: two or more data types in declaration specifiers

Strange, I get the following:

[root@gateway root]# gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/specs
gcc version 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)
[root@gateway root]# cat tint.c
typedef int int;
[root@gateway root]# gcc -c tint.c
tint.c:1: warning: useless keyword or type name in empty declaration
tint.c:1: warning: empty declaration
[root@gateway root]# ls -l tint.o
-rw-r--r-- 1 root root 703 Mar 24 16:17 tint.o
[root@gateway root]#

Program is not rejected.

That's a nearly 6-year old compiler, and not an official GCC
release at that. Not to say that 2.96 didn't have its uses,
and maybe it still does, but it's far from the state of the
art.

-- James

[David R Tribble]

jacob navia wrote:

Suppose you have somewhere
#define BOOL int
and somewhere else
typedef BOOL int;

This gives
typedef int int;

To me, this looks like a null assignment:
a = a;

Robert Gamble wrote: Maybe from an implementor's point of view but the Standard does not
allow it.
The typedef name must be an identifier, here you have a keyword.

Exactly.

On a related note, I've suggested in the past that duplicate
(redundant) typedefs be allowed as long as they are semantically
equivalent, e.g.:

typedef long mytype; // A
typedef long mytype; // B, error in C99
typedef long int mytype; // C, error in C99

It would introduce no problems if the redundant typedefs at B and C
were allowed. C99 rules, however, disallow this, so we're forced to
do things like the following in all our header files:

// foo.h
#ifndef MYTYPE_DEF
typedef long mytype;
#define MYTYPE_DEF
#endif

// bar.h
#ifndef MYTYPE_DEF
typedef long int mytype;
#define MYTYPE_DEF
#endif
Allowing redundant typedefs parallels the rule allowing redundant
preprocessor macro definitions:

#define SIZE 100 // D
#define SIZE 100 // E, okay, duplicate allowed

This also parallels C++ semantics, which allow duplicate typedefs.

-drt

[jacob navia]

James Dennett a écrit :

Strange, I get the following:

[root@gateway root]# gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/specs
gcc version 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)
[root@gateway root]# cat tint.c
typedef int int;
[root@gateway root]# gcc -c tint.c
tint.c:1: warning: useless keyword or type name in empty declaration
tint.c:1: warning: empty declaration
[root@gateway root]# ls -l tint.o
-rw-r--r-- 1 root root 703 Mar 24 16:17 tint.o
[root@gateway root]#

Program is not rejected.

That's a nearly 6-year old compiler, and not an official GCC
release at that. Not to say that 2.96 didn't have its uses,
and maybe it still does, but it's far from the state of the
art.

-- James

Wow, this complicates this quite a bit.
If Microsoft AND gcc reject the code... I think better leave it as it is...
I thought that gcc let it pass with some warnings and intended to do the
same, but it is true that I have not upgraded gcc since quite a while.

thanks

[Eric Sosman]

David R Tribble wrote On 03/24/06 11:01,:

On a related note, I've suggested in the past that duplicate
(redundant) typedefs be allowed as long as they are semantically
equivalent, e.g.:

typedef long mytype; // A
typedef long mytype; // B, error in C99
typedef long int mytype; // C, error in C99

It seems to me "semantical ly equivalent" might
open an unpleasant can of worms. For example, are

typedef unsigned int mytype;
typedef size_t mytype;

"semantical ly equivalent" on an implementation that
uses `typedef unsigned int size_t;'? What's really
wanted is "equivalenc e of intent," which seems a
harder notion to pin down.

If the suggestion were modified to require "lexical
equivalence," such questions would disappear and I don't
think the language would be any the worse without them.
Writing header files would perhaps not be quite as much
easier as with "semantic equivalence," but I think would
be a good deal easier than it is now.

--
Er*********@sun .com

[Douglas A. Gwyn]

jacob navia wrote:

#define BOOL int
typedef BOOL int; Would it break something if lcc-win32 would accept that,
maybe with a warning?
Please don't try to change the language, it doesn't do your
users any favor. Indeed, it merely encourages even more
out-of-control coding
Is the compiler *required* to reject that?

A diagnostic is required.

[Wojtek Lerch]

"Eric Sosman" <Er*********@su n.com> wrote in message
news:e0******** *@news1brm.Cent ral.Sun.COM...

David R Tribble wrote On 03/24/06 11:01,:

On a related note, I've suggested in the past that duplicate
(redundant) typedefs be allowed as long as they are semantically
equivalent, e.g.:

typedef long mytype; // A
typedef long mytype; // B, error in C99
typedef long int mytype; // C, error in C99

It seems to me "semantical ly equivalent" might
open an unpleasant can of worms. For example, are

typedef unsigned int mytype;
typedef size_t mytype;

"semantical ly equivalent" on an implementation that
uses `typedef unsigned int size_t;'? What's really
wanted is "equivalenc e of intent," which seems a
harder notion to pin down.

Couldn't it simply use the same rules as declarations do -- i.e. require
compatible types?

extern unsigned int myvar;
extern size_t myvar;