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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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 ##
operator.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel