On Fri, 2015-10-16 at 11:39 +0100, Wei Liu wrote:
> On Fri, Oct 16, 2015 at 11:33:12AM +0100, Ian Campbell wrote:
> > GC* assume an existing gc in scope, which means they can't be passed
> > NOGC. Instead recommend the use of the underlying functions with NOGC,
> > noting that this is excepitonal.
> >
> > Signed-off-by: Ian Campbell <ian.campb...@citrix.com>
> > ---
> > tools/libxl/CODING_STYLE | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/libxl/CODING_STYLE b/tools/libxl/CODING_STYLE
> > index a65efb3..545dc77 100644
> > --- a/tools/libxl/CODING_STYLE
> > +++ b/tools/libxl/CODING_STYLE
> > @@ -57,13 +57,14 @@ whenever they are applicable. For example:
> > libxl__log[v] LOG, LOGE, LOGEV
> > libxl__sprintf GCSPRINTF
> > libxl__*alloc et al. GCNEW, GCNEW_ARRAY, GCREALLOC_ARRAY
> > - malloc et al. GCNEW, GCNEW_ARRAY, GCREALLOC_ARRAY with
> > NOGC
> > isalnum etc. directly CTYPE
> > libxl__ctx_[un]lock CTX_LOCK, CTX_UNLOCK
> > gc=...; ao=...; EGC_GC, AO_GC, STATE_AO_GC
> > explicit gc creation GC_INIT, GC_FREE
> > memset(..,0,sizeof..) FILLZERO
> >
> > +Instead of malloc et al one should (as an exception to the above) use
> > +libxl__{zalloc,alloc,realloc} etc but passing NOGC.
> >
>
> There is no libxl__alloc. DYM libxl__malloc?
I meant libxl__calloc.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
