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

Re: [Xen-devel] [PATCH v2 1/3] xen/domain_page: Convert map_domain_page_global() to using mfn_t

>>> On 13.07.15 at 18:56, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH v2 1/3] xen/domain_page: Convert 
> map_domain_page_global() to using mfn_t"):
>> On 07.07.15 at 12:07, <andrew.cooper3@xxxxxxxxxx> wrote:
>> > Just like free(), these functions are not performing a read-only
>> > operation on the destination pointer, therefore must not be performed on
>> > an actual const pointer.
>> I disagree - from the caller's persepctive they don't modify the data
>> being pointed to (that data is simply becoming undefined). An entity
>> allocating memory, initializing it, and never modifying it again should
>> be allowed to store the pointer in a variable pointing to a const
>> modified type, and free/unmap it without needing any casts. I.e. in
>> fact xfree() and free_xenheap_pages() should have their parameters
>> constified.
> Surely xfree() ought to have the same prototype as free() ?

Why? If it were to be a full match, why wouldn't we call it free() in
the first place?

Note also that Linux has

void kfree(const void *);
void kzfree(const void *);

(with even the krealloc() flavors matching that model).

> free is declared in C99 ( in my copy of TC2) as:
>     void free(void *ptr);
> That is, non-const.  AFAIAA this is not generally regarded as a bug.

Perhaps, but certainly depending on who looks at it. I for my part
dislike (as hinted at above) that I have to cast away const-ness in
order to be able to call free() without causing compiler warnings,
and I generally hide this in wrappers to limit such casting.


Xen-devel mailing list



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