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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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 (7.20.3.2 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.

Jan


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