[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

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:


(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 ( 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 ?


Xen-devel mailing list



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