kon@asterix.Stanford.EDU (Ronnie Kon) (02/23/90)
The namespace for typedefs is (IMHO) wrong. Currently (according to
the ANSI spec), typedefs are stored in the ordinary identifier namespace,
separate from the label, tags, and struct/union member namespaces. This has
the effect of making the following code fragment legal:
typedef int typename;
struct {
typename typename; /* note: same name */
} x;
(as the occurance of typename as a struct member is in a separate namespace
from the space the typedef is stored in), but
typedef int typename;
typename typename;
is illegal (as the occurance of typename is now in ordinary identifier
namespace, and conflicts with the typedef).
It seems to me to be highly counterintuitive that a declaration that
is legal within a structure becomes illegal when removed from it. (Yes, I
realize that is the case with bit fields, but they are a special case).
What I think should happen is that either typedefs get their own
namespace (my preferred solution), or typedefs should automatically appear
within all struct/union member namespaces.
My questions then, are
1) Do people agree that this is the explanation for the fact
that my compilers (I have tried this on a number of different
machines) accept the first fragment but reject the second?
2) Do other people believe that this should be changed?
--
-------------------------------------------------------------------------------
Ronnie Kon | "I don't know about your brain,
ronnie@mindcraft.com | but mine is really bossy"
...!{decwrl,hpda}!mindcrf!ronnie | -- Laurie Anderson
-------------------------------------------------------------------------------henry@utzoo.uucp (Henry Spencer) (02/24/90)
In article <38@asterix.stanford.edu> kon@asterix.Stanford.EDU (Ronnie Kon) writes: > The namespace for typedefs is (IMHO) wrong... > What I think should happen is that either typedefs get their own >namespace (my preferred solution), or typedefs should automatically appear >within all struct/union member namespaces. ... > ...Do other people believe that this should be changed? Why bother? -- "The N in NFS stands for Not, | Henry Spencer at U of Toronto Zoology or Need, or perhaps Nightmare"| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (02/25/90)
In article <38@asterix.stanford.edu> kon@asterix.Stanford.EDU (Ronnie Kon) writes: | My questions then, are | 1) Do people agree that this is the explanation for the fact | that my compilers (I have tried this on a number of different | machines) accept the first fragment but reject the second? Without a copy of the standard home I can't be sure if you're right. It certainly looks as if the behavior violates the "law of least astonishment" rule, if nothing else. | | 2) Do other people believe that this should be changed? I think think it's urgent. When the next standard committee is meeting, I would agree that this would be a good place for enhancement. Having a typedefname behave like a type in all cases would probably be the best way to have it work. I suppose that it will break some "tricky" program or other. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc "Getting old is bad, but it beats the hell out of the alternative" -anon