sin dixit:
>On Thu, Aug 15, 2013 at 11:00:11AM +0000, Thorsten Glaser wrote:
>
>> > if(len+1 > *size && !(*p = realloc(*p, len+1)))
^^^^^
>> > eprintf("realloc:");
>> >
>> >- strcpy(&(*p)[len-n], buf);
>> >+ snprintf(&(*p)[len-n], n+1, "%s", buf);
>>
>> Again, I object… you do not calculate the length correctly.
>> Besides, this looks like a strlcat to me… if not, memcpy
>> might again be more wise; n+1 doesn’t match with len+1 from above.
>
>Will change these to memcpy(), thanks. However, I don't understand why n + 1
>is wrong here?
p is allocated with “len+1” bytes, so “len+1” should show up in
its size calculations… I admit (len+1-(len-n)) factors out as
n+1, but let the compiler do that was said recently AFAICT?
Anyway, this kind of offset magic is prone to produce buffer
over-/underflows later when other people touch the code.
Better be explicit: if you want a strcat, use strlcat.
>> Is not using spaces around operators normal for sbase, btw?
>> This is horrid. Please read https://www.mirbsd.org/man9/style
>> for something nicer-looking. (I used to do it wrong, too.)
>
>I always use spaces, however, the existing code I was changing was not
>using spaces.
Right – my comment on spaces was not a comment on your patch.
Sorry if that was unclear.
bye,
//mirabilos
--
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
Received on Thu Aug 15 2013 - 13:34:32 CEST