Mail Archives: djgpp-workers/2002/04/05/04:49:28
Hello.
Eli Zaretskii wrote:
>
> > Date: Wed, 03 Apr 2002 18:22:36 +0100
> > From: "Richard Dawe" <rich AT phekda DOT freeserve DOT co DOT uk>
> >
> > Below is a diff to fix the realloc bug in grow_table in the FSEXT code.
> > If realloc fails, then the current code will trash the __FSEXT_entry
> > table. This can lead to bogus behaviour when the program exits
> > and the __FSEXT_close_all function is called. On one occassion
> > it wedged my box.
>
> I'm not sure I understand the problem, because the solution doesn't
> seem to solve what I have in mind. If realloc fails, doesn't that
> mean the old buffer could be invalid as well? And yet AFAIU your
> change simply lets the program use the old array. What am I missing?
The problem is that grow_table does not currently cope with realloc() failing.
If realloc() fails, then the list we were trying to resize is still valid,
because realloc() does not trash the old buffer (source: draft N843 of the C99
standard). But the current FSEXT code throws away the pointer to the list.
This is bad, because we can still use the list to handle already allocated
FDs. If the list is lost, then any FSEXT hooks set up will not be used.
The patch uses a temporary variable to store the return code of realloc(). If
the realloc() succeeds, we use the newly-resized list and num_fds. If the
realloc() fails, we use the old list and restore the old num_fds. That way we
always have a valid list.
Now consider the case where we're initially allocating the list. If this
realloc() fails, then old_fds == 0, fsext_list == 0, temp == 0. So we still
end up with a valid combination on exit of grow_table(): fsext_list == 0,
num_fds == 0.
Another thing I did was to make 256 be in a const int (chunk_sz), to help
debugging & readability.
Hope that's clearer! Bye, Rich =]
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
- Raw text -