Re: [patch] Fix for PR gdb/10819

[Paul Pluzhnikov <ppluzhnikov@google.com>]

On Thu, Oct 22, 2009 at 4:09 AM, Andreas Schwab <schwab@redhat.com> wrote:

> Note that this is what the C standard requires.  Even if the number of
> elements is zero all pointer arguments must still be valid.

Specifically:

<quote>

In ISO/ IEC 9899:TC2 Committee Draft — May 6, 2005 WG14/N1124:

7.20.5 Searching and sorting utilities

1 These utilities make use of a comparison function to search or sort
arrays of unspecified type. Where an argument declared as size_t nmemb
specifies the length of the array for a function, nmemb can have the
value zero on a call to that function; the comparison function is not
called, a search finds no matching element, and sorting performs no
rearrangement. Pointer arguments on such a call shall still have valid
values, as described in 7.1.4.

And:

7.1.4 Use of library functions

1 Each of the following statements applies unless explicitly stated
otherwise in the detailed descriptions that follow: If an argument to
a function has an invalid value (such as a value outside the domain of
the function, or a pointer outside the address space of the program,
or a null pointer, or a pointer to non-modifiable storage when the
corresponding parameter is not const-qualified) or a type (after
promotion) not expected by a function with variable number of
arguments, the behavior is undefined. If a function argument is
described as being an array, the pointer actually passed to the
function shall have a value such that all address computations and
accesses to objects (that would be valid if the pointer did point to
the first element of such an array) are in fact valid.

</quote>

There appear to be quite a few qsort calls, and for a few I looked at
it's not immediately obvious that they pass a valid pointer when
nmemb==0 or that nmemb!=0.

I'll just fix the bsearch calls, since A) one of them is known to
cause a problem and B) I introduced them recently :-(

Thanks,
-- 
Paul Pluzhnikov