This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Minor DJGPP fixes
- To: Zack Weinberg <zack at wolery dot cumb dot org>
- Subject: Re: Minor DJGPP fixes
- From: Eli Zaretskii <eliz at delorie dot com>
- Date: Mon, 1 May 2000 04:37:09 -0400 (EDT)
- CC: Laurynas Biveinis <lauras at softhome dot net>, gcc-patches at gcc dot gnu dot org, djgpp-workers at delorie dot com
- References: <390C769C.812EAB7D@softhome.net><20000501000928.J11780@wolery.cumb.org>
- Reply-to: Eli Zaretskii <eliz at is dot elta dot co dot il>
> - fcntl() working is a characteristic of the _host_, not the target.
> - You should determine if it works using an autoconf test.
Why didn't the original code use an Autoconf test, then? I understand
that it was added only recently.
> - If it doesn't work, you need to open the file in blocking mode, not
> just elide the fcntl(); otherwise the code reading the file will
> break.
Could you please explain what does ``open in blocking mode'' mean?
Isn't a normal default `open' good enough? If not, why not?
> This fcntl() is there to avoid a problem that never happens in real
> life: someone does #include </dev/rmt0> and the preprocessor gets
> wedged because there's no tape.
Shouldn't people who do this get what they were asking for? I mean,
if someone *really* wanted the preprocessor to read the tape,
shouldn't the preprocessor get stuck if there's no tape?
> Therefore, I'd be willing to dump the fcntl() call entirely and open
> the file in blocking mode on all hosts. Does anyone else have an
> opinion?
I need to understand what a ``blocking mode'' is to form a useful
opinion. I assume that the same code will be used to read normal
files as well.