Re: input.c and here documents bugfixes

["Bart Schaefer" <schaefer@xxxxxxxxxx>]

[ You sent your message only to me, Zoltan ... it didn't go to the list. ]

On Sep 22,  6:09pm, Zoltan Hidvegi wrote:
} Subject: Re: input.c and here documents bugfixes
}
} > I think Zoltan's input.c patch was incorrect
} > 
} -- patch deleted ---
} 
} Sorry, I forgot the semicolon at the end. The patch below should be correct.
} 
} The problem with the original file is that is can exit from the for loop on
} two conditions.  If it exits when the buffer is filled up, the l counter is
} one more than otherwise.

But that's the right thing to do, unless ingetc() has changed a lot from
hgetch().  Originally, hgetch() would return a space that wasn't really
in the input stream whenever lexstop was true; and hgets() [which became
ingets() recently] would have to trim that space off to return the real
input.  If the buffer is filled up, then the last character returned by
ingetc() is a real part of the stream, and the counter should be one
greater so that the '\0' string-terminator will be inserted after the
last character read.

Your loop is completely equivalent as far as I can tell, except that if
n <= 1 and lexstop happens to already be true before ingets() is called,
you'll write a '\0' into buf[-1].

I still think the original version is correct.  Can you give an example
where it fails and your version does something different?

-- 
Bart Schaefer                                      Vice President, Technology
schaefer@xxxxxxxxxx                                Z-Code / NCD Software Inc.

What quantity of engineers is required to rotationally reconfigure an
electronically-actuated filament-enabled photon-wave generator?