jason@hpcvlo.HP.COM (Jason Su) (11/19/87)
/* Here's another irritating bug that compiled(!) w/o errors on MSC 4.0.
* Compiled on MSC 5.0 with "cl /AL /c test.c"
* error returned:
* test.c(10) : error C2059: syntax error : 'typedef name'
*/
typedef int map;
typedef struct {
int *map; /* <-- This is the error line */
} my_struct;
main()
{
}psc@lznv.ATT.COM (Paul S. R. Chisholm) (11/24/87)
<PS/2: yesterday's hardware today; OS/2: yesterday's software tomorrow> In article <1610047@hpcvlo.HP.COM>, jason@hpcvlo.HP.COM (Jason Su) writes: > /* Here's another irritating bug that compiled(!) w/o errors on MSC 4.0. */ > typedef int map; > > typedef struct { > int *map; /* <-- This is the error line */ > } my_struct; K&R, p. 200: "Declarations whose 'storage class' is typedef do not define storage, but instead DEFINE IDENTIFIERS WHICH CAN BE USED LATER AS IF THEY WERE TYPE KEYWORDS . . ." [emphasis mine] The identifier "map" is effectively a reserved keyword from the time its typedef is complete through the end of the compiled module. MSC 4.0 was incorrect in accepting this code in the first place. I suspect that most C compilers that support typedef will reject it. -Paul S. R. Chisholm, {ihnp4,cbosgd,allegra,rutgers}!mtune!lznv!psc AT&T Mail !psrchisholm, Internet psc@lznv.att.com I'm not speaking for my employer, I'm just speaking my mind.
ballou@brahms.Berkeley.EDU.UUCP (11/25/87)
In article <1203@lznv.ATT.COM> psc@lznv.ATT.COM (Paul S. R. Chisholm) writes: >In article <1610047@hpcvlo.HP.COM>, jason@hpcvlo.HP.COM (Jason Su) writes: >> /* Here's another irritating bug that compiled(!) w/o errors on MSC 4.0. */ >> typedef int map; >> >> typedef struct { >> int *map; /* <-- This is the error line */ >> } my_struct; > >K&R, p. 200: "Declarations whose 'storage class' is typedef do not >define storage, but instead DEFINE IDENTIFIERS WHICH CAN BE USED LATER >AS IF THEY WERE TYPE KEYWORDS . . ." [emphasis mine] > >The identifier "map" is effectively a reserved keyword from the time >its typedef is complete through the end of the compiled module. MSC >4.0 was incorrect in accepting this code in the first place. I suspect >that most C compilers that support typedef will reject it. Er, well, you are correct in the strict sense of K&R. However, it is my impression that Microsoft is moving their C compiler towards compliance with the draft ANSI standard. Now, unless I am misreading the standard, the members of a struct reside in a name space unique to that struct; moreover, this name space is disjoint from that in which typedef identifiers reside. Hence, if the goal is to follow the ANSI standard, it would seem MSC 5.0 is in error. Kenneth R. Ballou ARPA: ballou@brahms.berkeley.edu Department of Mathematics UUCP: ...!ucbvax!brahms!ballou University of California Berkeley, California 94720
platt@emory.uucp (Dan Platt) (11/28/87)
In article <1203@lznv.ATT.COM> psc@lznv.ATT.COM (Paul S. R. Chisholm) writes: ><PS/2: yesterday's hardware today; OS/2: yesterday's software tomorrow> > >In article <1610047@hpcvlo.HP.COM>, jason@hpcvlo.HP.COM (Jason Su) writes: >> /* Here's another irritating bug that compiled(!) w/o errors on MSC 4.0. */ >> typedef int map; >> >> typedef struct { >> int *map; /* <-- This is the error line */ >> } my_struct; > >K&R, p. 200: "Declarations whose 'storage class' is typedef do not >define storage, but instead DEFINE IDENTIFIERS WHICH CAN BE USED LATER >AS IF THEY WERE TYPE KEYWORDS . . ." [emphasis mine] > >The identifier "map" is effectively a reserved keyword from the time >its typedef is complete through the end of the compiled module. MSC >4.0 was incorrect in accepting this code in the first place. I suspect >that most C compilers that support typedef will reject it. Actually, in this case, if the error is in the line indicated by the comment, then there is a problem with the compiler. The reserved word is 'my_struct', not 'map'. As an example, I've constructed the following toy program: #include <stdio.h> typedef struct { int *map;} my_stor; my_stor map; main() { printf("I guess there was no complaint.\n"); map.map = (int *)malloc(sizeof(int)); *(map.map)=5; printf("%d\n",*(map.map)); } This program runs quite well on a Sun, a Vax and on my PC (using turboC) with no problems. Plus, as pointed out K&R were quite explicit in defining the variable as a type (in this case, the variable being declared was my_struct as a structure containing a pointer to an integer called map). Hope this clears things up... Dan Platt
psc@lznv.ATT.COM (Paul S. R. Chisholm) (12/02/87)
<PS/2: yesterday's hardware today; OS/2: yesterday's software tomorrow> In article <2355@emory.uucp>, platt@emory.uucp (Dan Platt) writes: > In article <1203@lznv.ATT.COM> psc@lznv.ATT.COM (Paul S. R. Chisholm) writes: > >In article <1610047@hpcvlo.HP.COM>, jason@hpcvlo.HP.COM (Jason Su) writes: > >> /* Here's another irritating bug that compiled(!) w/o errors on MSC 4.0. */ > >> typedef int map; > >> > >> typedef struct { > >> int *map; /* <-- This is the error line */ > >> } my_struct; Jason complained that the program no longer compiled under MSC 5.0. And I said (after a reference to K&R p. 200): > >The identifier "map" is effectively a reserved keyword from the time > >its typedef is complete through the end of the compiled module. MSC > >4.0 was incorrect in accepting this code in the first place. I suspect > >that most C compilers that support typedef will reject it. Well, it sounded good at the time. But both Turbo C and the VAX UNIX System V Release 2 compiler accepted it. (Hey, what do I know? I haven't looked at the compiler's source code since System III!-) I wouldn't be surprised if ANSI specifically states that the above code is legal. If so (and people have said so in other messages), MS blew it. And Dan responded: > Actually, in this case, if the error is in the line indicated by the > comment, then there is a problem with the compiler. The reserved word > is 'my_struct', not 'map'. Um, no. In some compilers, the typedef on line one would make "map" (effectively) a reserved identifier. Then the field declaration on line four fails, because "map" is no longer recognized as a possible user identifier; it's like saying "int *float;". (I would expect Dan's program to compile successfully even under limited compilers that broke on the example above.) -Paul S. R. Chisholm, {ihnp4,cbosgd,allegra,rutgers}!mtune!lznv!psc AT&T Mail !psrchisholm, Internet psc@lznv.att.com I'm not speaking for my employer, I'm just speaking my mind.