Re: port-line bug details & patch question.

[Jim Blandy <jimb@red-bean.com>]

> > 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 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.