Re: [Xen-devel] [PATCH for-4.10] libxl: handle NULL in libxl__enum_from_string

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Wei Liu writes ("Re: [PATCH for-4.10] libxl: handle NULL in 
libxl__enum_from_string"):
> I agree they shouldn't be called with NULL. We should guard against
> error (here or the libxl_*_type_from_string) or annotate the input can't
> be NULL.

I mean, who calls any  libxl_*_from_string  with s==NULL ?

Also I don't think we should annotate that the input value can't be
NULL, especially in a situation like this where the semantics could
only be "this is wrong".  The API (and the internal calling
conventions) are full of functions taking pointer arguments - are we
going to annotate each one of those to say that it cannot be NULL ?

Instead, what we have actually done so far, is annotate when a pointer
parameter *may* be NULL, and, in that case, what that means:

 * If ao_how==NULL, the function will be synchronous.
 * If ao_how->callback==NULL, a libxl_event will be generated which
  /* if old_name is NULL, any old name is OK; otherwise we check
/* May be called with info_r == NULL to check for domain's existence.
   * event_occurs may be NULL if mask is 0.
   * disaster may be NULL.  If it is, or if _register_callbacks has
 * The application may call beforepoll with fds==NULL and
_hidden void libxl__ptr_add(libxl__gc *gc_opt, void *ptr /* may be * NULL */) 
NN1;
_hidden char *libxl__strdup(libxl__gc *gc_opt,
                            const char *c /* may be NULL */) NN1;

etc. etc.

Ian.

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