[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v6 for-4.5 4/5] xl: add 'trim' and 'split_string_into_pair' functions

Wei Liu writes ("Re: [PATCH v6 for-4.5 4/5] xl: add 'trim' and 
'split_string_into_pair' functions"):
> On Wed, Sep 24, 2014 at 09:48:04PM +0100, David Scott wrote:
> > +/* NB: this follows the interface used by <ctype.h>. See 'man 3 ctype'
> > +   and look for CTYPE in libxl_internal.h */
> > +typedef int (*char_predicate_t)(const int c);
> > +
> > +static void trim(char_predicate_t predicate, const char *input, char 
> > **output) __attribute__ ((unused));
> > +static void trim(char_predicate_t predicate, const char *input, char 
> > **output)
> > +{
> > +    char *p, *q, *tmp;
> Ideally you should check input != NULL before dereferencing it. Or you
> need to document this function expects a valid pointer.

(Thanks for looking at this, Wei, but:)

I disagree.  I think in general a function that takes any kind of
pointer should be assumed to require a non-NULL pointer.  It should
not carry out any kind of nullness check; it should just dereference
the pointer (and consequently crash if it is NULL).

If a function permits callers to pass NULL, that should be documented
in the function's doc comment (along, presumably, with the semantics,
if that isn't obvious).

> You didn't restrict number of entries in this function. So a malformed
> "a=b=c" string ends up with "a" in key and "b=c" in value. Is that a
> problem?

That seems desirable to me.  Otherwise `=' becomes another character
that can't be specified in a value.


Xen-devel mailing list



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