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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Jan Beulich writes ("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:
> > 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?

Is that what is supposed to differ between free and xfree ?  That
would be a bit odd.

In the userland world, xfree is the companion to xmalloc:

  
http://manpages.debian.org/cgi-bin/man.cgi?query=xfree&apropos=0&sektion=0&manpath=Debian+8+jessie&format=html&locale=en

(Although, logically speaking, xfree is unnecessary in that set.)

> Note also that Linux has
> 
> void kfree(const void *);
> void kzfree(const void *);
> 
> (with even the krealloc() flavors matching that model).

How odd.

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

The flipside is that if free can take a const*, functions which take a
const struct foo* can free it.  That's not what I would expect such a
function to do.


Do we need to resolve this disagreement now ?

Ian.

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