Mail Archives: djgpp-workers/2001/08/20/10:27:51
> From: "Andrew Cottrell" <acottrel AT ihug DOT com DOT au>
> Date: Mon, 20 Aug 2001 23:58:40 +1000
>
> > If _is_executable is the suspect, it can be disabled by setting the
> > _STAT_EXEC_MAGIC bit in _djstat_flags.
> In my testing I found that I can "fix" the problem by one of the following
> methods:
> a) Commenting out the _is_executable() call in fstat.c
> b) Setting the _STAT_EXEC_MAGIC bit in _djstat_flags
> b) adding a _read() to the _is_executable() function before or after
> the second 4200 call.
> c) Debug the new sample under Rhide
I don't understand the (c) above (it's probably due to the fact that
RHIDE and GDB use FSEXT to watch handle usage by the debuggee), but
otherwise it sounds like _is_executable is the prime suspect. But I
cannot figure out why: all it does is move the file pointer (which is
actually a no-op, since stdin was not read yet), reads two bytes, and
then moves the file pointer again. One idea would be to selectively
disable parts of _is_executable and see which one(s) cause the
problem.
> I tried to find where STDIN is setup, but I couldn't see it. I do not think
> I am looking for the right thing. I searched for STDIN and couldn't see
> anything useful, I loked in crt1.c. Could someone please point me in the
> direction of where STDIN is setup/configured?
What ``setup'' exactly are you looking for?
stdin is a buffered stream, and its set up in
src/libc/ansi/stdio/stdin.c. But I don't think this is relevant to
the issue at hand, since we now know the problem is with lseek, not
with fseek. And lseek works on the file handle, not on the FILE
object. File handle zero is the one which corresponds to standard
input, and the shell connects that handle to the file when you
redirect it.
Does that answer your question?
- Raw text -