Xref: utzoo comp.sources.d:3938 comp.os.vms:16522
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!asuvax!noao!arizona!naucse!jdc
From: jdc@naucse.UUCP (John Campbell)
Newsgroups: comp.sources.d,comp.os.vms
Subject: Flex (latest 2.1 beta) on VMS
Keywords: read() in VMS library
Message-ID: <1629@naucse.UUCP>
Date: 3 Aug 89 22:29:28 GMT
Organization: Northern Arizona University, Flagstaff, AZ
Lines: 40

The latest flex was posted a month or so ago by Vern Paxson.  (Flex is
a faster lex that will be replacing most older lexes on many unix systems.)
I'm working on bringing it up on VMS and I've run into the following
situation...

The "older" flex read a line at a time (YY_MAX_LINE) and YY_INPUT worked
pretty much without a hitch.  The new flex reads a large chunck at a
time.  With VMS STREAM-LF files this works just fine--but with "normal"
VFC editor text files (darn these RMS things) the VMS 'C' rtl will only
return at most 1 record full of characters for any large read() byte
request.

During processing on a flex input file, flex complains of a "NULL in
input."  This seems to be because yyunput() wants to "shift things up
to make room" and assumes that the end of the valid buffer is around
YY_BUF_SIZE deep.  On VMS, with it's non-standard read() behavior, the
end of the valid data is frequently not near YY_BUF_SIZE.  (On non-record
oriented file systems read() will, of course, only do this on the last
buffer.)  

So my problem is not that I can't understand what is causing the "NULL
in input" message, but a request for what the best solution might be.
I could, of course, create a special VMS YY_INPUT macro that fills
the buffer like a unix read() would using getc, or I could try to
patch yyunput() and hope that the read() behavior assumption is isolated
to this spot in flex's code.  

If you have an opinion on which way to go I'd like to hear it.  If you
have already solved the problem I'd like to know what you did.  If you
can think of a reason why this read() assumption is a bad idea for unix
(streams and producer/consumers that might not always behave like flex
is assuming) I'd like to know about that also.

If I've been unclear and you want to know what the he-- I'm talking about
just mail me a message indicating where I was unclear.  I'm going to try
hard to shelve this project for a day or so...
-- 
	John Campbell               ...!arizona!naucse!jdc
                                    CAMPBELL@NAUVAX.bitnet
	unix?  Sure send me a dozen, all different colors.