[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] xen/many: xfree() can tolerate NULL pointers

>>> On 19.01.15 at 12:12, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 19/01/15 10:54, Ian Campbell wrote:
>> On Mon, 2015-01-19 at 10:42 +0000, Andrew Cooper wrote:
>>> Replace instances of "if ( p ) xfree(p)" with just "xfree(p)"
>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>> CC: Keir Fraser <keir@xxxxxxx>
>>> CC: Jan Beulich <JBeulich@xxxxxxxx>
>>> CC: Tim Deegan <tim@xxxxxxx>
>>> CC: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
>>> CC: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
>>> ---
>>> This was from some experimentation with semantic patches.  'spatch' can't
>>> currently parse some of our macros (e.g. XEN_GUEST_HANDLE()), which cases it
>>> to skip large numbers of functions in the codebase
>> How annoying! (and surprising)
> It also can't parse the "case $X ... $Y:" syntax if the spaces around
> the ellipsis is missing.  This is a little more understandable as this
> gccism does introduce an ambiguity into the grammar, insofar that 1...3
> is not a valid floating point constant.
> We have a number of uses with #defined numbers uses without spaces. 
> This turns out to be safe only because the preprocessor replacement puts
> spaces around replaced tokens.

Spaces? That could end up being problematic (e.g. when
subsequently making the resulting token sequence subject to a
# operator). Afaik the preprocessor simply doesn't concatenate
adjacent tokens after expansion, unless told so by the ##


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.