Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #399456 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-05-27 19:53 +0200 |
| Last post | 2026-05-30 11:18 +0200 |
| Articles | 20 on this page of 172 — 17 participants |
Back to article view | Back to comp.lang.c
this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 19:53 +0200
Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 20:15 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-27 18:49 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 04:53 +0000
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 02:35 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:32 +0000
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 20:07 -0500
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-28 11:48 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-28 09:18 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 04:57 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:35 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:52 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 05:20 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-29 13:22 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 15:16 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 13:52 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-30 14:40 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 16:36 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-30 15:48 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:14 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-31 13:25 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:14 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 15:22 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-30 03:49 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-28 12:47 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:56 +0200
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-29 11:00 -0700
Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-28 17:12 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 14:07 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:54 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 10:02 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 12:19 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 14:46 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 14:22 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 17:15 +0200
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-05-29 15:59 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:12 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:48 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 19:09 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:00 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:14 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:05 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:34 +0200
Re: this girl calls c ugly tTh <tth@none.invalid> - 2026-05-29 19:29 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 18:53 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:28 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 20:49 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:03 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 13:56 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:54 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 15:52 -0700
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-29 20:31 -0400
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 02:03 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 19:02 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 12:12 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-30 12:29 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 13:56 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 16:43 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-31 03:37 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 19:53 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:16 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:47 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:55 +0200
Re: this girl calls c ugly Richard Harnden <richard.nospam@gmail.invalid> - 2026-05-31 09:12 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:49 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 11:10 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 13:18 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:24 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 17:35 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 12:46 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:24 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 18:26 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:28 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 15:54 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:39 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:33 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:48 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-02 06:37 -0400
Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 05:06 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:28 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:35 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 06:29 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 16:10 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:29 -0700
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-02 13:59 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 13:05 +0000
Parentheses (was: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 14:38 +0100
Re: Parentheses (was: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
[OT] Fancy graphics (was Re: this girl calls c ugly) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 15:54 +0200
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 15:19 +0100
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 17:39 +0200
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:36 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 21:33 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-02 14:43 -0700
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-02 17:08 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 19:19 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:39 -0700
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-03 13:14 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:10 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:31 +0000
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:15 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 16:29 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 03:45 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 04:02 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 09:04 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 18:11 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-31 19:34 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 19:10 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:12 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:36 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:26 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 09:52 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:42 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:50 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:47 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:55 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:39 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 15:11 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 08:41 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 02:07 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:38 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:01 -0700
It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:39 +0000
Re: It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:42 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 11:46 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 11:09 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:25 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 14:20 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:12 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 04:16 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-01 15:23 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 16:06 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 23:24 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:35 +0200
Operator precedence in other (non-C, but "C-like") languages (Was: something about a girl) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:36 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 11:04 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 14:04 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 18:48 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 21:04 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:17 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:09 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 12:07 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 14:37 +0200
Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:06 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-31 19:11 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 16:08 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 16:32 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 17:12 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 14:07 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:10 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 19:18 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:17 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 21:47 +0100
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-29 15:57 -0400
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:34 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-29 23:18 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 01:26 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-30 04:25 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 12:01 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-31 00:29 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 10:59 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-01 00:33 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 02:26 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 13:24 +0200
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-29 08:09 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 04:15 -0500
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-29 14:58 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-30 01:04 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-29 23:20 +0000
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-30 11:18 +0200
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-02 16:28 +0000 |
| Subject | Re: Constants and undefined behavior |
| Message-ID | <10vn0bk$ghg$1@reader1.panix.com> |
| In reply to | #399615 |
In article <86ik81cfk5.fsf_-_@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
>> On 2026-06-01 00:54, Keith Thompson wrote:
>>
>>>> [...]
>>>
>>> Yes, a compiler can reduce (a + b) * 0 to just 0. But it's not
>>> required to do so, and (INT_MAX + 1) * 0 still has undefined
>>> behavior. Undefined behavior is determined by the rules of the
>>> abstract machine *without* any adjustments permitted by the as-if
>>> rule.
>>
>> This is something I really don't get in the actual C-logic...
>>
>> Using constants that can be determined at compile time is UB here,
>> despite the '* 0' mathematically indicating an IMO clear semantics,
>> but using variables is only UB possibly at runtime? [...]
>
>There's an important distinction to make here. Consider this
>program:
>
> #include <limits.h>
>
> int
> foo(){
> int zero = (INT_MAX+1)*0;
> return zero;
> }
>
> int
> main(){
> return 0;
> }
>
>This program does not transgress the bounds of undefined behavior.
Given that `foo` has external linkage, I find this hard to
believe, and `clang -fsanitize=undefined` agrees with me,
both emitting a diagnostic about the overflow and generating
code in `foo` to call into the sanitizer machinery.
Perhaps you mean that this is irrelevant because `foo` is not
invoked, but I see no reason why that need be the case in e.g.
a freestanding environment. In a hosted environment, I don't
think anything explicitly prevents `foo` from being called after
`main` returns (though I can't imagine that would happen in real
life; it would be weird if it did).
But I'm not sure what _you_ mean by "transgress the bounds of
undefined behavior" here.
>Even more than that, the program is strictly conforming, and must be
>accepted by a conforming implementation.
See above.
>Now let's change the program slightly:
>
> #include <limits.h>
>
> int
> foo(){
> static int zero = (INT_MAX+1)*0;
> return zero;
> }
>
> int
> main(){
> return 0;
> }
>
>This program does transgress the bounds of undefined behavior. The
>reason for the difference is that in the first program the semantics
>of foo() is to evaluate the expression to be stored in 'zero' only
>at runtime, whereas in the second program the semantics of foo() is
>to evaluate the expression to be stored in 'zero' before program
>startup (informally, "at compile time"). What matters is not
>whether the offending expression /might/ be evaluated "at compile
>time", but whether the offending expression /must/ be evaluated "at
>compile time". Only in the second case is undefined behavior
>inevitable (and thus it does not occur in the first program).
>
>Fine point: strictly speaking, I believe the C standard allows even
>the second program to complete translation phase 8 successfully, and
>for any offending behavior to occur only when we actually try to run
>the program. To say that another way, there is no requirement that
>possible nasal demons be made manifest at any point before an actual
>attempted execution. On the other hand, because that possibility is
>there lurking in the background, there is no requirement that the
>program be accepted, and could be rejected by a conforming compiler.
Indeed. Further, I believe that the same is true for the first
program, as well.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-02 05:35 -0700 |
| Message-ID | <10vmimv$2tjoi$3@kst.eternal-september.org> |
| In reply to | #399608 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-06-01 00:54, Keith Thompson wrote:
>>> [...]
>> Yes, a compiler can reduce (a + b) * 0 to just 0. But it's not
>> required to do so, and (INT_MAX + 1) * 0 still has undefined
>> behavior. Undefined behavior is determined by the rules of the
>> abstract machine *without* any adjustments permitted by the as-if
>> rule.
>
> This is something I really don't get in the actual C-logic...
>
> Using constants that can be determined at compile time is UB here,
> despite the '* 0' mathematically indicating an IMO clear semantics,
> but using variables is only UB possibly at runtime? And despite all
> that the latter might not even get triggered because it's probably
> optimized away? - I can't help, this sounds really crude.
>
> Is there any rationale from the _software designer_'s perspective?
In the abstract machine, every operator and subexpression is
evaluated (barring things like "||", "&&", and "?:"). (INT_MAX + 1)
has undefined behavior due to overflow, therefore any expression
that has (INT_MAX + 1) as a subexpression has undefined behavior.
Replacing (expr * 0) by 0 is an optimization, and optimizations
are *optional*. A naive implementation could generate code that
peforms the addition and the muliplication by 0; if the addition
traps, it traps.
Note that in a context that requires a constant expression, overflow is
a constraint violation. For example, a case label like:
case (INT_MAX + 1) * 0:
must be diagnosed at compile time.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-02 06:29 -0700 |
| Message-ID | <86ecipcbqa.fsf@linuxsc.com> |
| In reply to | #399618 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Note that in a context that requires a constant expression, overflow is > a constraint violation. For example, a case label like: > > case (INT_MAX + 1) * 0: > > must be diagnosed at compile time. gcc disagrees with you.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-02 16:10 +0200 |
| Message-ID | <10vmo8n$2ruaa$3@dont-email.me> |
| In reply to | #399625 |
On 02/06/2026 15:29, Tim Rentsch wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > >> Note that in a context that requires a constant expression, overflow is >> a constraint violation. For example, a case label like: >> >> case (INT_MAX + 1) * 0: >> >> must be diagnosed at compile time. > > gcc disagrees with you. My testing shows all versions of gcc that I tested on godbolt gave a warning, even without any options. I don't believe that INT_MAX can have any type suffixes that would avoid the overflow. What version of gcc and/or flags let that case label pass without a diagnostic? (I don't know if Keith is correct about it being a constraint violation - I have not looked at the details there.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-02 15:29 -0700 |
| Message-ID | <10vnlgu$382un$2@kst.eternal-september.org> |
| In reply to | #399625 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Note that in a context that requires a constant expression, overflow is
>> a constraint violation. For example, a case label like:
>>
>> case (INT_MAX + 1) * 0:
>>
>> must be diagnosed at compile time.
>
> gcc disagrees with you.
What makes you think so?
$ cat c.c
#include <limits.h>
int main(void) {
switch (0) {
case (INT_MAX + 1) * 0:
break;
}
}
$ gcc -std=c17 -pedantic-errors -c c.c
c.c: In function ‘main’:
c.c:4:23: warning: integer overflow in expression of type ‘int’ results in ‘-2147483648’ [-Woverflow]
4 | case (INT_MAX + 1) * 0:
| ^
c.c:4:9: error: overflow in constant expression [-Woverflow]
4 | case (INT_MAX + 1) * 0:
| ^~~~
$
But taking a closer look at the standard, I'm not 100% sure that the
language requires a diagnostic, though I think that's the intent.
The relevant constraint is:
Each constant expression shall evaluate to a constant that is
in the range of representable values for its type.
If I squint really hard, I can argue that the entire expression
has to be a constant expression, but it doesn't say that its
subexpressions are constant expressions -- and *if* INT_MAX +
1 evaluates to INT_MIN in the current implementation, then
(INT_MAX + 1) * 0 evaluates to 0 and therefore satisfies the
constraint.
But INT_MAX + 1 could legally trap, for example, and I don't believe
it was intended that a given expression can be a constant expression
or not depending on the vagaries of the behavior of an instance
of UB.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-06-02 13:59 -0700 |
| Message-ID | <10vng7e$377sq$1@dont-email.me> |
| In reply to | #399569 |
On 5/31/2026 3:54 PM, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 31/05/2026 16:24, James Kuyper wrote: >>> On 2026-05-31 07:18, David Brown wrote: > [...] >>>> People might think they affect the order of evaluation, such as when you >>>> have function calls : >>>> >>>> u = foo(x) + (foo(y) + foo(z)); >>>> >>>> Some people might think the use of parentheses means that "foo(y)" and >>>> "foo(z)" are called before "foo(x)", when the order of all these calls >>>> (and the additions) is unspecified. (Again, a given compiler might be >>>> influenced by the parentheses, but the language does not require it. >>> >>> You're correct with regard to the function calls, but the >>> parenthesized addition must be performed first, and the other one >>> second, which may make a difference, for the same reasons given in my >>> previous paragraph. >> >> The parentheses do not dictate the order of evaluation. But you are >> correct - and it's worth pointing out, so thank you for doing that - >> that for floating point operations, the grouping of operations can >> affect the result. > > The parentheses do not dictate the order of evaluation *of the > operands*. Each "+" can be evaluated (the addition performed) > only after the values of its operands are known. But regardless > of parentheses or operator precedence, the three operands foo(x), > foo(y), and foo(z) can be evaluated in any of 6 possible orders. > (It's different when you have operations like "&&", "||", and ",", > which imposes additional sequence points.) > >> If you are talking about floating point arithmetic (I was thinking of >> integer arithmetic, but did not specify), then the operations are not >> necessarily commutative or associative, and the compiler cannot then >> re-arrange the operations unless it knows that doing so does not >> affect the result. > > It's not just floating-point. Signed integer overflow is also relevant. > > (INT_MIN + INT_MAX) + 1 is well defined. (INT_MIN + INT_MAX) +1 > is equivalent, and is also well defined. INT_MIN + (INT_MAX +1) > has undefined behavior. > >> But except for specific cases, the order of evaluation - both for the >> values and side-effects - of sub-expressions is unspecified. Indeed, >> they are unsequenced - the evaluations can interleave. >> >> Usually, both sub-expressions of a binary operator will be evaluated >> before the operator itself, simply because usually the results of the >> operator cannot be calculated until the sub-expression's values are >> known. But this is not a requirement of the language - if the >> compiler can get the same results without doing so, it is free to pick >> a different order. "(a + b) * 0" does not need to evaluate "a", "b", >> or "a + b" at all unless there is a possibility of a side-effect - and >> it can perform the side-effects in any order. "a + (b + c)" can check >> "a" for a trap representation and deal with that before looking at "b" >> and "c" or the results of "b + c", even though it cannot (for floating >> point operations) re-arrange the code to do "a + b" first. > > Yes, a compiler can reduce (a + b) * 0 to just 0. But it's not > required to do so, and (INT_MAX + 1) * 0 still has undefined > behavior. Undefined behavior is determined by the rules of the > abstract machine *without* any adjustments permitted by the as-if > rule. > > [...] > 10 + 5 - 7 + 3 Oh my this is an error for the programmers logic! they forgot to do: 10 + 5 - (7 + 3) ?
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-02 13:05 +0000 |
| Message-ID | <10vmke4$4bm$1@reader1.panix.com> |
| In reply to | #399550 |
In article <10vh1eo$1ei50$2@dont-email.me>, Bart <bc@freeuk.com> wrote:
>On 31/05/2026 10:49, David Brown wrote:
>> On 31/05/2026 10:12, Richard Harnden wrote:
>>> On 31/05/2026 00:43, Keith Thompson wrote:
>>>> C's operator precedence rules are complicated and arguably flawed.
>>>> They could have been defined differently. A simpler set of rules,
>>>> with fewer levels,*might* have been better. I don't have any
>>>> concrete suggestions -- nor do I have any strong preferences.
>>>> I accept C's rules as they are. I would accept them if they had
>>>> been defined differently.
>>>
>>> Can't the compiler easily remove any parens that aren't necessary?
>>> So - just write complex expressions in a way that a human can most
>>> easily understand, it makes your intention clear and probable doesn't
>>> increase the size of the executable.
>>
>> Of course. Parentheses do not affect the generated code unless they
>> affect the semantics of the expression. (Some people think parentheses
>> affect the order of evaluation,
>
>They can do if they make a expression be parsed differently. Do you have
>an example where they make no difference but people might think they do?
This is all a bit of a distraction from the original point that
David and Richard Harnden were trying to make, which seemed
clear enough to me, but perhaps should have been given with a
better example. Maybe something like:
d = a*b + c;
Is equivalent to,
d = (a*b) + c;
And in this case, the parentheses are superfluous and don't
change the order of evaluation of the expression as far as the
language is concerned. Whether a compiler rearranges it in
generated code in a way that is more convenient of faster or
whatever is another matter.
I would quibble with this idea that the compiler "removes"
parentheses. I get the intuition, but C is not Go where the
compiler "inserts" semi-colons for you, and has no analogous
concept. Rather, as I think Keith said, expressions are parsed
into some internal representation, and then transformed into
something like an abstract syntax tree, where syntactic
notations like parentheses are lost.
Both expressions above correspond to an AST like:
┌───────┐
│BinOp +│
└───────┘
╱ ╲
╱ ╲
┌───────┐ ┌───────┐
│BinOp *│ │Sym `c`│
└───────┘ └───────┘
╱ ╲
╱ ╲
┌───────┐ ┌───────┐
│Sym `a`│ │Sym `b`│
└───────┘ └───────┘
But the to get to that, it may be that the compiler uses a
different initial representation, like a parse tree that more
closely resembles the source language grammar. Here, the
two expressions might have different parsed representations.
E.g., for the first, simplifying heavily, may look something
like this:
┌──────┐
│ expr │
└──────┘
╱ │ ╲
╱ │ ╲
┌─────┐ . ┌─────┐
│term │ (+) │term │
└─────┘ ' └─────┘
╱ │ ╲ │
╱ │ ╲ │
┌─────┐ . ┌─────┐ ┌─────┐
│ident│ (*) │ident│ │ident│
└─────┘ ' └─────┘ └─────┘
│ │ │
│ │ │
.─. .─. .─.
(`a`) (`b`) (`c`)
`─' `─' `─'
While the second might add an extra `expr` node, as in:
┌──────┐
│ expr │
└──────┘
╱ │ ╲
╱ │ ╲
┌──────┐ . ┌─────┐
│ expr │ (+) │term │
└──────┘ ' └─────┘
│ │
│ │
┌─────┐ ┌─────┐
│term │ │ident│
└─────┘ └─────┘
╱ │ ╲ │
╱ │ ╲ │
┌─────┐ . ┌─────┐ .─.
│ident│ (*) │ident│ (`c`)
└─────┘ ' └─────┘ `─'
│ │
│ │
.─. .─.
(`a`) (`b`)
`─' `─'
I believe that the answer, for most compilers that parse and
then convert to an AST, the second is more likely to be created
than the first. However, given that the same AST is created
from both parse trees, this is unlikely to have an effect on the
object code ultimately output from the compiler.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-02 14:38 +0100 |
| Subject | Parentheses (was: this girl calls c ugly) |
| Message-ID | <10vmmc2$2utb2$2@dont-email.me> |
| In reply to | #399623 |
On 02/06/2026 14:05, Dan Cross wrote: > In article <10vh1eo$1ei50$2@dont-email.me>, Bart <bc@freeuk.com> wrote: >> On 31/05/2026 10:49, David Brown wrote: >>> On 31/05/2026 10:12, Richard Harnden wrote: >>>> On 31/05/2026 00:43, Keith Thompson wrote: >>>>> C's operator precedence rules are complicated and arguably flawed. >>>>> They could have been defined differently. A simpler set of rules, >>>>> with fewer levels,*might* have been better. I don't have any >>>>> concrete suggestions -- nor do I have any strong preferences. >>>>> I accept C's rules as they are. I would accept them if they had >>>>> been defined differently. >>>> >>>> Can't the compiler easily remove any parens that aren't necessary? >>>> So - just write complex expressions in a way that a human can most >>>> easily understand, it makes your intention clear and probable doesn't >>>> increase the size of the executable. >>> >>> Of course. Parentheses do not affect the generated code unless they >>> affect the semantics of the expression. (Some people think parentheses >>> affect the order of evaluation, >> >> They can do if they make a expression be parsed differently. Do you have >> an example where they make no difference but people might think they do? > > This is all a bit of a distraction from the original point that > David and Richard Harnden were trying to make, which seemed > clear enough to me, but perhaps should have been given with a > better example. Maybe something like: > > d = a*b + c; > > Is equivalent to, > > d = (a*b) + c; > > And in this case, the parentheses are superfluous and don't > change the order of evaluation of the expression as far as the > language is concerned. Whether a compiler rearranges it in > generated code in a way that is more convenient of faster or > whatever is another matter. > > I would quibble with this idea that the compiler "removes" > parentheses. I get the intuition, but C is not Go where the > compiler "inserts" semi-colons for you, and has no analogous > concept. Rather, as I think Keith said, expressions are parsed > into some internal representation, and then transformed into > something like an abstract syntax tree, where syntactic > notations like parentheses are lost. > > Both expressions above correspond to an AST like: > > ┌───────┐ > │BinOp +│ > └───────┘ > ╱ ╲ > ╱ ╲ > ┌───────┐ ┌───────┐ > │BinOp *│ │Sym `c`│ > └───────┘ └───────┘ > ╱ ╲ > ╱ ╲ > ┌───────┐ ┌───────┐ > │Sym `a`│ │Sym `b`│ > └───────┘ └───────┘ > > But the to get to that, it may be that the compiler uses a > different initial representation, like a parse tree that more > closely resembles the source language grammar. Here, the > two expressions might have different parsed representations. > E.g., for the first, simplifying heavily, may look something > like this: > > ┌──────┐ > │ expr │ > └──────┘ > ╱ │ ╲ > ╱ │ ╲ > ┌─────┐ . ┌─────┐ > │term │ (+) │term │ > └─────┘ ' └─────┘ > ╱ │ ╲ │ > ╱ │ ╲ │ > ┌─────┐ . ┌─────┐ ┌─────┐ > │ident│ (*) │ident│ │ident│ > └─────┘ ' └─────┘ └─────┘ > │ │ │ > │ │ │ > .─. .─. .─. > (`a`) (`b`) (`c`) > `─' `─' `─' > > While the second might add an extra `expr` node, as in: > > ┌──────┐ > │ expr │ > └──────┘ > ╱ │ ╲ > ╱ │ ╲ > ┌──────┐ . ┌─────┐ > │ expr │ (+) │term │ > └──────┘ ' └─────┘ > │ │ > │ │ > ┌─────┐ ┌─────┐ > │term │ │ident│ > └─────┘ └─────┘ > ╱ │ ╲ │ > ╱ │ ╲ │ > ┌─────┐ . ┌─────┐ .─. > │ident│ (*) │ident│ (`c`) > └─────┘ ' └─────┘ `─' > │ │ > │ │ > .─. .─. > (`a`) (`b`) > `─' `─' > > I believe that the answer, for most compilers that parse and > then convert to an AST, the second is more likely to be created > than the first. However, given that the same AST is created > from both parse trees, this is unlikely to have an effect on the > object code ultimately output from the compiler. You're describing a 'Concrete Syntax Tree' or CST, versus AST. Although in that case, I expect to see a discrete node for bracketed expressions (ie. parenthesised), as those would also have a distinct production in any formal grammar. Personally I don't have much use for CSTs for a normal compiler, but they might be useful for source-to-source translators, or programs that do source refactoring, where you want to preserve extras such as parentheses even if they're not strictly needed. (Injecting the right parentheses for examples like `(a + b) * c' which would have an AST like '(* (+ a b) c)' is surpringly tricky. Easier to just follow the original source! In any case, that still wouldnt't turn ((a+b)) back into the original; you'd need a suitable CST.)
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-02 15:19 +0000 |
| Subject | Re: Parentheses (was: this girl calls c ugly) |
| Message-ID | <10vms98$cev$2@reader1.panix.com> |
| In reply to | #399626 |
In article <10vmmc2$2utb2$2@dont-email.me>, Bart <bc@freeuk.com> wrote: >On 02/06/2026 14:05, Dan Cross wrote: >You're describing a 'Concrete Syntax Tree' or CST, versus AST. Yes. "Concrete Syntax Tree" is another name for "Parse Tree". >Although in that case, I expect to see a discrete node for bracketed >expressions (ie. parenthesised), as those would also have a distinct >production in any formal grammar. Was that not in the second parse tree diagram I presented? Granted, I called it "expr", but as I noted, I was simplifying heavily, mostly for space. >Personally I don't have much use for CSTs for a normal compiler, but >they might be useful for source-to-source translators, or programs that >do source refactoring, where you want to preserve extras such as >parentheses even if they're not strictly needed. I think you're missing the point, here. The question was whether, given some compiler, `a*b + c` generates different code from `(a*b) + c`, and what it means for the compiler to "remove the parentheses." I submit that, with respect to the former, the answer is "very very unlikely" and with respect to the latter, the question is a category error. >(Injecting the right parentheses for examples like `(a + b) * c' which >would have an AST like '(* (+ a b) c)' is surpringly tricky. Easier to >just follow the original source! > >In any case, that still wouldnt't turn ((a+b)) back into the original; >you'd need a suitable CST.) That's not related to what I was trying to convey. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-02 15:54 +0200 |
| Subject | [OT] Fancy graphics (was Re: this girl calls c ugly) |
| Message-ID | <10vmna7$3uus8$13@dont-email.me> |
| In reply to | #399623 |
On 2026-06-02 15:05, Dan Cross wrote: > [...] > > ┌──────┐ > │ expr │ > └──────┘ > ╱ │ ╲ > ╱ │ ╲ > ┌──────┐ . ┌─────┐ > │ expr │ (+) │term │ > └──────┘ ' └─────┘ > │ │ > │ │ > ┌─────┐ ┌─────┐ > │term │ │ident│ > └─────┘ └─────┘ > ╱ │ ╲ │ > ╱ │ ╲ │ > ┌─────┐ . ┌─────┐ .─. > │ident│ (*) │ident│ (`c`) > └─────┘ ' └─────┘ `─' > │ │ > │ │ > .─. .─. > (`a`) (`b`) > `─' `─' > > [...] I suppose you have some tool to create those fancy graphics? What are you using for that? - Or is that all hand-crafted? Janis
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-02 15:19 +0100 |
| Subject | Re: [OT] Fancy graphics (was Re: this girl calls c ugly) |
| Message-ID | <10vmoph$2utb2$3@dont-email.me> |
| In reply to | #399627 |
On 02/06/2026 14:54, Janis Papanagnou wrote: > On 2026-06-02 15:05, Dan Cross wrote: >> [...] >> >> ┌──────┐ >> │ expr │ >> └──────┘ >> ╱ │ ╲ >> ╱ │ ╲ >> ┌──────┐ . ┌─────┐ >> │ expr │ (+) │term │ >> └──────┘ ' └─────┘ >> │ │ >> │ │ >> ┌─────┐ ┌─────┐ >> │term │ │ident│ >> └─────┘ └─────┘ >> ╱ │ ╲ │ >> ╱ │ ╲ │ >> ┌─────┐ . ┌─────┐ .─. >> │ident│ (*) │ident│ (`c`) >> └─────┘ ' └─────┘ `─' >> │ │ >> │ │ >> .─. .─. >> (`a`) (`b`) >> `─' `─' >> >> [...] > > I suppose you have some tool to create those fancy graphics? > What are you using for that? - Or is that all hand-crafted? The rectangles are just using box-drawing characters. Most times I use them, they have small spaces between the lines, but here on Thunderbird there are no spaces. Conversely, if I post the above to a Github .md file, then I see spaces. The rest is just clever ASCII art.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-02 15:19 +0000 |
| Subject | Re: [OT] Fancy graphics (was Re: this girl calls c ugly) |
| Message-ID | <10vmsas$cev$3@reader1.panix.com> |
| In reply to | #399627 |
In article <10vmna7$3uus8$13@dont-email.me>, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >On 2026-06-02 15:05, Dan Cross wrote: >> [...] >> >> ┌──────┐ >> │ expr │ >> └──────┘ >> ╱ │ ╲ >> ╱ │ ╲ >> ┌──────┐ . ┌─────┐ >> │ expr │ (+) │term │ >> └──────┘ ' └─────┘ >> │ │ >> │ │ >> ┌─────┐ ┌─────┐ >> │term │ │ident│ >> └─────┘ └─────┘ >> ╱ │ ╲ │ >> ╱ │ ╲ │ >> ┌─────┐ . ┌─────┐ .─. >> │ident│ (*) │ident│ (`c`) >> └─────┘ ' └─────┘ `─' >> │ │ >> │ │ >> .─. .─. >> (`a`) (`b`) >> `─' `─' >> >> [...] > >I suppose you have some tool to create those fancy graphics? >What are you using for that? - Or is that all hand-crafted? I used, "monodraw" on the Mac. I can't do that by hand; I am not artistically gifted. :-) - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-02 17:39 +0200 |
| Subject | Re: [OT] Fancy graphics (was Re: this girl calls c ugly) |
| Message-ID | <10vmtgc$3uus8$14@dont-email.me> |
| In reply to | #399633 |
On 2026-06-02 17:19, Dan Cross wrote: > In article <10vmna7$3uus8$13@dont-email.me>, > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >> On 2026-06-02 15:05, Dan Cross wrote: >>> [...] >> >> I suppose you have some tool to create those fancy graphics? >> What are you using for that? - Or is that all hand-crafted? > > I used, "monodraw" on the Mac. I can't do that by hand; I am > not artistically gifted. :-) What a pity that it's not available for Linux. Janis
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-02 16:36 +0000 |
| Subject | Re: [OT] Fancy graphics (was Re: this girl calls c ugly) |
| Message-ID | <10vn0pv$ghg$2@reader1.panix.com> |
| In reply to | #399635 |
In article <10vmtgc$3uus8$14@dont-email.me>, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >On 2026-06-02 17:19, Dan Cross wrote: >> In article <10vmna7$3uus8$13@dont-email.me>, >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >>> On 2026-06-02 15:05, Dan Cross wrote: >>>> [...] >>> >>> I suppose you have some tool to create those fancy graphics? >>> What are you using for that? - Or is that all hand-crafted? >> >> I used, "monodraw" on the Mac. I can't do that by hand; I am >> not artistically gifted. :-) > >What a pity that it's not available for Linux. Not related to C, but there are alternatives; `MonoSketch` looks similar. https://github.com/tuanchauict/MonoSketch AsciiFlow and ASCII Draw are also alternatives. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-06-02 21:33 +0000 |
| Subject | Re: [OT] Fancy graphics (was Re: this girl calls c ugly) |
| Message-ID | <B_HTR.9651$9P1.6865@fx36.iad> |
| In reply to | #399637 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: >In article <10vmtgc$3uus8$14@dont-email.me>, >Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >>On 2026-06-02 17:19, Dan Cross wrote: >>> In article <10vmna7$3uus8$13@dont-email.me>, >>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >>>> On 2026-06-02 15:05, Dan Cross wrote: >>>>> [...] >>>> >>>> I suppose you have some tool to create those fancy graphics? >>>> What are you using for that? - Or is that all hand-crafted? >>> >>> I used, "monodraw" on the Mac. I can't do that by hand; I am >>> not artistically gifted. :-) >> >>What a pity that it's not available for Linux. > >Not related to C, but there are alternatives; `MonoSketch` looks >similar. https://github.com/tuanchauict/MonoSketch > >AsciiFlow and ASCII Draw are also alternatives. > Conversation with google AI: Query: troff macros for flowcharts The AI responded with an example: .PS box "Start" arrow box "Read Data" arrow diamond "Valid?" arrow "Yes" right box "Process" arrow up move from last box .s to 0.5 below last diamond arrow from diamond to last position "No" arrow box "Stop" .PE Query: pic command complains aboue "Valid?" Answer: You are completely right. Standard pic will choke on diamond "Valid?" because diamond does not natively accept text string arguments the same way a box or circle does. It evaluates "Valid?" as an unexpected modifier. New example: .PS box "Start" arrow box "Read Data" arrow diamond # Clear the text string out of this line "Valid?" at last diamond arrow "Yes" right box "Process" arrow up move from last box .s to 0.5 below last diamond arrow from last diamond to last position "No" arrow box "Stop" .PE Query: PIC still complains about line 7 Answer: The issue is that standard pic parser grammar is very particular about relative positioning syntax. After several more subsequent failed attempts to create a valid PIC, I dug out my AT&T Documenter's Workbench User's Guide, and of course, there is no 'diamond' primitive. Query: pci does not have "diamond". Try again. Answer: You are completely correct, and I apologize for Hallucinating that keyword. pic does not have a diamond primitive. The primitive shapes are strictly limited to box, circle, ellipse, line, arrow, arc, and spline. So much for artifical intelligence built on scraping the web.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-06-02 14:43 -0700 |
| Subject | Re: [OT] Fancy graphics (was Re: this girl calls c ugly) |
| Message-ID | <10vnipk$37tjr$1@dont-email.me> |
| In reply to | #399645 |
On 6/2/2026 2:33 PM, Scott Lurndal wrote: > cross@spitfire.i.gajendra.net (Dan Cross) writes: >> In article <10vmtgc$3uus8$14@dont-email.me>, >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >>> On 2026-06-02 17:19, Dan Cross wrote: >>>> In article <10vmna7$3uus8$13@dont-email.me>, >>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >>>>> On 2026-06-02 15:05, Dan Cross wrote: >>>>>> [...] >>>>> >>>>> I suppose you have some tool to create those fancy graphics? >>>>> What are you using for that? - Or is that all hand-crafted? >>>> >>>> I used, "monodraw" on the Mac. I can't do that by hand; I am >>>> not artistically gifted. :-) >>> >>> What a pity that it's not available for Linux. >> >> Not related to C, but there are alternatives; `MonoSketch` looks >> similar. https://github.com/tuanchauict/MonoSketch >> >> AsciiFlow and ASCII Draw are also alternatives. >> > > Conversation with google AI: > > Query: troff macros for flowcharts > > The AI responded with an example: > > .PS > box "Start" > arrow > box "Read Data" > arrow > diamond "Valid?" > arrow "Yes" right > box "Process" > arrow up > move from last box .s to 0.5 below last diamond > arrow from diamond to last position "No" > arrow > box "Stop" > .PE > > Query: pic command complains aboue "Valid?" > > Answer: > You are completely right. Standard pic will choke on diamond > "Valid?" because diamond does not natively accept text string > arguments the same way a box or circle does. It evaluates > "Valid?" as an unexpected modifier. New example: > > .PS > box "Start" > arrow > box "Read Data" > arrow > diamond # Clear the text string out of this line > "Valid?" at last diamond > arrow "Yes" right > box "Process" > arrow up > move from last box .s to 0.5 below last diamond > arrow from last diamond to last position "No" > arrow > box "Stop" > .PE > > Query: PIC still complains about line 7 > > Answer: > > The issue is that standard pic parser grammar is very particular > about relative positioning syntax. > > > After several more subsequent failed attempts to create a valid PIC, > I dug out my AT&T Documenter's Workbench User's Guide, and > of course, there is no 'diamond' primitive. > > Query: pci does not have "diamond". Try again. > > Answer: > > You are completely correct, and I apologize for Hallucinating > that keyword. pic does not have a diamond primitive. The > primitive shapes are strictly limited to box, circle, ellipse, > line, arrow, arc, and spline. > > > So much for artifical intelligence built on scraping the web. Scary aspect... Somebody trusting the code it dumps out of its hind end... Runs it. Say its in a server loop... Oh my!
[toc] | [prev] | [next] | [standalone]
| From | ram@zedat.fu-berlin.de (Stefan Ram) |
|---|---|
| Date | 2026-06-02 17:08 +0000 |
| Subject | Re: [OT] Fancy graphics (was Re: this girl calls c ugly) |
| Message-ID | <ASCII-20260602180622@ram.dialup.fu-berlin.de> |
| In reply to | #399633 |
cross@spitfire.i.gajendra.net (Dan Cross) wrote or quoted:
>I used, "monodraw" on the Mac. I can't do that by hand; I am
>not artistically gifted. :-)
I have been searching for an ASCII-to-ASCII program for a long
time and never found anything impressive. I want to write
a /description/ of my diagram in ASCII and then want to get
my diagram as ASCII. Dot, ditaa, nothing worked.
The least bad solution I found so far is called /PlantUML/.
example.puml
@startuml
skinparam componentStyle rectangle
interface "SAX interface" as SAX_interface
interface "internal structure" as internal_structure
interface "internal HTML" as internal_HTML
interface "external HTML" as external_HTML
interface "external LaTeX" as external_LaTeX
Text --> [Parser]
[Parser] --> SAX_interface
SAX_interface --> [struct creator]
[struct creator] --> internal_structure
internal_structure --> [internal HTML transformer]
[internal HTML transformer] --> internal_HTML
internal_HTML --> [external HTML transformer]
[external HTML transformer] --> external_HTML
internal_structure --> [external LaTeX transformer]
[external LaTeX transformer] --> external_LaTeX
@enduml
example.cmd
set "GRAPHVIZ_DOT=C:\example\dot.exe"
"C:\example\java.exe" -jar "C:\example\plantuml.jar" -txt "example.puml"
output (not edited)
,----.
|Text|
|----|
`----'
|
|
,------.
|Parser|
|------|
`------'
|
,-------------.
|SAX interface|
|-------------|
`-------------'
|
,--------------.
|struct creator|
|--------------|
`--------------'
|
,------------------.
|internal structure|
|------------------|
`------------------'
,-------------------------. ,--------------------------.
|internal HTML transformer| |external LaTeX transformer|
|-------------------------| |--------------------------|
`-------------------------' `--------------------------'
| |
| |
,-------------. ,--------------.
|internal HTML| |external LaTeX|
|-------------| |--------------|
`-------------' `--------------'
|
,-------------------------.
|external HTML transformer|
|-------------------------|
`-------------------------'
|
,-------------.
|external HTML|
|-------------|
`-------------'
This is nothing impressive, but I am not aware of any other
program that can do this! You can then tweak it manually
if you've got the time:
.------.
(Markdown)
'------'
|
V
.------.
|Parser|
'------'
|
V
.-----------.
(SAX interface)
'-----------'
|
V
.--------------.
|struct creator|
'--------------'
|
V
.----------------.
(internal structure)
'----------------'
.--------------'--------------.
V V
.-------------------------. .--------------------------.
|internal HTML transformer| |external LaTeX transformer|
'-------------------------' '--------------------------'
| |
V V
.-----------. .------------.
(internal HTML) (external LaTeX)
'-----------' '------------'
|
V
.-------------------------.
|external HTML transformer|
'-------------------------'
|
V
.-----------.
(external HTML)
'-----------'
But at least PlantUML did some kind of minimal routing for you.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-02 19:19 +0000 |
| Subject | Re: [OT] Fancy graphics (was Re: this girl calls c ugly) |
| Message-ID | <10vnab9$jqo$1@reader1.panix.com> |
| In reply to | #399639 |
[This is _really_ off-topic now. Follow-up: comp.text] In article <ASCII-20260602180622@ram.dialup.fu-berlin.de>, Stefan Ram <ram@zedat.fu-berlin.de> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) wrote or quoted: >>I used, "monodraw" on the Mac. I can't do that by hand; I am >>not artistically gifted. :-) > > I have been searching for an ASCII-to-ASCII program for a long > time and never found anything impressive. I want to write > a /description/ of my diagram in ASCII and then want to get > my diagram as ASCII. Dot, ditaa, nothing worked. > > The least bad solution I found so far is called /PlantUML/. Personally, I rather like `pic` and `nroff`. Your mileage may vary, however, depending on the complexity of the diagram. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-02 15:39 -0700 |
| Subject | Re: [OT] Fancy graphics (was Re: this girl calls c ugly) |
| Message-ID | <10vnm2m$382un$3@kst.eternal-september.org> |
| In reply to | #399633 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <10vmna7$3uus8$13@dont-email.me>,
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>On 2026-06-02 15:05, Dan Cross wrote:
>>> [...]
>>>
>>> ┌──────â”
>>> │ expr │
>>> └──────┘
>>> ╱ │ ╲
>>> ╱ │ ╲
[...]
>>
>>I suppose you have some tool to create those fancy graphics?
>>What are you using for that? - Or is that all hand-crafted?
>
> I used, "monodraw" on the Mac. I can't do that by hand; I am
> not artistically gifted. :-)
For whatever reason, I'm seeing your drawings as gibberish
in articles you post, but as nicely formatted drawings when
they're quoted in replies by others.
https://en.wikipedia.org/wiki/Mojibake
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-03 13:14 +0000 |
| Subject | Re: [OT] Fancy graphics (was Re: this girl calls c ugly) |
| Message-ID | <10vp9cd$frf$1@reader1.panix.com> |
| In reply to | #399654 |
In article <10vnm2m$382un$3@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >> In article <10vmna7$3uus8$13@dont-email.me>, >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >>>On 2026-06-02 15:05, Dan Cross wrote: >>>> [...] >>>> >>>> ┌──────┠>>>> │ expr │ >>>> └──────┘ >>>> ╱ │ ╲ >>>> ╱ │ ╲ >[...] >>> >>>I suppose you have some tool to create those fancy graphics? >>>What are you using for that? - Or is that all hand-crafted? >> >> I used, "monodraw" on the Mac. I can't do that by hand; I am >> not artistically gifted. :-) > >For whatever reason, I'm seeing your drawings as gibberish >in articles you post, but as nicely formatted drawings when >they're quoted in replies by others. > >https://en.wikipedia.org/wiki/Mojibake Thanks. I customize things to add the appropriate headers. - Dan C.
[toc] | [prev] | [next] | [standalone]
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web