Date: Thu, 24 Mar 94 08:43:02 -0500
From: dj AT ctron DOT com (DJ Delorie)
To: eliz AT is DOT elta DOT co DOT il
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: Line terms; UNIX v. DOS; opinions wanted (was: Info port...) 


> > Actually, the problem is when you have split info files.  The first
> > file has *absolute* offsets into the other files, and the *absolute*
> > offsets change if you *convert* the file between unix and dos.
> >
> > If you *generate* the split file in dos, and if info is smart enough
> > ...
> 
>   That's the whole point: when you read() files in ``text'' mode, you don't
> have to be ``smart'': things automagically get settled for you.  The only

You missed the point.  Here's an example of when it breaks:

* run makeinfo on *unix*.  It uses read() to get offsets, *stores* the
unix-valid offsets in the .info file, splits the rest.  Most gnu info
are done this way.

* copy the .info* files to ms-dos.

* change one of the .info* split files with an editor that saves in
DOS format instead of unix format (or just run utod on them).

* run info on dos.  It uses the offsets generated on unix, seeks into
the split file, finds the wrong data because the file has been
changed.

The basic problem is that makeinfo stores absolute offsets and info
assumes they're still valid when it reads them.  This is *not* true if
the file has been changed since makeinfo (like cr/lf translation).