>>> On 10.07.18 at 10:44, <[email protected]> wrote: > On 10/07/2018 09:38, Jan Beulich wrote: >>>>> On 10.07.18 at 10:32, <[email protected]> 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 [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
