Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #162767 > unrolled thread
| Started by | Mehdi Amini <atorrses@gmail.com> |
|---|---|
| First post | 2021-09-20 10:54 +0430 |
| Last post | 2021-10-21 13:15 +0200 |
| Articles | 20 on this page of 119 — 23 participants |
Back to article view | Back to comp.lang.c
C23 (C2x) changes Mehdi Amini <atorrses@gmail.com> - 2021-09-20 10:54 +0430
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-20 09:35 +0200
Re: C23 (C2x) changes Mehdi Amini <atorrses@gmail.com> - 2021-09-21 11:01 +0430
Re: C23 (C2x) changes John Bode <jfbode1029@gmail.com> - 2021-09-20 10:41 -0500
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-20 18:17 +0200
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-20 18:55 +0100
Re: C23 (C2x) changes scott@slp53.sl.home (Scott Lurndal) - 2021-09-20 18:21 +0000
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-20 21:39 +0200
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-20 21:07 +0100
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-20 22:59 +0200
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-20 22:29 +0100
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-20 17:43 -0700
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-21 17:56 +0200
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-21 18:05 +0100
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-21 11:42 -0700
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-22 11:37 +0200
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-22 11:55 +0100
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-22 14:21 +0200
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-22 13:58 +0100
Re: C23 (C2x) changes Ian Pilcher <arequipeno@gmail.com> - 2021-09-22 12:02 -0500
Re: C23 (C2x) changes scott@slp53.sl.home (Scott Lurndal) - 2021-09-22 17:19 +0000
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-20 23:05 +0100
Re: C23 (C2x) changes scott@slp53.sl.home (Scott Lurndal) - 2021-09-20 22:47 +0000
Re: C23 (C2x) changes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-09-20 22:58 +0000
Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-02 07:16 -0700
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 15:15 +0000
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-20 17:45 -0700
Re: C23 (C2x) changes Manfred <noname@add.invalid> - 2021-09-27 17:15 +0200
Re: C23 (C2x) changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-27 17:38 +0100
Re: C23 (C2x) changes Manfred <noname@add.invalid> - 2021-09-27 23:18 +0200
Re: C23 (C2x) changes antispam@math.uni.wroc.pl - 2021-09-28 13:53 +0000
Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-02 08:07 -0700
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 15:18 +0000
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-02 15:04 -0700
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-03 01:58 +0000
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-02 22:06 -0700
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-03 10:43 +0000
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-03 13:30 -0700
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 05:04 +0000
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-03 23:24 -0700
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 06:54 +0000
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-10-04 09:58 +0200
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 15:52 +0000
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-04 10:45 -0700
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 20:30 +0000
Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-06 03:57 -0700
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-06 12:27 +0000
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-29 03:38 +0000
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-15 11:35 +0100
Re: C23 (C2x) changes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-10-15 18:27 +0000
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-15 20:08 +0100
Re: C23 (C2x) changes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-10-15 19:20 +0000
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-15 21:50 +0100
Re: C23 (C2x) changes Florian Weimer <fw@deneb.enyo.de> - 2021-10-03 09:43 +0200
Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-10-03 18:53 +0200
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-03 13:55 -0700
Re: C23 (C2x) changes William Ahern <william@25thandClement.com> - 2021-09-21 22:57 -0700
Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-02 08:55 -0700
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 16:36 +0000
Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-09-22 20:27 +0200
Re: C23 (C2x) changes Philipp Klaus Krause <pkk@spth.de> - 2021-09-22 22:25 +0200
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-22 14:05 -0700
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-22 23:24 +0100
Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-09-22 18:49 -0700
Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-09-23 18:47 +0200
Static bounds checking (was Re: C23 (C2x) changes) William Ahern <william@25thandClement.com> - 2021-09-23 21:11 -0700
Re: Static bounds checking (was Re: C23 (C2x) changes) David Brown <david.brown@hesbynett.no> - 2021-09-24 08:51 +0200
Re: Static bounds checking (was Re: C23 (C2x) changes) Philipp Klaus Krause <pkk@spth.de> - 2021-09-24 09:30 +0200
Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-24 07:52 +0000
Re: Static bounds checking (was Re: C23 (C2x) changes) Philipp Klaus Krause <pkk@spth.de> - 2021-09-24 12:32 +0200
Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-24 10:49 +0000
Re: Static bounds checking (was Re: C23 (C2x) changes) Philipp Klaus Krause <pkk@spth.de> - 2021-09-24 14:46 +0200
Re: Static bounds checking (was Re: C23 (C2x) changes) Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-24 18:14 +0200
Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 01:00 +0000
Re: Static bounds checking (was Re: C23 (C2x) changes) Philipp Klaus Krause <pkk@spth.de> - 2021-09-25 07:44 +0200
Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 11:28 +0000
Re: Static bounds checking (was Re: C23 (C2x) changes) antispam@math.uni.wroc.pl - 2021-09-28 10:56 +0000
Re: Static bounds checking (was Re: C23 (C2x) changes) Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 09:48 +0200
Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 11:30 +0000
Re: Static bounds checking (was Re: C23 (C2x) changes) Kaz Kylheku <480-992-1380@kylheku.com> - 2021-09-25 20:49 +0000
Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-26 00:04 +0000
Re: Static bounds checking (was Re: C23 (C2x) changes) Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-26 06:56 +0200
Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-09-27 10:15 -0700
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-27 11:15 -0700
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-27 22:11 +0200
Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-09-27 14:20 -0700
Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-09-27 14:31 -0700
Re: C23 (C2x) changes Mehdi Amini <atorrses@gmail.com> - 2021-09-28 10:43 +0330
Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-06 04:01 -0700
Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-10-06 04:42 -0700
Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 04:04 -0700
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-10-29 16:34 +0200
Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-10-06 19:07 +0200
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-10-07 11:06 +0200
Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-10-07 19:31 +0200
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-10-07 22:14 +0200
Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-10-08 06:18 -0700
Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-10-08 06:21 -0700
Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 04:01 -0700
Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-15 12:59 +0200
Re: C23 (C2x) changes Jim Jackson <jj@franjam.org.uk> - 2021-10-15 16:50 +0000
Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-16 07:51 +0200
Re: C23 (C2x) changes "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-16 11:50 -0700
Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-16 21:28 +0200
Re: C23 (C2x) changes Jim Jackson <jj@franjam.org.uk> - 2021-10-17 17:18 +0000
Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-17 20:00 +0200
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-17 19:17 +0100
Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-18 06:49 +0200
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-18 11:23 +0100
Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-18 14:09 +0200
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-21 01:07 +0000
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-21 01:02 +0000
Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-10-16 21:28 +0200
Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-17 06:04 +0200
Re: C23 (C2x) changes Manfred <noname@add.invalid> - 2021-10-17 19:35 +0200
Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-17 20:01 +0200
Re: C23 (C2x) changes "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-17 14:15 -0700
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-21 01:02 +0000
Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-21 13:15 +0200
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2021-09-22 22:25 +0200 |
| Message-ID | <sig3fm$91t$1@solani.org> |
| In reply to | #162820 |
Am 22.09.21 um 20:27 schrieb Guillaume: > - Tagged blocks/tagged loop constructs. > >[…] > > That would be more elegant and easier to statically analyze than goto's. No. It would not be better than goto. Neither for users nor for static analysis. AFAIK this has been proposed and rejected multiple times before (e.g. N1989 at the London 2016 WG14 meeting). Regarding analysis (and likely also code readability), one important parameter is the tree-width of the control-flow graph. For C this is bounded by a constant plus the number of labels for goto used per function. The situation is similar for many other languages. And at least for tree-width, it has been proven that unlimited use of labeled break / labeled continue, like Java has, would be just as bad as unlimited use of goto. If you need to get out of an inner loop, just use goto. Avoiding goto by introducing another variant of goto that just isn't called goto won't make the standard better.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-09-22 14:05 -0700 |
| Message-ID | <87mto4micx.fsf@nosuchdomain.example.com> |
| In reply to | #162821 |
Philipp Klaus Krause <pkk@spth.de> writes:
> Am 22.09.21 um 20:27 schrieb Guillaume:
>
>> - Tagged blocks/tagged loop constructs.
>>
>>[…]
>>
>> That would be more elegant and easier to statically analyze than goto's.
>
> No. It would not be better than goto. Neither for users nor for static
> analysis. AFAIK this has been proposed and rejected multiple times
> before (e.g. N1989 at the London 2016 WG14 meeting).
>
> Regarding analysis (and likely also code readability), one important
> parameter is the tree-width of the control-flow graph. For C this is
> bounded by a constant plus the number of labels for goto used per
> function. The situation is similar for many other languages. And at
> least for tree-width, it has been proven that unlimited use of labeled
> break / labeled continue, like Java has, would be just as bad as
> unlimited use of goto.
>
> If you need to get out of an inner loop, just use goto. Avoiding goto by
> introducing another variant of goto that just isn't called goto won't
> make the standard better.
The proposal in N1989
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1989.htm
was to have "break 2;" break out of two enclosing loops. (The Bourne
shell has this feature.) Personally, I dislike this. It's easy to
forget to update the number when the code is rearranged, and it forces
the programmer and reader to count nesting levels -- and counting, after
all, is something that computers are really really good at.
What I'd like to see is *named* loops, with "break" and "continue"
optionally taking an argument that names the loop to be operated on.
I've used other languages with this feature, and I've found it quite
useful.
It would, of course, be equivalent to a goto targeting a point after the
end of the loop ("continue" might be a little more complicated), but the
point is that it's restricted ("break foo" can't jump to an arbitrary
location) and it documents what it's doing.
I think of "break foo" as an operation on the loop named "foo", not an
operation that refers to a specific location in the code.
It would make no difference to static analysis, but in my opinion it
would make for more legible code in the (perhaps not very common) case
where you want to break out of nested loops.
Ada has this feature. It uses a deliberately heavy syntax for goto
labels:
<< LABEL >>
-- ...
goto LABEL;
but a simple identifier followed by a colon for labeled loops:
Loop_Name:
for I in 1..10 loop
-- ...
exit Loop_Name; -- Ada spells "break" as "exit"
end loop;
Perl uses the same syntax for goto labels and loop names, which means if
you see a loop name you can't be sure without checking that there isn't
a goto somewhere that targets it. I haven't found that to be a problem
in practice:
Loop_Name:
for my $i (1 .. 10) {
# ...
last Loop_Name; # Perl spells "break" as "last"
}
In both languages, if you omit the label on a break/exit/last statement
it applies to the innermost enclosing loop. Of course C would have to
do the same.
Off the top of my head, I can't think of a good simple syntax for loop
labels that's distinct from the syntax for goto labels, so perhaps a
"break name" construct could just refer to a goto label that's applied
to an iteration or switch statement. "break foo;" where "foo" is a
label that *doesn't* apply to an iteration or switch statement would be
a constraint violation.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-22 23:24 +0100 |
| Message-ID | <sigaf7$j1$1@dont-email.me> |
| In reply to | #162822 |
On 22/09/2021 22:05, Keith Thompson wrote:
> Philipp Klaus Krause <pkk@spth.de> writes:
>> Am 22.09.21 um 20:27 schrieb Guillaume:
>>
>>> - Tagged blocks/tagged loop constructs.
>>>
>>> […]
>>>
>>> That would be more elegant and easier to statically analyze than goto's.
>>
>> No. It would not be better than goto. Neither for users nor for static
>> analysis. AFAIK this has been proposed and rejected multiple times
>> before (e.g. N1989 at the London 2016 WG14 meeting).
>>
>> Regarding analysis (and likely also code readability), one important
>> parameter is the tree-width of the control-flow graph. For C this is
>> bounded by a constant plus the number of labels for goto used per
>> function. The situation is similar for many other languages. And at
>> least for tree-width, it has been proven that unlimited use of labeled
>> break / labeled continue, like Java has, would be just as bad as
>> unlimited use of goto.
>>
>> If you need to get out of an inner loop, just use goto. Avoiding goto by
>> introducing another variant of goto that just isn't called goto won't
>> make the standard better.
>
> The proposal in N1989
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1989.htm
> was to have "break 2;" break out of two enclosing loops. (The Bourne
> shell has this feature.) Personally, I dislike this. It's easy to
> forget to update the number when the code is rearranged, and it forces
> the programmer and reader to count nesting levels -- and counting, after
> all, is something that computers are really really good at.
>
> What I'd like to see is *named* loops, with "break" and "continue"
> optionally taking an argument that names the loop to be operated on.
> I've used other languages with this feature, and I've found it quite
> useful.
Named loops means having to invent names for things, which can be
annoying when the thing you're refering to is right there.
It makes it harder to copy and paste code within the same function,
since the loop names need to be revised. Unless you invent new scope
rules for those names so that they are local to that set of loops.
Also, if your intention is to break out of an entire set of nested
loops, you label the outer one, but then wrap it with an extra loop
level (or copy it into another loop), that 'outer' loop label may no
longer be the outermost.
I say, keep things simple. While I use numbered loops 1 (innermost) to N
(outermost), I also allow 0 to mean the outermost, so that most often
I'd write:
break # defaults to loop 1, innermost
break all # 'all' is a synonym for 0, so outermost
(Although my syntax uses 'exit' not break.)
Breaking out of any in-between loop is rare. For a start, you'd need 3
nested loop levels, itself uncommon.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2021-09-22 18:49 -0700 |
| Message-ID | <ef2dc441-6e2e-4f6b-b3a4-61e4a372fdeen@googlegroups.com> |
| In reply to | #162823 |
On Wednesday, September 22, 2021 at 7:24:45 PM UTC-3, Bart wrote: > On 22/09/2021 22:05, Keith Thompson wrote: > > Philipp Klaus Krause <p...@spth.de> writes: > >> Am 22.09.21 um 20:27 schrieb Guillaume: > >> > >>> - Tagged blocks/tagged loop constructs. > >>> > >>> […] > >>> > >>> That would be more elegant and easier to statically analyze than goto's. > >> > >> No. It would not be better than goto. Neither for users nor for static > >> analysis. AFAIK this has been proposed and rejected multiple times > >> before (e.g. N1989 at the London 2016 WG14 meeting). > >> > >> Regarding analysis (and likely also code readability), one important > >> parameter is the tree-width of the control-flow graph. For C this is > >> bounded by a constant plus the number of labels for goto used per > >> function. The situation is similar for many other languages. And at > >> least for tree-width, it has been proven that unlimited use of labeled > >> break / labeled continue, like Java has, would be just as bad as > >> unlimited use of goto. > >> > >> If you need to get out of an inner loop, just use goto. Avoiding goto by > >> introducing another variant of goto that just isn't called goto won't > >> make the standard better. > > > > The proposal in N1989 > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1989.htm > > was to have "break 2;" break out of two enclosing loops. (The Bourne > > shell has this feature.) Personally, I dislike this. It's easy to > > forget to update the number when the code is rearranged, and it forces > > the programmer and reader to count nesting levels -- and counting, after > > all, is something that computers are really really good at. > > > > What I'd like to see is *named* loops, with "break" and "continue" > > optionally taking an argument that names the loop to be operated on. > > I've used other languages with this feature, and I've found it quite > > useful. > Named loops means having to invent names for things, which can be > annoying when the thing you're refering to is right there. > > It makes it harder to copy and paste code within the same function, > since the loop names need to be revised. Unless you invent new scope > rules for those names so that they are local to that set of loops. > > Also, if your intention is to break out of an entire set of nested > loops, you label the outer one, but then wrap it with an extra loop > level (or copy it into another loop), that 'outer' loop label may no > longer be the outermost. > > I say, keep things simple. While I use numbered loops 1 (innermost) to N > (outermost), I also allow 0 to mean the outermost, so that most often > I'd write: > > break # defaults to loop 1, innermost > break all # 'all' is a synonym for 0, so outermost > > (Although my syntax uses 'exit' not break.) > > Breaking out of any in-between loop is rare. For a start, you'd need 3 > nested loop levels, itself uncommon. If you have a label it is as bad as goto. We need more kinds of structured jumps. I have suggested try throw catch (because I didn't find better name) that are basically a local jump to catch - doesn't matter if you are inside loops or not. Traditional loop operators are so old and all the languages have the same, so it's hard to get used to new jump names.
[toc] | [prev] | [next] | [standalone]
| From | Guillaume <message@bottle.org> |
|---|---|
| Date | 2021-09-23 18:47 +0200 |
| Message-ID | <siib3l$1i8b$1@gioia.aioe.org> |
| In reply to | #162822 |
Le 22/09/2021 à 23:05, Keith Thompson a écrit : > Philipp Klaus Krause <pkk@spth.de> writes: >> Am 22.09.21 um 20:27 schrieb Guillaume: >> >>> - Tagged blocks/tagged loop constructs. >>> >>> […] >>> >>> That would be more elegant and easier to statically analyze than goto's. >> >> No. It would not be better than goto. Neither for users nor for static >> analysis. AFAIK this has been proposed and rejected multiple times >> before (e.g. N1989 at the London 2016 WG14 meeting). >> >> Regarding analysis (and likely also code readability), one important >> parameter is the tree-width of the control-flow graph. For C this is >> bounded by a constant plus the number of labels for goto used per >> function. The situation is similar for many other languages. And at >> least for tree-width, it has been proven that unlimited use of labeled >> break / labeled continue, like Java has, would be just as bad as >> unlimited use of goto. >> >> If you need to get out of an inner loop, just use goto. Avoiding goto by >> introducing another variant of goto that just isn't called goto won't >> make the standard better. > > The proposal in N1989 > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1989.htm > was to have "break 2;" break out of two enclosing loops. (The Bourne > shell has this feature.) Personally, I dislike this. It's easy to > forget to update the number when the code is rearranged, and it forces > the programmer and reader to count nesting levels -- and counting, after > all, is something that computers are really really good at. It is indeed atrocious. And nothing like what I suggested. > > What I'd like to see is *named* loops, with "break" and "continue" > optionally taking an argument that names the loop to be operated on. > I've used other languages with this feature, and I've found it quite > useful. Yes, this is exactly what I suggested. And yes, this is useful, clear to read, and much better than goto's that are not attached to any structure.
[toc] | [prev] | [next] | [standalone]
| From | William Ahern <william@25thandClement.com> |
|---|---|
| Date | 2021-09-23 21:11 -0700 |
| Subject | Static bounds checking (was Re: C23 (C2x) changes) |
| Message-ID | <sovv1i-kui1.ln1@wilbur.25thandClement.com> |
| In reply to | #162767 |
Mehdi Amini <atorrses@gmail.com> wrote: > Hi, > > It seems these are some of changes for C23(C2x) standard taken from > draft documents: > > https://en.cppreference.com/w/c/23 > https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting Does anybody know how well received have been the various proposals for improving static bounds checking? Most proposals build on function declarator VLA syntax. That seems like the path of least resistance. Though, perhaps the backwards compatibility headaches silently make it the path of *most* resistance...?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-24 08:51 +0200 |
| Subject | Re: Static bounds checking (was Re: C23 (C2x) changes) |
| Message-ID | <sijsif$k9m$1@dont-email.me> |
| In reply to | #162827 |
On 24/09/2021 06:11, William Ahern wrote: > Mehdi Amini <atorrses@gmail.com> wrote: >> Hi, >> >> It seems these are some of changes for C23(C2x) standard taken from >> draft documents: >> >> https://en.cppreference.com/w/c/23 >> https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting > > Does anybody know how well received have been the various proposals for > improving static bounds checking? Most proposals build on function > declarator VLA syntax. That seems like the path of least resistance. Though, > perhaps the backwards compatibility headaches silently make it the path of > *most* resistance...? > Have you examples of what you mean here? I don't understand what you are talking about - perhaps because I am unfamiliar with the relevant proposals. If you are thinking of the "Annex K Bounds-checking interface" functions, that was, AFAIK, a total flop. It is overly complex, inconvenient, doesn't do what people want, and is unlikely to make anything safer or more reliable in any way - /if/ any toolchain and library bothered to implement it. (If anyone has contradictory arguments, I'd love to hear them.)
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2021-09-24 09:30 +0200 |
| Subject | Re: Static bounds checking (was Re: C23 (C2x) changes) |
| Message-ID | <sijuqt$s3f$1@solani.org> |
| In reply to | #162828 |
Am 24.09.21 um 08:51 schrieb David Brown: > On 24/09/2021 06:11, William Ahern wrote: >> Mehdi Amini <atorrses@gmail.com> wrote: >>> Hi, >>> >>> It seems these are some of changes for C23(C2x) standard taken from >>> draft documents: >>> >>> https://en.cppreference.com/w/c/23 >>> https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting >> >> Does anybody know how well received have been the various proposals for >> improving static bounds checking? Most proposals build on function >> declarator VLA syntax. That seems like the path of least resistance. Though, >> perhaps the backwards compatibility headaches silently make it the path of >> *most* resistance...? >> > > Have you examples of what you mean here? I don't understand what you > are talking about - perhaps because I am unfamiliar with the relevant > proposals. > N2660, N2779. AFAIR due to lack of time it wasn't discusses at this meeting. At the previous one, there was discussion, but no vote (see the minutes N2802).
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@gmail.com> |
|---|---|
| Date | 2021-09-24 07:52 +0000 |
| Subject | Re: Static bounds checking (was Re: C23 (C2x) changes) |
| Message-ID | <ptf3J.44292$ol1.39305@fx42.iad> |
| In reply to | #162827 |
Such things should be *optional*, we are not *kids*. -- 7-77-777 \|/ --- /|\ On 2021-09-24, William Ahern <william@25thandClement.com> wrote: > Mehdi Amini <atorrses@gmail.com> wrote: >> Hi, >> >> It seems these are some of changes for C23(C2x) standard taken from >> draft documents: >> >> https://en.cppreference.com/w/c/23 >> https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting > > Does anybody know how well received have been the various proposals for > improving static bounds checking? Most proposals build on function > declarator VLA syntax. That seems like the path of least resistance. Though, > perhaps the backwards compatibility headaches silently make it the path of > *most* resistance...? > -- Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2021-09-24 12:32 +0200 |
| Subject | Re: Static bounds checking (was Re: C23 (C2x) changes) |
| Message-ID | <sik9gb$116$1@solani.org> |
| In reply to | #162830 |
Am 24.09.21 um 09:52 schrieb Branimir Maksimovic: > Such things should be *optional*, we are not *kids*. > It is optional: You can always use pointer parameters to pass your arrays to your functions instead of VLA parameters. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@gmail.com> |
|---|---|
| Date | 2021-09-24 10:49 +0000 |
| Subject | Re: Static bounds checking (was Re: C23 (C2x) changes) |
| Message-ID | <q3i3J.84531$g81.37380@fx33.iad> |
| In reply to | #162831 |
What's purpose of VLA then? I always used alloca for that? -- 7-77-777 \|/ /|\ On 2021-09-24, Philipp Klaus Krause <pkk@spth.de> wrote: > Am 24.09.21 um 09:52 schrieb Branimir Maksimovic: >> Such things should be *optional*, we are not *kids*. >> > > It is optional: You can always use pointer parameters to pass your > arrays to your functions instead of VLA parameters. > > Philipp -- Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2021-09-24 14:46 +0200 |
| Subject | Re: Static bounds checking (was Re: C23 (C2x) changes) |
| Message-ID | <sikhbe$5gk$1@solani.org> |
| In reply to | #162832 |
Am 24.09.21 um 12:49 schrieb Branimir Maksimovic: > What's purpose of VLA then? I always used alloca for that? > Both VLAs and alloca can be used to allocate memory (though alloca is non-standard, and VLAs are optional since C11). But VLA types can also be used for other purposes, in particular as the type of a function parameter, which is the use relevant to this discussion.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-09-24 18:14 +0200 |
| Subject | Re: Static bounds checking (was Re: C23 (C2x) changes) |
| Message-ID | <sikth7$vpc$1@dont-email.me> |
| In reply to | #162830 |
Am 24.09.2021 um 09:52 schrieb Branimir Maksimovic: > Such things should be *optional*, we are not *kids*. There seem to be a lot of kids since buffer-overflow-errors are very common in C. C++ in contrast provides []-operator and iterators which have very convenient debug-boundschecking. > > -- > 7-77-777 > \|/ > --- > /|\ > On 2021-09-24, William Ahern <william@25thandClement.com> wrote: >> Mehdi Amini <atorrses@gmail.com> wrote: >>> Hi, >>> >>> It seems these are some of changes for C23(C2x) standard taken from >>> draft documents: >>> >>> https://en.cppreference.com/w/c/23 >>> https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting >> >> Does anybody know how well received have been the various proposals for >> improving static bounds checking? Most proposals build on function >> declarator VLA syntax. That seems like the path of least resistance. Though, >> perhaps the backwards compatibility headaches silently make it the path of >> *most* resistance...? >> > >
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@gmail.com> |
|---|---|
| Date | 2021-09-25 01:00 +0000 |
| Subject | Re: Static bounds checking (was Re: C23 (C2x) changes) |
| Message-ID | <8xu3J.74157$QzOf.42137@fx17.iad> |
| In reply to | #162834 |
Look, bounds checking is costly, if done in run time, and people think that using to_string is not efficient :P -- 7-77-777 \|/ --- /|\ On 2021-09-24, Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 24.09.2021 um 09:52 schrieb Branimir Maksimovic: >> Such things should be *optional*, we are not *kids*. > > There seem to be a lot of kids since buffer-overflow-errors are very > common in C. C++ in contrast provides []-operator and iterators which > have very convenient debug-boundschecking. > >> >> -- >> 7-77-777 >> \|/ >> --- >> /|\ >> On 2021-09-24, William Ahern <william@25thandClement.com> wrote: >>> Mehdi Amini <atorrses@gmail.com> wrote: >>>> Hi, >>>> >>>> It seems these are some of changes for C23(C2x) standard taken from >>>> draft documents: >>>> >>>> https://en.cppreference.com/w/c/23 >>>> https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting >>> >>> Does anybody know how well received have been the various proposals for >>> improving static bounds checking? Most proposals build on function >>> declarator VLA syntax. That seems like the path of least resistance. Though, >>> perhaps the backwards compatibility headaches silently make it the path of >>> *most* resistance...? >>> >> >> > -- Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2021-09-25 07:44 +0200 |
| Subject | Re: Static bounds checking (was Re: C23 (C2x) changes) |
| Message-ID | <simcvk$r2n$1@solani.org> |
| In reply to | #162835 |
Am 25.09.21 um 03:00 schrieb Branimir Maksimovic: > Look, bounds checking is costly, if done in run time, […] Yes. But unlike Annex K, which is about runtime bounds checking, the features now discussed for C23 are about improving static bounds checking, i.e. compile-time bounds checking. Via array types, including VLA types, as function parameters. This could allow both improved diagnostics and optimization in the callee. AFAIR the main problem is that the syntax already has a meaning (an array currently just decays to a pointer). But maybe actual use is uncommen enough that it can still be changed.
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@gmail.com> |
|---|---|
| Date | 2021-09-25 11:28 +0000 |
| Subject | Re: Static bounds checking (was Re: C23 (C2x) changes) |
| Message-ID | <XJD3J.125617$F26.95788@fx44.iad> |
| In reply to | #162836 |
On 2021-09-25, Philipp Klaus Krause <pkk@spth.de> wrote: > Am 25.09.21 um 03:00 schrieb Branimir Maksimovic: >> Look, bounds checking is costly, if done in run time, […] > > Yes. But unlike Annex K, which is about runtime bounds checking, the > features now discussed for C23 are about improving static bounds > checking, i.e. compile-time bounds checking. Via array types, including > VLA types, as function parameters. This could allow both improved > diagnostics and optimization in the callee. > > AFAIR the main problem is that the syntax already has a meaning (an > array currently just decays to a pointer). But maybe actual use is > uncommen enough that it can still be changed. Problem is that, in order that to work, how you can check, when using malloc or passing array to library function? -- 7-77-777 Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2021-09-28 10:56 +0000 |
| Subject | Re: Static bounds checking (was Re: C23 (C2x) changes) |
| Message-ID | <siusco$b2q$1@z-news.wcss.wroc.pl> |
| In reply to | #162836 |
Philipp Klaus Krause <pkk@spth.de> wrote:
> Am 25.09.21 um 03:00 schrieb Branimir Maksimovic:
> > Look, bounds checking is costly, if done in run time, [?]
>
> Yes. But unlike Annex K, which is about runtime bounds checking, the
> features now discussed for C23 are about improving static bounds
> checking, i.e. compile-time bounds checking. Via array types, including
> VLA types, as function parameters. This could allow both improved
> diagnostics and optimization in the callee.
>
> AFAIR the main problem is that the syntax already has a meaning (an
> array currently just decays to a pointer). But maybe actual use is
> uncommen enough that it can still be changed.
I did not see current proposal in the standard. However, in the past
I have seen proposal for bounds checking in C. The whole idea was
that syntax should be acceptable to existing compiler and as long
as accesses are in bounds existing compiler should generate
correct code. Such proposals may break existing code, however
probably no more than type based alias analysis. And given
compile-time nature of checking conseqences of breakage should
be quite managable.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-09-25 09:48 +0200 |
| Subject | Re: Static bounds checking (was Re: C23 (C2x) changes) |
| Message-ID | <simk7g$afa$1@dont-email.me> |
| In reply to | #162835 |
> Look, bounds checking is costly, if done in run time, and people think that > using to_string is not efficient :P Bounds-checking is only costly when you have random-access array access. If you iterate linearely the loop will be split in three passes by the optimizer: the part before the begin of the array, the part within the array and the part afterwards; that's how Java and Rust do it. And Rust isn't significantly slower than C or c++.
[toc] | [prev] | [next] | [standalone]
| From | Branimir Maksimovic <branimir.maksimovic@gmail.com> |
|---|---|
| Date | 2021-09-25 11:30 +0000 |
| Subject | Re: Static bounds checking (was Re: C23 (C2x) changes) |
| Message-ID | <LLD3J.125618$F26.58164@fx44.iad> |
| In reply to | #162837 |
On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote: >> Look, bounds checking is costly, if done in run time, and people think that >> using to_string is not efficient :P > > Bounds-checking is only costly when you have random-access array access. > If you iterate linearely the loop will be split in three passes by the > optimizer: the part before the begin of the array, the part within the > array and the part afterwards; that's how Java and Rust do it. And Rust > isn't significantly slower than C or c++. > That's costly. Fact when iterating over array hides it (because of cache), but not all accesses are sequential. -- 7-77-777 Evil Sinner!
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <480-992-1380@kylheku.com> |
|---|---|
| Date | 2021-09-25 20:49 +0000 |
| Subject | Re: Static bounds checking (was Re: C23 (C2x) changes) |
| Message-ID | <20210925134720.515@kylheku.com> |
| In reply to | #162839 |
On 2021-09-25, Branimir Maksimovic <branimir.maksimovic@gmail.com> wrote: > On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Look, bounds checking is costly, if done in run time, and people think that >>> using to_string is not efficient :P >> >> Bounds-checking is only costly when you have random-access array access. >> If you iterate linearely the loop will be split in three passes by the >> optimizer: the part before the begin of the array, the part within the >> array and the part afterwards; that's how Java and Rust do it. And Rust >> isn't significantly slower than C or c++. >> > > That's costly. > Fact when iterating over array hides it (because of cache), but not all accesses > are sequential. Never mind caching; when you're iterating over an array, you can hoist the bounds check out of the loop (if you know that the loop has no termination condition other than the array bounds). -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web