Re: [PATCH net-next 2/2] tools: ynl: check alloc fails in generated code

[Thaison Phan <thaisonphan@google.com>]

> Silently eating errors in setters does not seem great, better to crash
> and make it clear than things are not working than have a silently
> misconfigured system?

I was thinking that the user could check for NULL in the struct field that
the setter was allocating for to see if something went wrong, but that is
probably not ideal either since a user might assume with the void return
there can be no errors, and I didn't realize the field is not guaranteed to
be NULL when it is passed in.

> AI also points out that setters are preceded by a free (in case we're
> replacing existing attr, multiple sets on a single attr are allowed) So
> if alloc fails we'll end up with NULL ptr and len from previous
> allocation.

That makes sense, so we could have an unreported free() on the key someone
using the setter might think is still allocated. We could maybe delay the
free() until after the malloc() works, and maybe we could return an error
code in setters that allocate to let users know something went wrong.

> Maybe tackle the setters in a separate patch, and keep patch 2 scoped
> to the easier case?

That sounds like a good idea to me. I'll make v2 only tackle the getters
and look into a different way to handle the setters.

Thanks,
Thaison