Mail Archives: djgpp-workers/2001/08/23/04:12:28
> > 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.
4DOS - also fails.
Bash 2.05 beta - Works, same as Charles found.
I have read all of the email going arround and I would like to find out what
I can do to help out with this issue as some of the info in the emails went
over my head.
- Raw text -