[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::digital_unix

Title:DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:Welcome to the Digital UNIX Conference
Moderator:SMURF::DENHAM
Created:Thu Mar 16 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:10068
Total number of notes:35879

8645.0. "lex problem" by DEKVC::YONGJOONCHOI () Thu Jan 30 1997 06:07

    
    
      Hi
      Our customer have some problems  when compile.
      This program work out well under solias,ultrix but not DU4.0 
      When compiles  following message displayed.
    
      >make
    
        yacc  -d dilp.y
        cc -O -I../hfiles -c y.tab.c
        rm -f y.tab.c
        mv  y.tab.o dilp.o
        lex  token.l
        lex: (Warning at line 169)Non-terminated string
        lex: (Warning) bad state  308 175   
        cc -O -I../hfiles -c lex.yy.c
        cc: Warning: lex.yy.c, line 271: In this statement, the referenced  
        type of the pointer value "&yytext[2]" is "unsigned char",which is
        not compatible with "signed char".
                              for(num = 0, ptr = &yytext[2];*ptr != '\'';ptr++) /*imsi*/
       -------------------------------------^
       cc: Warning: lex.yy.c, line 278: In this statement,the referenced
       type of the pointer value "&yytext[2]" is "unsigned char",which is
       not  compatible with "signed char".
    
                              for(num = 0, ptr = &yytext[2];*ptr != '\'';ptr++)
       -------------------------------------^
       rm -f lex.yy.c
       mv  lex.yy.o token.o
       cc -c -O -I../hfiles -DVer=\"REL1.1\" -DDate=\"1996/09/03\" main.c
       cc -O -I../hfiles -c symbol.c
       cc -O -I../hfiles -c parse.c
       cc -O -I../hfiles -c run.c
       cc -c -g ../hfiles/head.c
       cc dilp.o token.o main.o symbol.o parse.o run.o head.o -o dilp
       cp dilp ../../bin
    
       <Makefile>
    
       
    #YFLAGS = -d -v
    YFLAGS = -d
    CFLAGS = -O -I$(HFDIR)
    INS = :
    BIN =
    LIST = lpr -Pqp3
    HFILES = $(HFDIR)/hdfile.h symbol.h
    SRC = dilp.y token.l main.c symbol.c parse.c run.c $(HFDIR)/head.c
    OBJS =  dilp.o token.o main.o symbol.o parse.o run.o head.o
    
    EXOUT = dilp
    
    $(EXOUT):$(OBJS)
            $(CC) $(OBJS) -o dilp
            $(INS) $(EXOUT) $(BIN)
    
    $(OBJS) : $(HFILES)
    
    main.o : main.c $(HFILES)
            $(CC) -c ${CFLAGS} -DVer=\"$(Ver)\" -DDate=\"$(Date)\" main.c
    
    head.o  : $(HFDIR)/head.c
            $(CC) -c -g $(HFDIR)/head.c
    
    
    Sinece the program have prolbem is too long, I post 169 line.
    
    <Str>"\\\""             { cbuf[clen++]='"'; }
    <Str,Chc>"\\"n          { cbuf[clen++]='\n'; } <----- 169 line
    <Str,Chc>"\\"t          { cbuf[clen++]='\t'; }
    <Str,Chc>"\\"b          { cbuf[clen++]='\b'; }
    <Str,Chc>"\\"r          { cbuf[clen++]='\r'; }
    <Str,Chc>"\\"f          { cbuf[clen++]='\f'; }
    <Str,Chc>"\\\\"         { cbuf[clen++]='\\'; }
    <Str>.                  { CADD; }
    
    
    
    any information?
    
    
    thanks
    
    
    
    
    
    
    
    
    
    
    
    
T.RTitleUserPersonal
Name
DateLines
8645.1This is a bug in LEX - CLD needed.SMURF::GAFJerry Feldman, Unix Dev. Environment, DTN:381-2970Thu Jan 30 1997 12:5711
    The issue here is on line 168. 
        <Str>"\\\""             { cbuf[clen++]='"'; }
        <Str,Chc>"\\"n          { cbuf[clen++]='\n'; } <----- 169 line
        <Str,Chc>"\\"t          { cbuf[clen++]='\t'; }
    
         The Digital Unix version of Lex is the AT&T lex which has been
    updated to comply with the POSIX specification. What is happening here
    is that lex wants the '"' wo be escaped as:'\"'. 
    
    In my opinion this is a bug in LEX, and a QAR and/or CLD should be
    issued. A CLD is probably more appropriate in this case. 
8645.2Try flex.SMURF::GAFJerry Feldman, Unix Dev. Environment, DTN:381-2970Thu Jan 30 1997 13:003
    As a workaround, we also support flex. I am not sure if flex would be
    aprpopriate with your grammar or not, but it could provide a quick
    workaround for your customer. 
8645.3MY first analysis was a bit off.SMURF::GAFJerry Feldman, Unix Dev. Environment, DTN:381-2970Thu Jan 30 1997 14:406
    A bit more to add. This is still a bug in LEX, but the bug is 
    on line 169 where the POSIX Extended Regular Expresssion modification
    caused a regression. MY first glance at this, the '"' threw me off,
    because the routine that parses actions has the same message as the one
    which parses regular expressions. Still need to QAR or CLD this to get
    a fix.
8645.4How to do DEKVC::YONGJOONCHOIThu Jan 30 1997 20:3719
    
    
    Thanks for your answer
    
    The program have problem running under DU3.2C as well.
    I think this problem JUST against DU4.0*.
    If that problem is BUG, is there any relevant patch or any solution?
    As following your reply, To fix that problem  need QAR or CLD
    What is the QAR,CLD?
    Give me a best way to fix that problem.
    
    Our reseller competite  against SUN. That problem work out under SUN.
    If we don,t solve that problem until next tuesday(2.4), Maybe Customer
    want to SUN. 
    
    thanks
    
     
    
8645.5You need to file the appropriate requestSMURF::GAFJerry Feldman, Unix Dev. Environment, DTN:381-2970Fri Jan 31 1997 10:344
    The problem was caused a change to LEX in V4.0. The change was that the
    UNIX 95 standard requires LEX to support Extended Regular Expressions.
    I have already implemented a fix for this. A CLD or an SPR is required
    before I am allowed to place the fix into the support pools.