Mail Archives: djgpp-workers/2001/08/22/10:43:46
> From: "Andrew Cottrell" <acottrel AT ihug DOT com DOT au>
> Date: Wed, 22 Aug 2001 22:03:29 +1000
>
> seek.c 172 4200, flags = 0x02 pos = 0x0000:0000 Char at offset [0] = (3)
> seek.c 172 4200, flags = 0x02 pos = 0x0000:0000 Char at offset [0] = (4)
It looks like 4200 reports that it did move the file pointer, but the
subsequent 3F00 still continues from the position before the lseek.
> After I wrote the sentence above I thought that the possibel solution is to
> add a seek to position 1 after the 3700 call and then to seek to zero. I
> just tested this an it works. To include the change I found works change the
> AC_PATCH_TEST_1 define to 1, to go back to the old code change the define
> to 0.
>
> There are other changs in the code that I am working on, for example move
> the processing of the retval to just after the 3700 call so that the
> additional code will not overwrite the buffer.
>
> What do you think about this sort of solution for is_executable()?
Right now, I'm more worried by lseek not working than by
_is_executable. I think we need first to find a good general-purpose
solution for lseek, so that we could be sure the file pointer moves to
the right place. If that doesn't fix _is_executable, we can find some
local trick later.
> Thanks for this as it explains how come I could not see this anywhere as it
> is up to the shell used. I wonder if bash or 4DOS shell has work? I will
> also try this if I have time tomorrow night.
Thanks, trying this with different shells might indeed shed some light
on this problem.
- Raw text -