Re: [Xen-devel] [PATCH] fix misc issues related toallowingsupport of more CPUs

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 22.09.08 16:02 >>>
>On 22/9/08 09:35, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:
>
>> On 22/9/08 08:46, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>> 
>>>> Why must it be WARN_ON()? You think you could specify strings so long that
>>>> they overflow 32 bits? You've got other problems in that case.
>>> 
>>> No, that's not the reason. It's because of how bitmap_scnprintf() and
>>> bitmap_scnlistprintf() work - they can (validly, assuming that the code
>>> having been derived from Linux and still being that way in Linux, hence
>>> apparently considered correct) pass negative sizes to scnprintf(), and
>>> hence it must not kill the system to actually do so.
>> 
>> The obvious answer would be to fix the bogus callers. Or consider negative
>> size to be a valid input. Warning on what callers consider valid behaviour
>> is just weird. I would say the former (fix the callers) is the better way to
>> go here; presumably they just need to clamp the size parameter.
>
>Further to this, actually I think the callers in bitmap.c are correct.
>Assuming len<=buflen at the start of the bitmap_scn*() functions (valid
>since buflen is non-negative and len == 0 at function start) then we'll
>never have len>buflen because scnprintf() truncates its return value to be
>less than its size parameter, which is always buflen-len.

Ah, right - while I looked at this difference to snprintf(), I then forgot about
it again.

Thanks for spotting and clarifying, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel