[Spice-devel] [PATCH spice-server 2/3] test-gst: Remove options parsing leaks
Frediano Ziglio
fziglio at redhat.com
Tue Sep 12 11:19:32 UTC 2017
>
> On Tue, Sep 12, 2017 at 05:44:23AM -0400, Frediano Ziglio wrote:
> > >
> > > On Tue, Sep 12, 2017 at 04:11:57AM -0400, Frediano Ziglio wrote:
> > > > >
> > > > > On Tue, Sep 12, 2017 at 03:41:15AM -0400, Frediano Ziglio wrote:
> > > > > > >
> > > > > > > On Tue, Sep 12, 2017 at 03:19:12AM -0400, Frediano Ziglio wrote:
> > > > > > > > > > - const EncoderInfo *encoder =
> > > > > > > > > > get_encoder_info(encoder_name);
> > > > > > > > > > + const EncoderInfo *encoder =
> > > > > > > > > > get_encoder_info(encoder_name
> > > > > > > > > > ?
> > > > > > > > > > encoder_name : "mjpeg");
> > > > > > > > > > if (!encoder) {
> > > > > > > > > > g_printerr("Encoder name unsupported: %s\n",
> > > > > > > > > > encoder_name);
> > > > > > > > >
> > > > > > > > > This is going to be "Encoder name unsupported: (null)" when
> > > > > > > > > the
> > > > > > > > > corresponding option is not given, ditto for the other
> > > > > > > > > options
> > > > > > > > > that
> > > > > > > > > you
> > > > > > > > > changed.
> > > > > > > > >
> > > > > > > >
> > > > > > > > No, the defaults are present so encoder won't be NULL... but I
> > > > > > > > can
> > > > > > > > change
> > > > > > > > the code to make this more clear.
> > > > > > >
> > > > > > > I'm missing something then, the code I quoted is:
> > > > > > >
> > > > > > > const EncoderInfo *encoder = get_encoder_info(encoder_name ?
> > > > > > > encoder_name : "mjpeg");
> > > > > > > if (!encoder) {
> > > > > > > g_printerr("Encoder name unsupported: %s\n",
> > > > > > > encoder_name);
> > > > > > >
> > > > > > > so it looks like encoder_name can be NULL in the call to
> > > > > > > get_encoder_info(), in which case we call
> > > > > > > get_encoder_info("mjpeg")
> > > > > > > instead of get_encoder_info(encoder_name), but right after that,
> > > > > > > in
> > > > > > > the
> > > > > > > g_printerr call, encoder_name cannot be NULL?
> > > > > > >
> > > > > >
> > > > > > No, get_encoder_info("mjpeg") is not supposed to return NULL... but
> > > > > > I
> > > > > > changed
> > > > > > the code to understand it even without reading get_encoder_info,
> > > > > > better.
> > > > >
> > > > > But you are printing "encoder_name" (the input parameter), not
> > > > > "encoder"
> > > > > (the
> > > > > output) !
> > > > >
> > > >
> > > > Yes, the name is encoder_name, the print is referring to name.
> > > > By the way, changed code in last version I sent, should be clear, now
> > > > is
> > > >
> > > > const EncoderInfo *encoder =
> > > > encoder_name ? get_encoder_info(encoder_name) :
> > > > encoder_info_mjpeg;
> > > > if (!encoder) {
> > > > g_printerr("Encoder name unsupported: %s\n", encoder_name);
> > > > exit(1);
> > > > }
> > >
> > > Which is still awful to read..
> > >
> >
> > This is a personal opinion, I don't see any opposite advice in the style
> > document, not any esoteric feature used
>
> Yes this is a personal opinion, but the easier the code is to read for
> the reviewer, the faster your code is going to get in.
> I'm totally fine with updating the style document to say that pointer
> checks should be (encoder != NULL), and to limit (!encoder) to booleans.
> I'm also fine discouraging ?: use.
>
> Christophe
>
This is going OT, I already updated the patch.
About checking for pointer assuming you have to check for NULL
would mean the NULL is not 0 which would mean that
memset(structure_ptr, 0, sizeof(structure)) cannot set pointer
to NULL which would mean that assuming pointer initialized from
GObject NULL are not correct, I would personally vote again
the if (pointer != NULL) style, if (pointer) is good as well.
About ?: I would limit, maybe if you can write it into a single
line, not more, it's a C syntax since ever.
Frediano
More information about the Spice-devel
mailing list