error: partial base64 value left over

[Peter Rathlev]

On Tue, 2011-01-25 at 17:58 -0800, David Hankins wrote:
> On Tue, Jan 25, 2011 at 3:45 PM, Peter Rathlev <peter at rathlev.dk> 
> > And cfile->cur_line is alread \0-terminated; get_char (conflex.c:109
> > in 3.1-ESV) continually moves the termination of cur_line, but not
> > after cfile->lpos (position in line) moves beyond 80. Thus only the
> > first 80 characters are returned.
> That sounds like a problem.

The problems seems to lie in the fact that the cfile->line1 and
cfile->line2 used in a "buffer swap" style to store current and previous
lines are only char[81]. Enlarging these arrays and adjusting the
counter could move the problem beyond "normal" line lengths.

I'm cutting my teeth on GDB these days and hope to find the difference
between the (to laymen) two similar base64 strings.

> > Including "&& c != '+' " in the test on line 509 seems to fix the
> > problem, but I'm not sure that's the "right" solution. And the
> > quoted string works since "read_string" doesn't use "isalnum" or
> > similar, only terminating at the ending double quote.
> No, you just broke the addition operator for name + name. :)

Heh, yeah I see that. As far as I can tell that means that the lexer
could not easily be made to tell the difference between "name + name"
and an unquoted but otherwise valid base64 string.

Maybe it would be a good idea to update the man-page of dhcpd.conf to
include quoting in the examples (e.g. server/dhcpd.conf.5:1309 in
4.2.0-P2) and point out the problems with unquoted strings.

Where would one suggest such a thing? I'm thinking dhcp-users might not
be the right place.

-- 
Peter