Re: port-line bug details & patch question.

[Greg Harvey <Greg.Harvey@thezone.net>]

"Harvey J. Stein" <hjstein@bfr.co.il> writes:

> It seems like port-line works for read-char but not for read-line:
> 
>    guile> (define p (open-input-file "ports.c"))
>    guile> (read-char p)
>    #\/
>    guile> (do ((i 0 (1+ i))) ((> i 300)) (read-char p))
>    guile> (port-line p)
>    5
>    guile> (define p (open-input-file "ports.c"))
>    guile> (read-line p)
>    "/*	Copyright (C) 1995,1996,1997 Free Software Foundation, Inc."
>    guile> (read-line p)
>    " * "
>    guile> (read-line p)
>    " * This program is free software; you can redistribute it and/or modify"
>    guile> (read-line p)
>    " * it under the terms of the GNU General Public License as published by"
>    guile> (port-line p)
>    0
>    guile> 
> 
> Checking the code, I see that SCM_INCLINE is called on the port by
> scm_getc, but not by any of the readline code (which doesn't go
> through scm_getc).
> 
> My questions are:
> 
> 1. Where should it be called for line reading?  The options, as far as
> I can tell are:
> 
>    scm_do_read_line

It can't be (as easily) done there, because fgets & generic_fgets
munch off the newline (you could check for eof). It's probably also
better to have the port specific fgets stuff do the incrementing, so
that for port types where it isn't needed (or sensible) to keep track
of line numbers don't have to worry about it. Plus, fgets and
generic_fgets already check for a newline, so you can just put the
increments there :)

> The latter seems to parallel its usage in scm_getc better.  The former
> is simpler, and keeps the calls to SCM_INCLINE in the one file -
> scm_getc & scm_do_readline are both defined in ioext.c, scm_fgets &
> scm_generic_fgets are in fports.c.

Actually, scm_do_read_line is in genio.c Maybe code reorganization
should be the first thing on the list for post-1.3?

> 2. Would one or the other cover all appropriate entry points?  The
> code is sufficiently byzantine that it's not at all clear to me that
> either one covers all possibilities.

Not completely sure, but I would think that it will cover all file
ports. Other types can (and should, imo) deal with it themselves. If
this is the case, that also should be added to the documentation (in
theory, at any rate ;).

> If someone can answer these questions, great - that person could do a
> better patch than I could.  

Not much to it really... I'd slap one on right now, but I've got a
dentist appointment in like five minutes :(


-- 
Greg, ouch!