Re: [REPOST PATCH v3 2/2] vfs: parse: deal with zero length string value

[Andrew Morton]

On Tue, 20 Sep 2022 15:26:29 +0800 Ian Kent <raven@xxxxxxxxxx> wrote:

> Parsing an fs string that has zero length should result in the parameter
> being set to NULL so that downstream processing handles it correctly.
> For example, the proc mount table processing should print "(none)" in
> this case to preserve mount record field count, but if the value points
> to the NULL string this doesn't happen.
> 
> ...
>
> --- a/fs/fs_parser.c
> +++ b/fs/fs_parser.c
> @@ -197,6 +197,8 @@ int fs_param_is_bool(struct p_log *log, const struct fs_parameter_spec *p,
>  		     struct fs_parameter *param, struct fs_parse_result *result)
>  {
>  	int b;
> +	if (param->type == fs_value_is_empty)
> +		return 0;
>  	if (param->type != fs_value_is_string)
>  		return fs_param_bad_value(log, param);
>  	if (!*param->string && (p->flags & fs_param_can_be_empty))
> @@ -213,6 +215,8 @@ int fs_param_is_u32(struct p_log *log, const struct fs_parameter_spec *p,
>  		    struct fs_parameter *param, struct fs_parse_result *result)
>  {
>  	int base = (unsigned long)p->data;
> +	if (param->type == fs_value_is_empty)
> +		return 0;
>  	if (param->type != fs_value_is_string)
>  		return fs_param_bad_value(log, param);
>  	if (!*param->string && (p->flags & fs_param_can_be_empty))
>
> [etcetera]

This feels wrong.  Having to check for fs_value_is_empty in so many
places makes me think "we just shouldn't have got this far".  Am I
right for once?