Message-Id: <m114Nly-0006ALC@sloep100.cs.vu.nl>
Date:     Wed, 14 Jul 99 14:04:26 MET DST
From: Michel de Ruiter  <mdruiter AT cs DOT vu DOT nl>
To: djgpp-workers AT delorie DOT com, Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Subject:  Re:  DJGPP cvs and gcc-2.95
               DJGPP cvs and gcc-2.95
Reply-To: djgpp-workers AT delorie DOT com

Andris wrote:
> I don't think gcc should crash on such not very complicated sources.
> Are You sure that was not due to Wincrash95 DPMI server bugs
> (descriptor leaks)?

I only ran MS-DOS 7.01 (Win98 without GUI), so that's not it... I
think it is my machine as I wasn't able to reproduce the strange
behaviour on an other machine. Never mind for now.

Eli wrote:
> The discussion in the docs draws upon experience from several
> programs that really do what is described there. One example that
> comes to mind is the ported Less; gzip and cat are two others. I
> wrote all that docs in the hope that my experience will be useful to
> someone, some day...

I understand, but somehow it wasn't :-)

> >   And, as the input is line buffered, __djgpp_set_ctrl_c will not
> >   really help to generate signals, will it? Or do I still miss
> >   something, about console in binary mode?
> When you switch the console to binary mode, the library puts the
> console device into raw mode, whereby input is not line-buffered
> anymore, at least not by DOS. So you *can* say e.g. "read (0, &c,1)"
> and read a single character into c.

Hmmm, in that case I understand all the documentation you wrote! But
then why did I get the impression input stays line-buffered? I now
looked in the mail-archives, where I see you have written:

> If the program actually *needs* to read binary data from the
> terminal, it should read it one character at a time, like so:
> 	  read (0, &c, 1);
> (or use `getch'). Using buffered stdio functions, like `getchar',
> won't return until the full 512-byte long request is satisfied, and
> until then you are parked inside a DOS call...

Now I see my problem was in using `getchar' or `getc' instead of
`getch' or `read'. I didn't realize/know the former were buffered
where the latter are not. So the use of *buffered* input functions is
useless with a tty in binary mode... Ahhhh, now it's clear! Sorry to
have bothered all of you about this (again).

You (Eli) also wrote:
> > All problems disappeared when I set stdin to _IONBF (not buffered)
> I'm worried about the possible implications of turning off the
> buffering just because somebody reads in binary mode. Can anybody
> think of any downside to this change? If not, let's do it.

I now understand this is not worth the hassle? Or should it only wait
for 2.04?

> > scheck.c: In function `scheck':
> > scheck.c:56: warning: cast discards qualifiers from pointer target type
> What's scheck.c?  I don't think I ever saw that file.

The file `zoneinfo/src/scheck.c', it was used in the regular building
process, because:

# You don't have to build the stuff in ../zoneinfo/src, but if you do
# unzip djtzsNNN.zip, you will need a Unixy shell to build it.
# If you don't have ../zoneinfo/src, Make will report (and ignore) an
# error when it tries to build files there; disregard it.
...
all : misc.exe $(DIRS) makemake.exe subs ../lib/libg.a ../lib/libpc.a
... 
subs:
...
        -$(MAKE) -C ../zoneinfo/src

Groente, Michel.