Re: [Xen-devel] [PATCH 1/2] xen: Introduce an xmemdup() helper

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.07.18 at 10:44, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 10/07/2018 09:38, Jan Beulich wrote:
>>>>> On 10.07.18 at 10:32, <roger.pau@xxxxxxxxxx> wrote:
>>> On Mon, Jul 09, 2018 at 11:29:47AM +0100, Andrew Cooper wrote:
>>>> --- a/xen/include/xen/xmalloc.h
>>>> +++ b/xen/include/xen/xmalloc.h
>>>> @@ -13,6 +13,16 @@
>>>>  #define xmalloc(_type) ((_type *)_xmalloc(sizeof(_type), 
>>> __alignof__(_type)))
>>>>  #define xzalloc(_type) ((_type *)_xzalloc(sizeof(_type), 
>>> __alignof__(_type)))
>>>>  
>>>> +/* Allocate space for a typed object and copy an existing instance. */
>>>> +#define xmemdup(ptr)                                         \
>>>> +({                                                           \
>>>> +    typeof(*(ptr)) *p_ = (ptr), *n_ = xmalloc(typeof(*p_));  \
>>> Could you do?
>>>
>>> const typeof(*(ptr)) *p_ = (ptr);
>>> typeof(*(ptr)) *n_ = xmalloc(typeof(*p_));
>> Wouldn't this second line again discard const then? If anything I
>> was wondering whether p_ is needed in the first place.
> 
> It is very easy to turn a possibly-const pointer const in the way
> described above.  It doesn't work the other way around because the
> constness of the pointer gets propagated through the typeof, and there
> is no nonconst (or equivalent) keyword.

Sure, but my point was that with the above p_ is a pointer to
const, and hence the type handed to xmalloc() is a pointer to
const. Yet n_ is supposed to be a pointer to non-const, unless
the incoming ptr was.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel