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


You wrote:
> 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
gotcha is: never ever take the file size from stat().  That's the only *real*
change you need when porting to dos: take the file size from whatever read()
returns. (I would recommend this as a universally good practice for writing
programs that can be ported to other OS's; too bad that so much of
unix-oriented people don't care about ``strange'' (read: ``foolish'') OS's
like DOS etc.  Sigh...)  If you do this, the offsets will always be OK.  It
works for me both for unix-generated split files (e.g. Texinfo docs which came
with DJGPP) and files split under dos (I tested this by running makeinfo on
Bison docs without the --no-split option).
  Btw, it's Makeinfo which has to be ``smart'' when splitting files, not Info.
To my great surprise I found that whoever ported it to VMS and DOS already
did the necessary #ifdef and took file sizes from the return value of read().
No need to change a bit here, either.

		Eli Zaretskii