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

Groups > muc.lists.netbsd.source-changes > #156207 > unrolled thread

Re: The --> "operator" (was: Re: CVS commit: src/sys/uvm)

Back to article view | Back to muc.lists.netbsd.source-changes

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#156207 — Re: The --> "operator" (was: Re: CVS commit: src/sys/uvm)

> 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?

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.

	for (i = N - 1; --i > 0;} { ... i - 1 ... }
	for (i = N - 1; --i > 0;} { ... i ... }
	for (i = N - 1; --i >= 0;} { ... i - 1 ... }
	for (i = N - 1; --i >= 0;} { ... i ... }
	for (i = N - 1; i --> 0;) { ... i - 1 ... }
	for (i = N - 1; i --> 0;) { ... i ... }
	for (i = N - 1; i > 0; i--} { ... i - 1 ... }
	for (i = N - 1; i > 0; i--} { ... i ... }
	for (i = N - 1; i >= 0; i--} { ... i - 1 ... }
	for (i = N - 1; i >= 0; i--} { ... i ... }
	for (i = N - 1; i-- > 0;} { ... i - 1 ... }
	for (i = N - 1; i-- > 0;} { ... i ... }
	for (i = N - 1; i-- >= 0;} { ... i - 1 ... }
	for (i = N - 1; i-- >= 0;} { ... i ... }
	for (i = N; --i > 0;} { ... i - 1 ... }
	for (i = N; --i > 0;} { ... i ... }
	for (i = N; --i >= 0;} { ... i - 1 ... }
	for (i = N; --i >= 0;} { ... i ... }
	for (i = N; i --> 0;) { ... i - 1 ... }
	for (i = N; i --> 0;) { ... i ... }
	for (i = N; i > 0; i--} { ... i - 1 ... }
	for (i = N; i > 0; i--} { ... i ... }
	for (i = N; i >= 0; i--} { ... i - 1 ... }
	for (i = N; i >= 0; i--} { ... i ... }
	for (i = N; i-- > 0;} { ... i - 1 ... }
	for (i = N; i-- > 0;} { ... i ... }
	for (i = N; i-- >= 0;} { ... i - 1 ... }
	for (i = N; i-- >= 0;} { ... i ... }

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

[toc] | [next] | [standalone]

#156208

    Date:        Wed, 8 Jul 2026 15:31:01 +0000
    From:        Taylor R Campbell <riastradh@NetBSD.org>
    Message-ID:  <20260708153102.C64DD84DA8@mail.netbsd.org>


  | 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.

Really?

  | 	for (i = N; i --> 0;) { ... i ... }

That one, which is the one you (claim to) prefer, and

  | 	for (i = N; i-- > 0;} { ... i ... }

this one, which is in KNF (ignoring the statement part), differ by
exactly the positioning of one (unnecessary) space.

	for (i=N;i-->0;} { ... i ...}

is just the same, compressed a bit (I am not suggesting that be used).

You're really unable to see that these 3 all do the exact same thing in more
than about a millisecond?

And KNF does say to surround binary operators (of which '>' is one)
with spaces (--> isn't an operator, it is two).   But KNF's stance on
that is kind of meaningless, as no-one surrounds -> . or [ with spaces,
and yet all are binary operators in C.

kre

ps: while C has not had a habit of inventing new operators (the # and ##
preprocessor operators are the only ones I can think of) in general it
is unwise to run operators into each other, as if someone should decide
to invent a --> operator, and it doesn't do what the two operators it
now represents do, then any use of that would break, whereas -- > never
will.



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

[toc] | [prev] | [next] | [standalone]

#156209

On Thu, Jul 09, 2026 at 06:59:41 +0700, Robert Elz wrote:

>     Date:        Wed, 8 Jul 2026 15:31:01 +0000
>     From:        Taylor R Campbell <riastradh@NetBSD.org>
>     Message-ID:  <20260708153102.C64DD84DA8@mail.netbsd.org>
> 
> 
>   | 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.
> 
> Really?
> 
>   | 	for (i = N; i --> 0;) { ... i ... }
> 
> That one, which is the one you (claim to) prefer, and
> 
>   | 	for (i = N; i-- > 0;} { ... i ... }
> 
> this one, which is in KNF (ignoring the statement part), differ by
> exactly the positioning of one (unnecessary) space.
> 
> 	for (i=N;i-->0;} { ... i ...}
> 
> is just the same, compressed a bit (I am not suggesting that be used).
> 
> You're really unable to see that these 3 all do the exact same thing in more
> than about a millisecond?

In all fairness, minor formatting choices _can_ have big impact.

The following is a true story.  At an old job we hit a bug.  We knew
for a fact that the bug was located in a relatively small fragment of
code.  _5_ engineers took turns staring at that code for a couple of
_hours_ and couldn't see the bug.  The code was something like this:

  if (valgrind) {
      // slow, so increase timeouts a lot
  } if (some condition) {
      // increase timeouts a bit
  } else {
     // ...
  }

This is, btw, why I hate winged "else".

So just as

  if (foo) {
    ...
  } else if (bar) {
    ...
  }

vs.

  if (foo) {
    ...
  }
  else if (bar) {
    ...
  }

is a minor formatting change that, as the story above shows, may have
non-trivial effect on readability, the choice of (index --> 0)
spelling may have a similar effect.  Unfortunately, that spelling is
not just more explicit, but is also "cute", even terminally cute, and
it seems to cause massive cognitive dissonance when encountered by an
unsuspecting reader.

-uwe

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

[toc] | [prev] | [next] | [standalone]

#156210

    Date:        Thu, 9 Jul 2026 13:22:54 +0300
    From:        Valery Ushakov <uwe@stderr.spb.ru>
    Message-ID:  <ak92forfqqXkRfqM@snips.stderr.spb.ru>


  | The code was something like this:
  |

  | This is, btw, why I hate winged "else".
  |
  | So just as
  |
  |   if (foo) {
  |     ...
  |   } else if (bar) {
  |     ...
  |   }
  |
  | vs.
  |
  |   if (foo) {
  |     ...
  |   }
  |   else if (bar) {
  |     ...
  |   }

Sorry, I see no difference in the two.   Certainly cascading if else if ...
really need extra braces, and better indentation to make it clear what else
associates with which if, but I really cannot see how an extra linefeed makes
any difference at all.

kre


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

[toc] | [prev] | [next] | [standalone]

#156212

> Date: Thu, 09 Jul 2026 06:59:41 +0700
> From: Robert Elz <kre@munnari.OZ.AU>
> 
>     Date:        Wed, 8 Jul 2026 15:31:01 +0000
>     From:        Taylor R Campbell <riastradh@NetBSD.org>
>     Message-ID:  <20260708153102.C64DD84DA8@mail.netbsd.org>
> 
>   | 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.
> 
> Really?

Really!

>   | 	for (i = N; i --> 0;) { ... i ... }
> 
> That one, which is the one you (claim to) prefer, and
> 
>   | 	for (i = N; i-- > 0;} { ... i ... }
> 
> this one, which is in KNF (ignoring the statement part), differ by
> exactly the positioning of one (unnecessary) space.
> 
> 	for (i=N;i-->0;} { ... i ...}
> 
> is just the same, compressed a bit (I am not suggesting that be used).
> 
> You're really unable to see that these 3 all do the exact same thing in more
> than about a millisecond?

Absolutely yes, because with

	i-- > 0

I have to stop and think whether pre-increment or post-increment is
correct here.  In contrast

	i --> 0

is highly memorable.

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

[toc] | [prev] | [next] | [standalone]

#156211 — Re: The --> "operator"

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

[toc] | [prev] | [standalone]

Back to top | Article view | muc.lists.netbsd.source-changes

csiph-web