Re: [PATCH] aout relocs

[msnyder at sonic dot net]

> msnyder@sonic.net writes:
>
>> As near as I can tell, if reloc_size is zero, the routine does
>> nothing useful.  Maybe it will never be zero, but if it is, a few
>> iffy things will happen:
>>
>>  * we'll call malloc with a size of zero, which is ill defined,
>> and later free the result
>
> No, we'll call bfd_malloc with a size of zero.  That is not
> ill-defined.

With hat in hand, are you sure?  bfd_malloc does not check for
size == 0 before it calls malloc, and malloc(0) is "implementation
defined" (whatever that may mean).

> It will either return NULL, or not, as (confusingly)
> specified in the C standard.  Passing a NULL pointer to free will
> always work.
>
>>  * we'll call bfd_bread with a size of zero, and
>
> Which is fine.

Again, are you sure?  bfd_bread doesn't seem to check size either,
and it passes it to memcpy.  Is memcpy(x,y,0) well defined?

>>  * a potentially null pointer may slip thru the cracks.
>
> I'm not sure which pointer you mean here.

OK: we have
  relocs = bfd_malloc (reloc_size);  // which might be zero
  if (relocs == NULL && reloc_size != 0)
    bail;

So now it is possible that relocs == NULL and reloc_size == 0.
And then,

  if (bfd_bread (relocs, reloc_size, abfd)...

And bfd_bread does this:

  memcpy (ptr, bim->buffer + abfd->where, size);

where both ptr and size might be zero.

Note, sorry about the changelog, I'll take care of that.

> Why aout?

I know, I know...   I'm looking at a Coverity scan.