Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > muc.lists.netbsd.source-changes > #156211

Re: The --> "operator"

From Greg Troxel <gdt@lexort.com>
Newsgroups muc.lists.netbsd.source-changes
Subject Re: The --> "operator"
Date 2026-07-09 12:53 -0400
Organization Newsgate at muc.de e.V.
Message-ID <rmildbkxfyo.fsf@s1.lexort.com> (permalink)
References <20260708153102.C64DD84DA8@mail.netbsd.org>

Show all headers | View raw


Taylor R Campbell <riastradh@NetBSD.org> writes:

>> Date: Wed, 8 Jul 2026 07:46:38 -0700 (PDT)
>> From: Hisashi T Fujinaka <htodd@twofifty.com>
>> 
>> The fact that the people I trust to know C better than I do are
>> discussing this "operator" means it really isn't that obvious and should
>> probably not be used. Overly clever code is hard to read.
>
> I generally agree about `overly clever' code.  But you haven't said
> which alternative you prefer for iterating safely in reverse over
> array indices the half-open interval [0,N)!
>
> Some of the following options are correct for _only_ signed
> arithmetic, some of the following options are correct for both signed
> and unsigned arithmetic, and some of the following options are broken
> for both.
>
> So, quiz, to be self-timed: Can you work out in 60 seconds or less
> which ones are which?

There are legitimate questions of how to deal with unsigned values and
iteration.   But I don't think that using a non-KNF-compliant
non-standard syntax fixes those questions.

As I see it, the central difficulty is that you must avoid decrmementing
0 and comparing, and if you want N-1 to 0, then you have to have the
loop variable in the conditional and the actual variable used in the
body be different.

Arguably, a way to be understandable is to write something like

        /* Avoid decrementing unsigned 0. */
        for (iplus1 = N; iplus1 > 0; iplus1--) {
          i = iplus1 - 1;
          stuff;
        }

it's jarring, but forces the reader to confront the issue.

Perhaps a macro, perhaps something else.  But when I see "-->" I know
it's ok does not make sense to me.

> I can tell you in a second _one_ of them is definitely correct, and
> for _every other one_ it'll take me at least a few seconds if not a
> few minutes to think about.  And once we've had this conversation
> once, I bet you'll have the same experience.

My initial reaction was that using -- or ++ in the test/middle position
is irregular.  I still think that.

Overall, it seems there are a number of people unhappy about -->, and
that KNF says it's not ok, vs one in favor.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de

Back to muc.lists.netbsd.source-changes | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: The --> "operator" (was: Re: CVS commit: src/sys/uvm) Taylor R Campbell <riastradh@NetBSD.org> - 2026-07-08 15:31 +0000
  Re: The --> "operator" (was: Re: CVS commit: src/sys/uvm) Robert Elz <kre@munnari.OZ.AU> - 2026-07-09 06:59 +0700
    Re: The --> "operator" (was: Re: CVS commit: src/sys/uvm) Valery Ushakov <uwe@stderr.spb.ru> - 2026-07-09 13:22 +0300
      Re: The --> "operator" (was: Re: CVS commit: src/sys/uvm) Robert Elz <kre@munnari.OZ.AU> - 2026-07-09 18:41 +0700
    Re: The --> "operator" (was: Re: CVS commit: src/sys/uvm) Taylor R Campbell <riastradh@NetBSD.org> - 2026-07-09 23:18 +0000
  Re: The --> "operator" Greg Troxel <gdt@lexort.com> - 2026-07-09 12:53 -0400

csiph-web