> Date: Mon, 4 Sep 2000 11:21:24 -0500 (EST)
> From: Dan Moore <[EMAIL PROTECTED]>
>
> i ask because i spent some time getting it working on BeOS, only to find
> that some of the problems had already been addressed in patches sent to
> this list.
Please tell how can we help. Avoiding waste of resources on problems
that were already solved is a Good Thing ;-).
If you can access the archives of this list, then you should be able
to apply the patches before doing anything else. You could also ask
here about specific problems, before you start debugging them; then if
someone remembers that she already took care of that problem, you'll
hear from her.
> any idea on how long it will be until a patched version of the source will
> be available?
[Running for cover, looking the other way...]
> while i'm at it, i'd like to comment on the patch submitted by Per Mildner
> <[EMAIL PROTECTED]> on March 8, 2000. it looks like that thread was
> never really finished (by looking at the archives).
I'm not sure what thread was that. The fragment you cite is relevant
to MS-Windows, and specifically to the Cygwin port of makeinfo. The
*real* problem with this, it turns out, is that makeinfo asks for
file_size bytes each time through the loop:
> while ((n = read (file, result + count, file_size)) > 0)
> count += n;
Obviously, after at least one byte was already been read, the last
argument to `read' should be reduced accordingly. This works on most
systems, because in reality, you will always read less than file_size
if the code loops more than once. However, on MS-Windows, the
underlying system call makes a point of checking whether the caller
owns the necessary storage for file_size bytes beginning from
result+count. The answer is, of course, NO, whenever you loop more
than once. So Windows fails the call (with the ubiquitous Access
denied error ;-).
This bug was attacked several times by different individuals, all but
one of them suggested wrong explanations for the problem (or no
explanation at all), which made it hard to review the proposed
solutions. Given the above description, the solution is clear, and it
is on my todo list to make that happen some time soon.
I think that the changes you suggested (some of which were discussed
in that particular thread) are NOT the correct solution for the
problem at hand.
Did I miss something?
