Re: [commit/Tru64] bring back the Tru64 port to life...

[Joel Brobecker <brobecker@adacore.com>]

> Can nsecs be 0 here?

Good question. It seems pretty highly unlikely, but I'm not sure whether
this is possible or not. I couldn't find a whole lot of documentation
about the lmi_nregion field in ldr_module_info_t. But from the code
in solib-osf.c, it looks like this field is actually the number of
sections. I don't see how a shared library could have zero section
and yet still be loaded. If the naming in solib-osf.c got me
confused, and the secs array actually refers to memory regions,
you'd think that there would be at least one region for the code.

> Since it is checked at least here:

Yeah, that's strange.

I can add an extra check, but...

> struct lm_info
>   {
>     int isloader;               /* whether the module is /sbin/loader */
>     int nsecs;                  /* length of .secs */
>     struct lm_sec secs[1];      /* variable-length array of sections, sorted
>                                    by name */
>   };

The previous code was a glorified version of 

   malloc (offsetof (struct lm_info, secs)
           + nsecs * sizeof (struct lm_sec))

The new expression I used should be strictly equivalent:

  malloc (sizeof (struct lm_info)
          + (nsecs - 1) * sizeof (struct lm_sec));

In both cases, if nsecs is zero, we end up allocating less memory
than sizeof (struct lm_info). Intuitively, it seems OK, since we
shouldn't really access the secs array if nsecs is null.

One easy way out is to change the allocation to allocate one extra
entry in the secs array. It's slightly wasteful, but it's just a
few bytes times the number of shared libraries.

What do you think?

-- 
Joel