Date: Fri, 30 Jun 2023 13:52:37 -0800 From: Rob Wing <rob.fx907@gmail.com> To: "Simon J. Gerraty" <sjg@juniper.net> Cc: Jessica Clarke <jrtc27@freebsd.org>, Mitchell Horne <mhorne@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "dev-commits-src-all@freebsd.org" <dev-commits-src-all@freebsd.org>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@freebsd.org> Subject: Re: git: 56f3f2d2491e - main - libsecureboot: avoid set but not used errors Message-ID: <CAF3%2Bn_e9oSVh=jD-AeTPA0nfEpVkG2zyj8Cs-EL3=p4r92O7xg@mail.gmail.com> In-Reply-To: <79845.1688159657@kaos.jnpr.net> References: <202306300652.35U6qpgP027126@gitrepo.freebsd.org> <667C347E-B7C7-405B-AFEC-F0A0FD0656F6@freebsd.org> <498f3ba2-dc7a-e7d3-626a-76ca68cee5b2@freebsd.org> <B59305E1-680B-4793-9779-B872E76B6A34@freebsd.org> <79845.1688159657@kaos.jnpr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
Looking at this snippet:
+ if (!cn.status) {
buf = NULL;
+ if (err == 0) /* keep compiler happy */
+ buf = NULL;
+ }
return (buf);
}
And considering the comment at contrib/bearssl/inc/bearssl_x509.h
<https://github.com/freebsd/freebsd-src/blob/eb33b693b364a4547dfcfd21c159ffc4fb339bc2/contrib/bearssl/inc/bearssl_x509.h#L616>,
is it intended for buf to be returned as-is (i.e., not set to NULL) when
the decoding status indicates an error condition?
On Fri, Jun 30, 2023 at 1:14 PM Simon J. Gerraty <sjg@juniper.net> wrote:
> Jessica Clarke <jrtc27@freebsd.org> wrote:
> > A conditional assignment of the same value that has already been
> > assigned unconditionally is unidiomatic code generally regarded as a
> > code smell and should be avoided. In an ideal world that would give a
>
> I agree.
>
> I've been bitten by __unused recently when porting stuff to linux
> so was looking to avoid that.
>
>
[-- Attachment #2 --]
<div dir="ltr"><div>Looking at this snippet:<br></div><div><br></div><div>+ if (!cn.status) {</div>
buf = NULL;<br>
+ if (err == 0) /* keep compiler happy */<br>
+ buf = NULL;<br>
+ }<br>
return (buf);<br><div>
}</div><div><br></div><div>And considering the comment at <a href="https://github.com/freebsd/freebsd-src/blob/eb33b693b364a4547dfcfd21c159ffc4fb339bc2/contrib/bearssl/inc/bearssl_x509.h#L616">contrib/bearssl/inc/bearssl_x509.h</a>, is it intended for buf to be returned as-is (i.e., not set to NULL) when the decoding status indicates an error condition?<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 30, 2023 at 1:14 PM Simon J. Gerraty <<a href="mailto:sjg@juniper.net">sjg@juniper.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Jessica Clarke <<a href="mailto:jrtc27@freebsd.org" target="_blank">jrtc27@freebsd.org</a>> wrote:<br>
> A conditional assignment of the same value that has already been<br>
> assigned unconditionally is unidiomatic code generally regarded as a<br>
> code smell and should be avoided. In an ideal world that would give a<br>
<br>
I agree.<br>
<br>
I've been bitten by __unused recently when porting stuff to linux<br>
so was looking to avoid that.<br>
<br>
</blockquote></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAF3%2Bn_e9oSVh=jD-AeTPA0nfEpVkG2zyj8Cs-EL3=p4r92O7xg>