Subject: Re: Portability

From: Zheng Gengbing <[email-masked]>
Date: Fri, 24 May 1996 11:21:40 +0800 (EAT)

On Thu, 23 May 1996, Guansong Zhang wrote:

> HIT, please also pay attention to this letter.
> 
> On May 23,  4:19pm, Zheng Gengbing wrote:
> > Subject: Re: Portability
> > On Wed, 22 May 1996, Guansong Zhang wrote:
> >
> > > >
> > > > 	can you tell me which line did you commented out ?
> > >
> > > Well, I said the line about definition of yytext.
> > >
> > > /* extern  char yytext[YYLMAX];   yytext[0x400] (sun20) ; *yytext  (Linux)
> */
> > >
> > > the old one looks like:
> > >
> > > extern  char yytext[YYLMAX];  /* yytext[0x400] (sun20) ; *yytext  (Linux)
> */
> > >
> > > in 1.53.
> > >
> >
> >
> > 	yytext always causes troubles . Sometimes it is decalred as
> > unsigned char yytext[] , while sometimes char yytext[] , to make thing worse,
> > sometime flex also define  char *yytext (pointer instead of array ).
> >
> > 	To eliminate the first difference , I used
> > #undef YYCHAR_ARRAY
> > 	to force the compiler to adopt the definition of char yytext[] .
> >
> 
> 
> I don't understand this. Could you please explain a little more?
>

	YYCHAR_ARRAY proved to be unsuccessful , I have comment the line
in hpflexer.l instead to remove the warning of redeclaration of yytext as
you did .

> In addition, where did you use the directive in 1.55? I can not find it.
>

	I have removed that .

> > 	To the second case , I used   %array yytext
> > to tell the lex to define the yytext as array instead of pointer .
> >
> > 	So please test if the lexer and parser can be smoothly compiled
> > in the coming version . My test on HP and Linux is successful .
> >
> 
> 
> The problem is that only POSIX standard lex support this. I am not sure to
> those who don't support this feature what will happen.
>

	Well, our lexer cannot support  yytext as pointer . I have tested 
that . In HP9000 , the default defintion is pointer , the testing is 
terrible , no sample can be passed . The reason is that when use yytext as
pointer , every input , unput will damage the content of yytext .
I have no idea if we have no POSIX standard lex , maybe we must use machine
dependent configure then to deal the problem machine by machine .And  
Does they have other means to force the definition of yytext as array ?

> > > I found autoconf package has some special places about whether the
> definition
> > > is pointer or an array for yytext. But I don't how to use it. Zheng
> Gengbin, do
> > > you have any idea, please?
> > >
> >
> > 	I once used the YYTEXT_POINTER to determine the definition . But ,
> > I found that is not successful . As mentioned in the man page of flex ,
> > use yytext as pointer will cause some portablity problem though using pointer
> > can make  the parser fast .  So to force the lex to define the yytext as
> > array is better , I think. If we use %array yytext , we can force the lex
> > to define yytext as array , then we need not use YYTTEX_POINTER .
> >
> 
> I agree with you, but I don't quite understand the situation now.
> 
> If we comment that line in .l file out, if it is still a problem. I found the
> following lines in hpflexer.c and hpfparser.c respectively on 1.55.
> 
> hpflexer.c:unsigned char   yytext[YYLMAX];
> 
> hpfparser.c:char yytext[0x400]; /* *yytext (Linux);  yytext[0x400] (Sun20)  */
> 
> >From what I understand you said, the first one is generated by the lex(or flex)
> by forcing %array. But the second one have to be declared in .y file, so it can
> be referenced some place else in .y, right?
> 

	This is the real problem now .

> I don't see any relations between them in the above, is the second one should
> be declared as extern? Please check this.
> 
> Then how we can know whether we should declare yytext as char or unsigned char?
> %array will force an unsigned char?
> 

	I don't know either . I will examine other gnu softwares to see how
they deal the problem.

> 
> Guansong
> 
> P.S. I found that in 1.55 Makefile.in's cc was not changed to @CC@, HIT please
> let me know if you can access gcc and gdb.
> 
> Another question about autoconf, if we change to @CC@ now, when configure can
> not find gcc, it will use cc, right?
> 

	certainly.

***************************************************************************
*     Zheng Gengbin                 *                                     *
*                                   *                                     *
*  Dept. of Computer Science        *  Phone:  86-10-2585088              *
*         & Technology              *  Email:                             *
*                                   *      [email-masked]   *
*  Peking University P.R.China      *  Mail:                              *
*                                   *      Room 1077 ,Building 47,        *
*                                   *      Peking University, P.R.China   *
***************************************************************************

---

From: Zheng Gengbing <[email-masked]>
Date: Fri, 24 May 1996 14:43:40 +0800 (EAT)

I think to solve the problem brought by  yytext , the best way is 
not to provide hpflexer.l at all , just put hpflexer.c instead . This is 
the way some softwares take .

---

From: Zheng Gengbing <[email-masked]>
Date: Fri, 24 May 1996 17:01:51 +0800 (EAT)

here I find 2 bugs :

	1. about  hpf2dep :

	try
++
implicit none 
integer a

	hpf2dep can pass , while 
++
implicit none !zgs
integer a

	can not be passed .

	The reason is that after reduced comment ,  <uu> is kept so
the 'a' in next line return IMPLICITLETTER , which is wrong .

	2.  about unparser ,

	Zhang GuangSong , you seem forget to define a def for POINTER_STMT
so try this example:

	program try
	pointer a
	end

will get
	program try
	end

pointer statement lost .