Re: port-line bug details & patch question.

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

Jim Blandy <jimb@red-bean.com> writes:

> > > 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 :)
> 
> It seems to me that line counting is potentially useful across all
> port types; is that misgiven?  I wouldn't put it in the port-type-
> specific routines.
> 
> If that's so, then, since the port's .fgets ptob function promises to
> consume only one line, it's okay to increment the counter in
> scm_do_read_line.

The only real problem I can see with that is if someone goes around
scm_do_read_line and uses the fgets method directly (probably not a
good idea, and won't be something you want to encourage in any
case). Also, it could possibly get less than one line (for example, a
text file that doesn't end with a newline, or a growing file), so that
the count given by doing read-line won't give the same results as
doing read-char (which is hard coded for newlines). Actually, this
could be fixed by making the port structure know about what is
considered a line incrementor, and then checking the last character of
the string in scm_do_read_line (and probably in read-char, as well). 

Of course, this is assuming that anyone is ever going to use a port,
with scm_do_read_line, that doesn't use a newline as a line
incrementor, but wants to take the port-line of that port. I'd think
that probability aproaches 0, since 'lines' probably won't make much
sense there, anyway.

In any case, I don't think it matters much where it goes, as long as
the results of reading the file are consistant with each other.

> > > 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?
> 
> I remember wandering through the I/O port stuff in 1996, and getting
> totally lost.  There are two problems I see these days:
>
> 1) Each port type's ptob functions aren't really named in a way that
> makes it clear what they are.  People see the name scm_fgetc, and assume
> that it's a general-purpose function for reading a single character.
> It's not.  (I renamed that, and scm_fgets...)
> 
> 2) The port implementations aren't really localized.  There's a bunch
> of stuff in ioext.c that knows all about the internals of fports, for
> example.
> 

Maybe some of it should be merged with fports.c? I'd think that this
was probably to segregate base rnrs style stuff from extensions, but
it's probably better to bundle it into one place, and let runtime
modules determine what is included. Of course, a good determination of
this should probably take more than the two seconds of thought I've
given this while trying to watch a hockey game :)

-- 
Greg