Avoid side-effectful assignments in conditionals. #984
Conversation
iphydf
force-pushed
the
no-cond-side-effects
branch
4 times, most recently
from
e5a0004
to
57faf61
Compare
Only in audio.c for now. This should be done everywhere.
iphydf
force-pushed
the
no-cond-side-effects
branch
from
57faf61
to
c0c3098
Compare
There was a problem hiding this comment.
Reviewed 1 of 2 files at r1.
Reviewable status: 0 of 1 LGTMs obtained (waiting on @sudden6)
toxav/audio.c, line 149 at r1 (raw file):
struct RTPMessage *msg = jbuf_read(j_buf, &rc); for (; msg != nullptr || rc == 2; msg = jbuf_read(j_buf, &rc)) {
any special reason not to use a while loop here and move the msg = ... into the body?
There was a problem hiding this comment.
Reviewable status: 0 of 1 LGTMs obtained (waiting on @sudden6)
toxav/audio.c, line 149 at r1 (raw file):
Previously, sudden6 wrote…
any special reason not to use a while loop here and move the
msg = ...into the body?
Because this is a "for-each-element-in-jitter-buffer" loop, so the "for" keyword makes the most sense. Did I miss something?
There was a problem hiding this comment.
Reviewed 1 of 2 files at r1.
Reviewable status:complete! 1 of 1 LGTMs obtained
toxav/audio.c, line 149 at r1 (raw file):
Previously, iphydf wrote…
Because this is a "for-each-element-in-jitter-buffer" loop, so the "for" keyword makes the most sense. Did I miss something?
just wanted to know the reason, because for me this structure always looks incomplete and I would use a while loop here to make the loop header as short as possible. Just personal preference in the end, no need to change it.
Only in audio.c for now. This should be done everywhere.
This change is