Re: [evolution-patches] fix for bug #55280 (camel-object)

[Not Zed <notzed ximian com>]

As discussed on irc.

 - the code should be count-CAMEL_ARGV_MAX since the structure already
has CAMEL_ARGV_MAX args inside of it.  This just allocates the right
amount of space.
 - just do a sanity check on the count, since its unsigned, just do
something like count < 1024 or something.
 - this stuff shouldn't depend on the architecture anyway, the whole
point of encode/decode uint32 :(  So I guess something is going awry
somewhere in that code.  it should be checked.

(although some other stuff does depend on the architecutre, like
write_time_t etc).

On Wed, 2004-03-10 at 14:04 -0500, Jeffrey Stedfast wrote:

> http://bugzilla.ximian.com/show_bug.cgi?id=55280
> 
> The g_try_malloc() replacement is just so that if the count value is
> too high (corrupt?) that we don't abort(), especially since it's not a
> major deal if we can't set the meta data on the object.
> 
> I'm not sure what (count - CAMEL_ARGV_MAX) was supposed to do? if
> count was less than 20, then we'd end up trying to malloc a negative
> amount of memory (or, rather, a really large amount of memory). If
> count == 20, then we'd malloc just enough space for the containing
> struct, but none of the args. And finally, if count was > 20, we'd
> malloc 20 fewer args than we'd need...
> 
> or, at least that's what it looked like to me. From what I could tell,
> CAMEL_ARGV_MAX was meant to be a limiter when setting a bunch of args.
> Maybe that malloc call was copy/paste-o'd from somewhere else where it
> was valid. 
> 
> Jeff
>