Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #397418 > unrolled thread
| Started by | DFS <nospam@dfs.com> |
|---|---|
| First post | 2026-04-07 23:14 -0400 |
| Last post | 2026-04-28 13:01 +0000 |
| Articles | 20 on this page of 141 — 19 participants |
Back to article view | Back to comp.lang.c
Small challenge: sort names DFS <nospam@dfs.com> - 2026-04-07 23:14 -0400
Re: Small challenge: sort names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-08 10:22 +0200
Re: Small challenge: sort names DFS <nospam@dfs.com> - 2026-04-08 12:25 -0400
Re: Small challenge: sort names Bart <bc@freeuk.com> - 2026-04-08 18:57 +0100
Re: Small challenge: sort names scott@slp53.sl.home (Scott Lurndal) - 2026-04-08 21:04 +0000
Re: Small challenge: sort names Michael S <already5chosen@yahoo.com> - 2026-04-09 00:10 +0300
Re: Small challenge: sort names scott@slp53.sl.home (Scott Lurndal) - 2026-04-08 23:35 +0000
Re: Small challenge: sort names Michael S <already5chosen@yahoo.com> - 2026-04-09 02:59 +0300
Re: Small challenge: sort names James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-09 06:29 -0400
Re: Small challenge: sort names cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-09 15:15 +0000
Re: Small challenge: sort names Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-11 08:49 -0700
Re: Small challenge: sort names cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-11 19:59 +0000
Re: Small challenge: sort names Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-16 18:50 +0200
Re: Small challenge: sort names cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-16 19:54 +0000
Re: Small challenge: sort names Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-17 16:22 +0200
Re: Small challenge: sort names Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-08 17:27 -0700
Re: Small challenge: sort names Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-08 22:14 -0700
Re: Small challenge: sort names Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-09 02:19 -0700
Re: Small challenge: sort names scott@slp53.sl.home (Scott Lurndal) - 2026-04-09 15:06 +0000
Re: Small challenge: sort names Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-12 06:35 -0700
Re: Small challenge: sort names scott@slp53.sl.home (Scott Lurndal) - 2026-04-12 14:51 +0000
Re: Small challenge: sort names Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-13 06:31 -0700
Re: Small challenge: sort names Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-12 06:48 -0700
Re: Small challenge: sort names Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-12 16:15 -0700
Re: Small challenge: sort names Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-25 13:31 -0700
Re: Small challenge: sort names Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 15:12 -0700
Re: Small challenge: sort names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-26 04:13 +0200
Re: Small challenge: sort names Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-25 19:50 -0700
Re: Small challenge: sort names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-26 05:28 +0200
Re: Small challenge: sort names David Brown <david.brown@hesbynett.no> - 2026-04-26 12:08 +0200
Re: Small challenge: sort names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-26 18:16 +0200
Re: Small challenge: sort names David Brown <david.brown@hesbynett.no> - 2026-04-26 19:37 +0200
Re: Small challenge: sort names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-27 02:17 +0200
Re: Small challenge: sort names David Brown <david.brown@hesbynett.no> - 2026-04-27 09:19 +0200
Re: Small challenge: sort names scott@slp53.sl.home (Scott Lurndal) - 2026-04-26 17:47 +0000
Re: Small challenge: sort names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-27 02:33 +0200
Re: Small challenge: sort names David Brown <david.brown@hesbynett.no> - 2026-04-27 09:34 +0200
Re: Small challenge: sort names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-27 12:35 +0200
Re: Small challenge: sort names Bart <bc@freeuk.com> - 2026-04-27 13:28 +0100
Re: Small challenge: sort names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-27 17:02 +0200
Re: Small challenge: sort names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-27 17:36 +0200
Re: Small challenge: sort names scott@slp53.sl.home (Scott Lurndal) - 2026-04-27 16:18 +0000
Re: Small challenge: sort names Michael S <already5chosen@yahoo.com> - 2026-04-27 11:42 +0300
Re: Small challenge: sort names scott@slp53.sl.home (Scott Lurndal) - 2026-04-27 16:27 +0000
Assembler verb choice (Was: Small challenge: sort names) gazelle@shell.xmission.com (Kenny McCormack) - 2026-04-28 12:59 +0000
Re: Assembler verb choice (Was: Small challenge: sort names) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-28 16:26 +0200
Re: Small challenge: sort names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-27 12:45 -0700
Re: Small challenge: sort names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-27 12:42 -0700
Re: Small challenge: sort names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-27 12:43 -0700
Re: Small challenge: sort names Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-27 12:59 -0700
Re: Small challenge: sort names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-27 13:26 -0700
Re: Small challenge: sort names cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-27 20:43 +0000
Re: Small challenge: sort names "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-27 17:30 -0700
Re: Small challenge: sort names Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-27 19:15 -0700
Re: Small challenge: sort names gazelle@shell.xmission.com (Kenny McCormack) - 2026-04-28 12:01 +0000
Re: Small challenge: sort names David Brown <david.brown@hesbynett.no> - 2026-04-28 08:35 +0200
Re: Small challenge: sort names cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-28 13:27 +0000
Re: Small challenge: sort names David Brown <david.brown@hesbynett.no> - 2026-04-28 15:59 +0200
Re: Small challenge: sort names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-28 16:49 +0200
Re: Small challenge: sort names David Brown <david.brown@hesbynett.no> - 2026-04-28 17:25 +0200
Re: Small challenge: sort names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-28 23:46 +0200
Re: Small challenge: sort names cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-28 18:12 +0000
Re: Small challenge: sort names David Brown <david.brown@hesbynett.no> - 2026-04-28 20:28 +0200
Re: Small challenge: sort names vallor <vallor@vallor.earth> - 2026-04-28 13:45 +0000
Re: Small challenge: sort names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-11 08:44 +0200
Re: Small challenge: sort names DFS <nospam@dfs.com> - 2026-04-08 17:13 -0400
Re: Small challenge: sort names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-11 08:59 +0200
Re: Small challenge: sort names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-11 09:34 +0200
Re: Small challenge: sort names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-11 08:31 +0200
Re: Small challenge: sort names vallor <vallor@vallor.earth> - 2026-04-28 14:19 +0000
Re: Small challenge: sort names BGB <cr88192@gmail.com> - 2026-04-12 13:08 -0500
What is the point of anything? (Was: Small challenge: sort names) gazelle@shell.xmission.com (Kenny McCormack) - 2026-04-17 20:44 +0000
Re: Small challenge: sort names Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-08 18:46 -0700
Re: Small challenge: sort names Sort <Sort@invalid.invalid> - 2026-04-11 19:15 +0100
Re: Small challenge: sort names Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-16 18:24 +0200
Re: Small challenge: sort names Bart <bc@freeuk.com> - 2026-04-16 18:38 +0100
Re: Small challenge: sort names Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-16 19:43 +0200
Re: Small challenge: sort names Bart <bc@freeuk.com> - 2026-04-18 11:22 +0100
Re: Small challenge: sort names Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-18 17:48 +0200
Re: Small challenge: sort names Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-19 08:44 +0200
Re: Small challenge: sort names DFS <nospam@dfs.com> - 2026-04-22 05:33 -0400
Re: Small challenge: sort names Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-22 03:16 -0700
Re: Small challenge: sort names DFS <nospam@dfs.com> - 2026-04-22 07:35 -0400
Re: Small challenge: sort names Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-23 08:11 -0700
Re: Small challenge: sort names Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-23 20:14 +0200
Re: Small challenge: sort names gazelle@shell.xmission.com (Kenny McCormack) - 2026-04-23 18:30 +0000
Re: Small challenge: sort names gazelle@shell.xmission.com (Kenny McCormack) - 2026-04-23 17:19 +0000
Re: Small challenge: sort names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-22 14:11 +0200
Re: Small challenge: sort names James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-22 21:27 -0400
[OT][meta] Gender (was Re: Small challenge: sort names) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-23 15:51 +0200
Re: [OT][meta] Gender (was Re: Small challenge: sort names) scott@slp53.sl.home (Scott Lurndal) - 2026-04-23 14:45 +0000
Re: [OT][meta] Gender (was Re: Small challenge: sort names) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-23 17:03 +0200
Re: [OT][meta] Gender (was Re: Small challenge: sort names) DFS <nospam@dfs.com> - 2026-04-23 20:31 -0400
Re: [OT][meta] Gender (was Re: Small challenge: sort names) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 18:43 -0700
Re: [OT][meta] Gender (was Re: Small challenge: sort names) gazelle@shell.xmission.com (Kenny McCormack) - 2026-04-24 16:58 +0000
Re: [OT][meta] Gender (was Re: Small challenge: sort names) Jan van den Broek <balglaas@dds.nl> - 2026-04-24 06:57 +0000
Re: [OT][meta] Gender (was Re: Small challenge: sort names) Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-24 10:10 +0200
Re: [OT][meta] Gender (was Re: Small challenge: sort names) David Brown <david.brown@hesbynett.no> - 2026-04-24 12:52 +0200
Re: [OT][meta] Gender (was Re: Small challenge: sort names) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 16:36 -0700
Re: [OT][meta] Gender (was Re: Small challenge: sort names) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-24 03:01 +0200
Re: [OT][meta] Gender (was Re: Small challenge: sort names) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-23 18:50 -0700
Re: [OT][meta] Gender (was Re: Small challenge: sort names) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-24 20:35 -0700
Re: [OT][meta] Gender (was Re: Small challenge: sort names) Michael S <already5chosen@yahoo.com> - 2026-04-24 14:20 +0300
Re: [OT][meta] Gender (was Re: Small challenge: sort names) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-24 14:32 +0200
Re: Small challenge: sort names Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-23 20:10 +0200
Re: Small challenge: sort names DFS <nospam@dfs.com> - 2026-04-25 10:26 -0400
Re: Small challenge: sort names Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-26 13:01 +0200
Re: Small challenge: sort names Rosario19 <Ros@invalid.invalid> - 2026-04-18 11:16 +0200
Re: Small challenge: sort names DFS <nospam@dfs.com> - 2026-04-18 08:11 -0400
Re: Small challenge: sort names Bart <bc@freeuk.com> - 2026-04-18 14:03 +0100
Re: Small challenge: sort names Rosario19 <Ros@invalid.invalid> - 2026-04-20 21:20 +0200
Re: Small challenge: sort names DFS <nospam@dfs.com> - 2026-04-20 16:43 -0400
Re: Small challenge: sort names Rosario19 <Ros@invalid.invalid> - 2026-04-21 05:09 +0200
Re: Small challenge: sort names DFS <nospam@dfs.com> - 2026-04-21 08:46 -0400
Re: Small challenge: sort names Bart <bc@freeuk.com> - 2026-04-21 16:08 +0100
Re: Small challenge: sort names DFS <nospam@dfs.com> - 2026-04-21 11:33 -0400
Re: Small challenge: sort names Bart <bc@freeuk.com> - 2026-04-21 18:25 +0100
Re: Small challenge: sort names scott@slp53.sl.home (Scott Lurndal) - 2026-04-21 17:38 +0000
Re: Small challenge: sort names Michael S <already5chosen@yahoo.com> - 2026-04-21 20:50 +0300
Re: Small challenge: sort names scott@slp53.sl.home (Scott Lurndal) - 2026-04-21 18:22 +0000
Re: Small challenge: sort names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-22 03:48 +0200
Re: Small challenge: sort names David Brown <david.brown@hesbynett.no> - 2026-04-22 09:18 +0200
Re: Small challenge: sort names Michael S <already5chosen@yahoo.com> - 2026-04-22 13:22 +0300
Re: Small challenge: sort names David Brown <david.brown@hesbynett.no> - 2026-04-22 12:38 +0200
Re: Small challenge: sort names Michael S <already5chosen@yahoo.com> - 2026-04-22 13:58 +0300
Re: Small challenge: sort names David Brown <david.brown@hesbynett.no> - 2026-04-22 13:13 +0200
Re: Small challenge: sort names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-22 14:53 +0200
Re: Small challenge: sort names DFS <nospam@dfs.com> - 2026-04-21 16:31 -0400
Re: Small challenge: sort names Bart <bc@freeuk.com> - 2026-04-21 23:04 +0100
Re: Small challenge: sort names Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-20 14:16 -0700
An audience of one (Was: Small challenge: sort names) gazelle@shell.xmission.com (Kenny McCormack) - 2026-04-21 13:00 +0000
Re: An audience of one (Was: Small challenge: sort names) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-04-21 12:21 -0700
Re: Small challenge: sort names Rosario19 <Ros@invalid.invalid> - 2026-04-21 05:00 +0200
Re: Small challenge: sort names Rosario19 <Ros@invalid.invalid> - 2026-04-21 05:06 +0200
Re: Small challenge: sort names gggggggggggunit <gunitinug@50cent.com> - 2026-04-18 10:19 +0000
[OT] Shell approach to Re: Small challenge: sort names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-19 09:35 +0200
Re: [OT] Shell approach to Re: Small challenge: sort names gazelle@shell.xmission.com (Kenny McCormack) - 2026-04-19 14:18 +0000
Re: [OT] Shell approach to Re: Small challenge: sort names cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-19 19:32 +0000
Re: [OT] Shell approach to Re: Small challenge: sort names Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-04-22 03:34 +0200
Re: Small challenge: sort names Bonita Montero <Bonita.Montero@gmail.com> - 2026-04-28 06:53 +0200
Re: Small challenge: sort names gazelle@shell.xmission.com (Kenny McCormack) - 2026-04-28 13:01 +0000
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-04-12 14:51 +0000 |
| Message-ID | <6kOCR.135369$rGx6.58407@fx24.iad> |
| In reply to | #397503 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >scott@slp53.sl.home (Scott Lurndal) writes: > >> Or even obsolete. The systems in question were all retired by >> 2010, and never had a C compiler. The system was BCD and the >> six digit 'undigit' value of EEEEEE was chosen as the NIL (NULL) >> pointer value. > >It would be nice if in the future it were stated directly when a >non-C environment is the context of a comment. I mistakenly >understood that what you were saying had to do with experience >using some unusual C compiler. I was in the OS group at the time. The languages group had started looking at writing a C compiler for the architecture, but it never panned out (and there was little interest from the predominantly COBOL customer base).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-04-13 06:31 -0700 |
| Message-ID | <86zf376l7v.fsf@linuxsc.com> |
| In reply to | #397507 |
scott@slp53.sl.home (Scott Lurndal) writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> scott@slp53.sl.home (Scott Lurndal) writes: >> >>> Or even obsolete. The systems in question were all retired by >>> 2010, and never had a C compiler. The system was BCD and the >>> six digit 'undigit' value of EEEEEE was chosen as the NIL (NULL) >>> pointer value. >> >> It would be nice if in the future it were stated directly when a >> non-C environment is the context of a comment. I mistakenly >> understood that what you were saying had to do with experience >> using some unusual C compiler. > > I was in the OS group at the time. The languages group had > started looking at writing a C compiler for the architecture, but > it never panned out (and there was little interest from the > predominantly COBOL customer base). I'm sure there was a good reason for working in the development environment you were using, and I didn't mean to imply otherwise. I just wanted a heads-up about the non-C-ness of it.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-04-12 06:48 -0700 |
| Message-ID | <86o6jo8f30.fsf@linuxsc.com> |
| In reply to | #397446 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > [...] > >> The semantics of !ptr has been codified to mean 1 for null pointers >> since the original C standard. Heck, even during the 1970s when C >> allowed assigning integers directly to pointers, K&R said that >> assigning 0 to a pointer produces a pointer guaranteed to be >> different than a pointer to any object. Any C implementation where >> !ptr does the wrong thing should be avoided like the plague. > > Any C implementation where !ptr does the wrong thing almost certainly > does not exist. It's difficult to imagine that a C compiler with > such a fundamental bug would ever go out the door. My usual preference is to draw conclusions based on evidence rather imagination or supposition. > It's barely possible that compiler that uses a representation other > than all-bits-zero for null pointers might have such a bug, but > (a) anyone creating such an implementation will almost certainly > be extremely careful to get such things right, and (b) I'm not sure > that any such compilers even exist, except perhaps for old systems > that would be considered exotic today. Here again this sounds like just supposition. How much experience do you have, and how extensive, using non-mainstream C compilers? For myself I can't say I much at all, but I have seen one where believe it or not assert() was implemented wrongly. assert()! I certainly wouldn't have guessed that before actually seeing it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-12 16:15 -0700 |
| Message-ID | <878qar3h3x.fsf@example.invalid> |
| In reply to | #397504 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> [...]
>>
>>> The semantics of !ptr has been codified to mean 1 for null pointers
>>> since the original C standard. Heck, even during the 1970s when C
>>> allowed assigning integers directly to pointers, K&R said that
>>> assigning 0 to a pointer produces a pointer guaranteed to be
>>> different than a pointer to any object. Any C implementation where
>>> !ptr does the wrong thing should be avoided like the plague.
>>
>> Any C implementation where !ptr does the wrong thing almost certainly
>> does not exist. It's difficult to imagine that a C compiler with
>> such a fundamental bug would ever go out the door.
>
> My usual preference is to draw conclusions based on evidence rather
> imagination or supposition.
Good for you.
>> It's barely possible that compiler that uses a representation other
>> than all-bits-zero for null pointers might have such a bug, but
>> (a) anyone creating such an implementation will almost certainly
>> be extremely careful to get such things right, and (b) I'm not sure
>> that any such compilers even exist, except perhaps for old systems
>> that would be considered exotic today.
>
> Here again this sounds like just supposition. How much experience
> do you have, and how extensive, using non-mainstream C compilers?
> For myself I can't say I much at all, but I have seen one where
> believe it or not assert() was implemented wrongly. assert()! I
> certainly wouldn't have guessed that before actually seeing it.
Quick summary: You wrote that "Any C implementation where !ptr does
the wrong thing should be avoided like the plague." My response
was, to summarize briefly, that such implementations are unlikely
to exist and not worth worrying about.
Do you disagree, or are you just criticizing the way I said it?
I believe I was clear about the basis for my statement. No, I don't
have a lot of experience with non-mainstream C compilers. I'm not
going to perform a survey of all historical C implementations.
Do you have anything useful to say about my point, as opposed to
how I expressed it?
I speculate that no released C implementation gets either !ptr or
2+2 wrong. A bug in the former is, I speculate, more likely than a
bug in the latter, but neither seems likely. If such a bug exists,
my guess is that it's in a pre-standard compiler for some system
that is now obsolete. K&R1 (1978) is less than clear about the
representation of null pointers.
Would you be surprised to see a C compiler that handles !ptr
incorrectly?
I'd be interested in more information about the implementation
that implemented assert() incorrectly.
--
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-04-25 13:31 -0700 |
| Message-ID | <86se8i3hoq.fsf@linuxsc.com> |
| In reply to | #397514 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> [...] >>> >>>> The semantics of !ptr has been codified to mean 1 for null pointers >>>> since the original C standard. Heck, even during the 1970s when C >>>> allowed assigning integers directly to pointers, K&R said that >>>> assigning 0 to a pointer produces a pointer guaranteed to be >>>> different than a pointer to any object. Any C implementation where >>>> !ptr does the wrong thing should be avoided like the plague. >>> >>> Any C implementation where !ptr does the wrong thing almost certainly >>> does not exist. It's difficult to imagine that a C compiler with >>> such a fundamental bug would ever go out the door. >> >> My usual preference is to draw conclusions based on evidence rather >> imagination or supposition. > > Good for you. > >>> It's barely possible that compiler that uses a representation other >>> than all-bits-zero for null pointers might have such a bug, but >>> (a) anyone creating such an implementation will almost certainly >>> be extremely careful to get such things right, and (b) I'm not sure >>> that any such compilers even exist, except perhaps for old systems >>> that would be considered exotic today. >> >> Here again this sounds like just supposition. How much experience >> do you have, and how extensive, using non-mainstream C compilers? >> For myself I can't say I much at all, but I have seen one where >> believe it or not assert() was implemented wrongly. assert()! I >> certainly wouldn't have guessed that before actually seeing it. > > Quick summary: You wrote that "Any C implementation where !ptr does > the wrong thing should be avoided like the plague." My response > was, to summarize briefly, that such implementations are unlikely > to exist and not worth worrying about. You said "Any C implementation where !ptr does the wrong thing almost certainly does not exist." > Do you disagree, or are you just criticizing the way I said it? I was simply drawing attention to the circumstance of your having made a statement of fact without offering any facts to support it. > I believe I was clear about the basis for my statement. No, I don't > have a lot of experience with non-mainstream C compilers. I'm not > going to perform a survey of all historical C implementations. > > Do you have anything useful to say about my point, as opposed to > how I expressed it? As far as I can tell your point is that you don't mind offering unsupported allegations as facts. In my opinion it is useful to have that attitude pointed out.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-25 15:12 -0700 |
| Message-ID | <10sje8n$1668o$1@kst.eternal-september.org> |
| In reply to | #397944 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>> [...]
>>>>> The semantics of !ptr has been codified to mean 1 for null pointers
>>>>> since the original C standard. Heck, even during the 1970s when C
>>>>> allowed assigning integers directly to pointers, K&R said that
>>>>> assigning 0 to a pointer produces a pointer guaranteed to be
>>>>> different than a pointer to any object. Any C implementation where
>>>>> !ptr does the wrong thing should be avoided like the plague.
>>>>
>>>> Any C implementation where !ptr does the wrong thing almost certainly
>>>> does not exist. It's difficult to imagine that a C compiler with
>>>> such a fundamental bug would ever go out the door.
>>>
>>> My usual preference is to draw conclusions based on evidence rather
>>> imagination or supposition.
>>
>> Good for you.
>>
>>>> It's barely possible that compiler that uses a representation other
>>>> than all-bits-zero for null pointers might have such a bug, but
>>>> (a) anyone creating such an implementation will almost certainly
>>>> be extremely careful to get such things right, and (b) I'm not sure
>>>> that any such compilers even exist, except perhaps for old systems
>>>> that would be considered exotic today.
>>>
>>> Here again this sounds like just supposition. How much experience
>>> do you have, and how extensive, using non-mainstream C compilers?
>>> For myself I can't say I much at all, but I have seen one where
>>> believe it or not assert() was implemented wrongly. assert()! I
>>> certainly wouldn't have guessed that before actually seeing it.
>>
>> Quick summary: You wrote that "Any C implementation where !ptr does
>> the wrong thing should be avoided like the plague." My response
>> was, to summarize briefly, that such implementations are unlikely
>> to exist and not worth worrying about.
>
> You said "Any C implementation where !ptr does the wrong thing
> almost certainly does not exist."
>
>> Do you disagree, or are you just criticizing the way I said it?
>
> I was simply drawing attention to the circumstance of your having
> made a statement of fact without offering any facts to support it.
>
>> I believe I was clear about the basis for my statement. No, I don't
>> have a lot of experience with non-mainstream C compilers. I'm not
>> going to perform a survey of all historical C implementations.
>>
>> Do you have anything useful to say about my point, as opposed to
>> how I expressed it?
>
> As far as I can tell your point is that you don't mind offering
> unsupported allegations as facts. In my opinion it is useful
> to have that attitude pointed out.
So you have nothing to say about whether the statement itself is
true or not.
Yes, my statements were "just supposition".
I don't generally feel the need to point out when I'm making a
speculative statement. It was obvious enough to you, and I presume
to everyone else, that I was speculating. I wouldn't expect anyone
here to assume that my statement was based on an exhaustive survey
of all existing C compilers. And I thought that the phrases "almost
certainly" and "difficult to imagine" were enough to make it clear
that I wasn't making an absolute statement of fact.
Someone with actual information could even have used my speculation
as an opportunity to provide some solid information, for example
citing a real compiler that miscompiles !ptr (or, less likely,
a study covering all C compilers demonstrating that none do so).
In my opinion, the possibility of !ptr being compiled incorrectly
is not worth worrying about when writing C code. I would no more
worry about !ptr not yielding 0 for a non-null ptr or 1 for a null
ptr than I would worry about 2+2 not yielding 4. And your concern
is not with whether I'm right, but with how I stated it.
I could point out some things about your attitude, but I don't
think it would be useful to do so.
--
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 | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-04-26 04:13 +0200 |
| Message-ID | <10sjscs$3knhv$1@dont-email.me> |
| In reply to | #397949 |
On 2026-04-26 00:12, Keith Thompson wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >> You said "Any C implementation where !ptr does the wrong thing >> almost certainly does not exist." >> >>> Do you disagree, or are you just criticizing the way I said it? >> >> I was simply drawing attention to the circumstance of your having >> made a statement of fact without offering any facts to support it. >> >>> I believe I was clear about the basis for my statement. No, I don't >>> have a lot of experience with non-mainstream C compilers. I'm not >>> going to perform a survey of all historical C implementations. >>> >>> Do you have anything useful to say about my point, as opposed to >>> how I expressed it? >> >> As far as I can tell your point is that you don't mind offering >> unsupported allegations as facts. In my opinion it is useful >> to have that attitude pointed out. > > So you have nothing to say about whether the statement itself is > true or not. > > Yes, my statements were "just supposition". Actually, from my limited (mostly old K&R) perspective, I usually see in these examples comparisons against '\0' formulated, I would infer, given that it's stated that '\0' is actually an integer 0, and integers were also standard boolean values, that you can omit it (in these examples and the ones I think we had been discussing, concerning 'char *'). This is probably a bit informal, maybe also outdated, but at least some pointer (pun unintended) why '*ptr' is (commonly?) used as predicate without that we heard about problems with that. - Or are there other observations? For more general cases it's at least stated that assignments of 0 to pointers is (generally) creating the special null-pointer, but the opposite I cannot find, I don't see a bijective relation. Beyond spreading doubt, getting personal, or doing meta-talk; are there any formal reasons to not write 'if (*ptr)' ? - I'm curious. Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-25 19:50 -0700 |
| Message-ID | <10sjuh7$19c5j$6@kst.eternal-september.org> |
| In reply to | #397973 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-04-26 00:12, Keith Thompson wrote:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> You said "Any C implementation where !ptr does the wrong thing
>>> almost certainly does not exist."
>>>
>>>> Do you disagree, or are you just criticizing the way I said it?
>>>
>>> I was simply drawing attention to the circumstance of your having
>>> made a statement of fact without offering any facts to support it.
>>>
>>>> I believe I was clear about the basis for my statement. No, I don't
>>>> have a lot of experience with non-mainstream C compilers. I'm not
>>>> going to perform a survey of all historical C implementations.
>>>>
>>>> Do you have anything useful to say about my point, as opposed to
>>>> how I expressed it?
>>>
>>> As far as I can tell your point is that you don't mind offering
>>> unsupported allegations as facts. In my opinion it is useful
>>> to have that attitude pointed out.
>> So you have nothing to say about whether the statement itself is
>> true or not.
>> Yes, my statements were "just supposition".
>
> Actually, from my limited (mostly old K&R) perspective, I usually
> see in these examples comparisons against '\0' formulated, I would
> infer, given that it's stated that '\0' is actually an integer 0,
> and integers were also standard boolean values, that you can omit
> it (in these examples and the ones I think we had been discussing,
> concerning 'char *'). This is probably a bit informal, maybe also
> outdated, but at least some pointer (pun unintended) why '*ptr' is
> (commonly?) used as predicate without that we heard about problems
> with that. - Or are there other observations?
'\0' and 0 are both integer constant expressions of type int with
the value zero. I can't think of any circumstances in which they're
not interchangeable. (The fact that an unprefixed character constant
is of type int is a bit of an oddity; in C++, for example, it's of
type char.)
Which one I use depends on what I consider to be clearer to the
human reader in the given context.
> For more general cases it's at least stated that assignments of 0
> to pointers is (generally) creating the special null-pointer, but
> the opposite I cannot find, I don't see a bijective relation.
Right, a conversion of a pointer value to an integer type is not
guaranteed to yield zero, even if the pointer is a null pointer. (I
speculate that it does yield zero in all existing implementations.)
> Beyond spreading doubt, getting personal, or doing meta-talk; are
> there any formal reasons to not write 'if (*ptr)' ? - I'm curious.
I'm not sure how your reply relates to the parent posts. I was
talking about the semantics of !ptr, applying the unary ! operator
to a pointer value, particularly for an implementation that uses
a non-zero representation for null pointers. It yields a result
of type int, with the value 1 if ptr holds a null pointer value,
0 otherwise (assuming no undefined behavior).
You mention `if (*ptr)`. If ptr is of type char*, and its
value is known to be non-null, I'd probably write the equivalent
`if (*ptr != '\0')`, but that's a matter of style, not of semantics,
and a completely different issue.
--
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 | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-04-26 05:28 +0200 |
| Message-ID | <10sk0o4$3knhv$4@dont-email.me> |
| In reply to | #397976 |
On 2026-04-26 04:50, Keith Thompson wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > >> [...]; are >> there any formal reasons to not write 'if (*ptr)' ? - I'm curious. [....] are there any formal reasons to not write 'if (!ptr)' ? > I'm not sure how your reply relates to the parent posts. I was > talking about the semantics of !ptr, applying the unary ! operator > to a pointer value, particularly for an implementation that uses > a non-zero representation for null pointers. It yields a result > of type int, with the value 1 if ptr holds a null pointer value, > 0 otherwise (assuming no undefined behavior). Sorry for the confusion. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-26 12:08 +0200 |
| Message-ID | <10sko63$1gg7p$1@dont-email.me> |
| In reply to | #397981 |
On 26/04/2026 05:28, Janis Papanagnou wrote: > On 2026-04-26 04:50, Keith Thompson wrote: >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> >>> [...]; are >>> there any formal reasons to not write 'if (*ptr)' ? - I'm curious. > > [....] are there any formal reasons to not write 'if (!ptr)' ? > I can't answer for pre-standard C, but in the C standards, "if (!ptr)" means exactly the same as "if (ptr == 0)" from the way the operations ! and == are defined, and the way 0 as a null pointer is defined. Is it conceivable that there are compilers with bugs or non-conformities that treat these differently? If have seen a view very buggy and/or very non-conforming or function-limited compilers in my time (including a few big name, expensive toolchains), but a failure here would surprise me greatly. There is no real limit to the type of bugs a compiler could have, but a compiler that fails to get this right is unlikely to be usable in practice. It is plausible that a weaker or non-optimising compiler could generate different code for the two conditionals, one of which is more efficient than the other. Again, I've seen some pretty weak compilers over the years, where you need to fine-tune the source code if you want efficient object code. Mostly comes down to preferences - personal, or set by some coding standards. Do you think the code is clearer to human readers if it is written as "if (!ptr)", "if (ptr == 0)", or perhaps "if (0 == ptr)" - some people feel "Yoda conditionals" are safer.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-04-26 18:16 +0200 |
| Message-ID | <10sldpd$3kni0$4@dont-email.me> |
| In reply to | #397984 |
On 2026-04-26 12:08, David Brown wrote:
> On 26/04/2026 05:28, Janis Papanagnou wrote:
>>
>> [....] are there any formal reasons to not write 'if (!ptr)' ?
>
> I can't answer for pre-standard C, but in the C standards, "if (!ptr)"
> means exactly the same as "if (ptr == 0)" from the way the operations !
> and == are defined, and the way 0 as a null pointer is defined.
>
> Is it conceivable that there are compilers with bugs or non-conformities
> that treat these differently? If have seen a view very buggy and/or
> very non-conforming or function-limited compilers in my time (including
> a few big name, expensive toolchains), but a failure here would surprise
> me greatly. There is no real limit to the type of bugs a compiler could
> have, but a compiler that fails to get this right is unlikely to be
> usable in practice.
>
> It is plausible that a weaker or non-optimising compiler could generate
> different code for the two conditionals, one of which is more efficient
> than the other. Again, I've seen some pretty weak compilers over the
> years, where you need to fine-tune the source code if you want efficient
> object code.
>
> Mostly comes down to preferences - personal, or set by some coding
> standards. Do you think the code is clearer to human readers if it is
> written as "if (!ptr)", "if (ptr == 0)", or perhaps "if (0 == ptr)" -
> some people feel "Yoda conditionals" are safer.
Well, preferences vary, sure, and so we don't need to discuss
these in depth. But since you asked, here's my opinion on that.
First, the latter I consider to be "unreadable" nonsense based
on a false understanding of safety.[*]
For the former two (for me) it depends on the context; has the
expression a boolean characteristic or not? If so I often prefer
the former. As example;
if ((fd = fopen ("file", "r")) != NULL)
if ((fd = fopen ("file", "r")) != 0)
if (fd = fopen ("file", "r"))
I'd clearly choose the latter. (And even with local semantics for
the 'fd' variable where available[**]
if (FILE * fd = fopen ("file", "r"))
Janis
[*] Often it's an asymmetric comparison where natural languages
would formulate "is/has item this value" (or similar), and the
reverse formulation is counter-intuitive (in that respect). And
concerning "safety"; if one has to learn that the reverse form
is the "safe" form then he could instead also just learn that in
"C" the comparison is '==' and not '='. (In other languages we
might have support for alternative forms; in OO maybe 'fd.isopen',
also an asymmetric relation.)
[**] Don't newer versions of "C" support that (or do I confuse it
with contemporary C++ versions)?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-26 19:37 +0200 |
| Message-ID | <10sligh$1oce0$1@dont-email.me> |
| In reply to | #397999 |
On 26/04/2026 18:16, Janis Papanagnou wrote:
> On 2026-04-26 12:08, David Brown wrote:
>> On 26/04/2026 05:28, Janis Papanagnou wrote:
>>>
>>> [....] are there any formal reasons to not write 'if (!ptr)' ?
>>
>> I can't answer for pre-standard C, but in the C standards, "if (!ptr)"
>> means exactly the same as "if (ptr == 0)" from the way the
>> operations ! and == are defined, and the way 0 as a null pointer is
>> defined.
>>
>> Is it conceivable that there are compilers with bugs or non-
>> conformities that treat these differently? If have seen a view very
>> buggy and/or very non-conforming or function-limited compilers in my
>> time (including a few big name, expensive toolchains), but a failure
>> here would surprise me greatly. There is no real limit to the type of
>> bugs a compiler could have, but a compiler that fails to get this
>> right is unlikely to be usable in practice.
>>
>> It is plausible that a weaker or non-optimising compiler could
>> generate different code for the two conditionals, one of which is more
>> efficient than the other. Again, I've seen some pretty weak compilers
>> over the years, where you need to fine-tune the source code if you
>> want efficient object code.
>>
>> Mostly comes down to preferences - personal, or set by some coding
>> standards. Do you think the code is clearer to human readers if it is
>> written as "if (!ptr)", "if (ptr == 0)", or perhaps "if (0 == ptr)" -
>> some people feel "Yoda conditionals" are safer.
>
> Well, preferences vary, sure, and so we don't need to discuss
> these in depth. But since you asked, here's my opinion on that.
>
> First, the latter I consider to be "unreadable" nonsense based
> on a false understanding of safety.[*]
>
> For the former two (for me) it depends on the context; has the
> expression a boolean characteristic or not? If so I often prefer
> the former. As example;
>
> if ((fd = fopen ("file", "r")) != NULL)
>
> if ((fd = fopen ("file", "r")) != 0)
>
> if (fd = fopen ("file", "r"))
>
> I'd clearly choose the latter. (And even with local semantics for
> the 'fd' variable where available[**]
>
> if (FILE * fd = fopen ("file", "r"))
>
>
> Janis
>
> [*] Often it's an asymmetric comparison where natural languages
> would formulate "is/has item this value" (or similar), and the
> reverse formulation is counter-intuitive (in that respect). And
> concerning "safety"; if one has to learn that the reverse form
> is the "safe" form then he could instead also just learn that in
> "C" the comparison is '==' and not '='. (In other languages we
> might have support for alternative forms; in OO maybe 'fd.isopen',
> also an asymmetric relation.)
>
I agree about "Yoda conditionals" being hard to read. And if a
programmer is concerned about accidentally using assignment instead of
comparison, compilers can easily check for the mistake. IMHO it is much
better to enable that warning, and pay the "price" of extra parentheses
when you really want to use assignment, rather than writing conditionals
backwards.
> [**] Don't newer versions of "C" support that (or do I confuse it
> with contemporary C++ versions)?
>
You are thinking of :
if (FILE * fd; fd = fopen("file", "r")) ...
or
if (FILE * fd = fopen("file", "r"); fd) ...
which are both valid in C++14 onwards. There are two parts - the
declaration (with optional initialisation), and then the normal
conditional expression. Key to this is that the declared variable is
limited to the scope of the controlled statement or block, in the same
manner as declaring a variable in a "for" statement.
C is expected to support it in C2y, the next version after the current
C23, but that is not yet released.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-04-27 02:17 +0200 |
| Message-ID | <10sm9u0$3knhv$6@dont-email.me> |
| In reply to | #398007 |
On 2026-04-26 19:37, David Brown wrote:
> On 26/04/2026 18:16, Janis Papanagnou wrote:
>> [...]
>>
>> For the former two (for me) it depends on the context; has the
>> expression a boolean characteristic or not? If so I often prefer
>> the former. As example;
>>
>> if ((fd = fopen ("file", "r")) != NULL)
>>
>> if ((fd = fopen ("file", "r")) != 0)
>>
>> if (fd = fopen ("file", "r"))
>>
>> I'd clearly choose the latter. (And even with local semantics for
>> the 'fd' variable where available[**]
>>
>> if (FILE * fd = fopen ("file", "r"))
[...]
>
> You are thinking of :
>
> if (FILE * fd; fd = fopen("file", "r")) ...
>
> or
>
> if (FILE * fd = fopen("file", "r"); fd) ...
>
> which are both valid in C++14 onwards.
Not really, since I've stopped following the C++ evolution with C++11.
It may have been that compilers have supported things like that before
the standard defined it. Actually, faint memories suggest that there
was a time where that was able with 'for' loops but not (not yet) with
'if' blocks. (I may be misremembering, though.)
> There are two parts - the
> declaration (with optional initialisation), and then the normal
> conditional expression. Key to this is that the declared variable is
> limited to the scope of the controlled statement or block, in the same
> manner as declaring a variable in a "for" statement.
Right. The point is that in C/C++ I often have or get a descriptor in
contexts such as
if (descriptor = obtain_resource ()) {
do_things_only_if_valid_descriptor_could_be_obtained ();
release (descriptor);
}
// no descriptor at this point
and I want it exactly with that local scope, tightly coupled.
(The time when I regularly (professionally) programmed in C++ I could
not do that.)
>
> C is expected to support it in C2y, the next version after the current
> C23, but that is not yet released.
For me that's anyway just an academic question, purely out of interest.
Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-27 09:19 +0200 |
| Message-ID | <10sn2lj$25thf$1@dont-email.me> |
| In reply to | #398015 |
On 27/04/2026 02:17, Janis Papanagnou wrote:
> On 2026-04-26 19:37, David Brown wrote:
>> On 26/04/2026 18:16, Janis Papanagnou wrote:
>>> [...]
>>>
>>> For the former two (for me) it depends on the context; has the
>>> expression a boolean characteristic or not? If so I often prefer
>>> the former. As example;
>>>
>>> if ((fd = fopen ("file", "r")) != NULL)
>>>
>>> if ((fd = fopen ("file", "r")) != 0)
>>>
>>> if (fd = fopen ("file", "r"))
>>>
>>> I'd clearly choose the latter. (And even with local semantics for
>>> the 'fd' variable where available[**]
>>>
>>> if (FILE * fd = fopen ("file", "r"))
> [...]
>>
>> You are thinking of :
>>
>> if (FILE * fd; fd = fopen("file", "r")) ...
>>
>> or
>>
>> if (FILE * fd = fopen("file", "r"); fd) ...
>>
>> which are both valid in C++14 onwards.
>
> Not really, since I've stopped following the C++ evolution with C++11.
>
> It may have been that compilers have supported things like that before
> the standard defined it. Actually, faint memories suggest that there
> was a time where that was able with 'for' loops but not (not yet) with
> 'if' blocks. (I may be misremembering, though.)
>
Compilers often support new features in experimental modes before they
are standardised - indeed, for bigger features, both the C and C++
committees like to see such experimental support so they know they are
standardising a workable feature. But in C, declaration within an "if"
is a very recent feature and will not be supported until C2y, and while
I have not tested other compilers, for gcc you need gcc 15. gcc accepts
it as an extension for use with previous C standards (unless you use
"-Wpedantic").
Maybe you have used a different compiler that has offered your version
of the syntax here as an extension.
Declaring a variable in a "for" loop, on the other hand, has been
supported since C99. So the time when it has been allowed with "for"
and not with "if" is from 1999 to perhaps 2029 (current estimates for C2y).
>> There are two parts - the declaration (with optional initialisation),
>> and then the normal conditional expression. Key to this is that the
>> declared variable is limited to the scope of the controlled statement
>> or block, in the same manner as declaring a variable in a "for"
>> statement.
>
> Right. The point is that in C/C++ I often have or get a descriptor in
> contexts such as
>
> if (descriptor = obtain_resource ()) {
> do_things_only_if_valid_descriptor_could_be_obtained ();
> release (descriptor);
> }
> // no descriptor at this point
>
> and I want it exactly with that local scope, tightly coupled.
>
> (The time when I regularly (professionally) programmed in C++ I could
> not do that.)
>
You can do it now in C++, but not yet in C. Of course you can always
put a block around the "if". That has been valid since before C90.
{
descriptor_type descriptor;
if (descriptor = obtain_resource ()) {
do_things_only_if_valid_descriptor_could_be_obtained ();
release (descriptor);
}
}
>>
>> C is expected to support it in C2y, the next version after the current
>> C23, but that is not yet released.
>
> For me that's anyway just an academic question, purely out of interest.
>
OK. That's a perfectly valid reason for asking.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-04-26 17:47 +0000 |
| Message-ID | <ScsHR.196967$%Rle.8581@fx11.iad> |
| In reply to | #397999 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >On 2026-04-26 12:08, David Brown wrote: >> On 26/04/2026 05:28, Janis Papanagnou wrote: >>> >>> [....] are there any formal reasons to not write 'if (!ptr)' ? >> <snip> >> Mostly comes down to preferences - personal, or set by some coding >> standards. Do you think the code is clearer to human readers if it is >> written as "if (!ptr)", "if (ptr == 0)", or perhaps "if (0 == ptr)" - >> some people feel "Yoda conditionals" are safer. > >Well, preferences vary, sure, and so we don't need to discuss >these in depth. But since you asked, here's my opinion on that. > >First, the latter I consider to be "unreadable" nonsense based >on a false understanding of safety.[*] Hear Hear! Agree 100% Similarly, I prefer AT&T asm syntax (from->to) over Intel asm syntax (to<-from) on intel processors..
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-04-27 02:33 +0200 |
| Message-ID | <10smata$3kni0$5@dont-email.me> |
| In reply to | #398008 |
On 2026-04-26 19:47, Scott Lurndal wrote: > [...] > > Similarly, I prefer AT&T asm syntax (from->to) over > Intel asm syntax (to<-from) on intel processors.. I seem to recall that the former was especially historically often seen, starting with Konrad Zuse's Plankalkül (in the early 1940's). Yes, its structure follows the way of "thinking" the assignment. Concerning assemblers I'd have no preference if there's some symbol present to indicate direction (as you used '->' and '<-' above). But if I recall my assembler days decades ago I think there haven't been any indications of that, it was just something like "MOV A B". Don't know whether that has changed "recently" (i.e. "during the past decades"). ;-) Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-27 09:34 +0200 |
| Message-ID | <10sn3hs$25thf$2@dont-email.me> |
| In reply to | #398017 |
On 27/04/2026 02:33, Janis Papanagnou wrote: > On 2026-04-26 19:47, Scott Lurndal wrote: >> [...] >> >> Similarly, I prefer AT&T asm syntax (from->to) over >> Intel asm syntax (to<-from) on intel processors.. > > I seem to recall that the former was especially historically often > seen, starting with Konrad Zuse's Plankalkül (in the early 1940's). > > Yes, its structure follows the way of "thinking" the assignment. > > Concerning assemblers I'd have no preference if there's some symbol > present to indicate direction (as you used '->' and '<-' above). > But if I recall my assembler days decades ago I think there haven't > been any indications of that, it was just something like "MOV A B". > Don't know whether that has changed "recently" (i.e. "during the > past decades"). ;-) > > Janis > Generally in non-assembly programming, I prefer the "dest = val" ordering for assignments. That's also the most common direction, but there are exceptions. I used to have a programmable calculator where storage was "val -> dest", and in Forth you have "val dest !" (where ! means "store"). And then there is MetaFont / MetaPost, where you can write "x + 3 = 2 * y - 4; 4 * y - x = 2;" and that assigns to both x and y. For comparisons, you generally have one thing that you are trying to check against another - and then it is natural to have the thing you are checking come first. So "x == 1", rather than "1 == x" - you want to check the value of "x", not the value of "1". For assembly, I've used assembly languages that go in both directions. Destination first seems most logical to me, especially when there can be more than one source operand. But I've used assemblies with source first too. You get used to the syntax you are using.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-04-27 12:35 +0200 |
| Message-ID | <10sne5i$3kni0$7@dont-email.me> |
| In reply to | #398028 |
On 2026-04-27 09:34, David Brown wrote:
> On 27/04/2026 02:33, Janis Papanagnou wrote:
>> On 2026-04-26 19:47, Scott Lurndal wrote:
>>> [...]
>>>
>>> Similarly, I prefer AT&T asm syntax (from->to) over
>>> Intel asm syntax (to<-from) on intel processors..
>>
>> I seem to recall that the former was especially historically often
>> seen, starting with Konrad Zuse's Plankalkül (in the early 1940's).
>>
>> Yes, its structure follows the way of "thinking" the assignment.
>>
>> Concerning assemblers I'd have no preference if there's some symbol
>> present to indicate direction (as you used '->' and '<-' above).
>> But if I recall my assembler days decades ago I think there haven't
>> been any indications of that, it was just something like "MOV A B".
>> Don't know whether that has changed "recently" (i.e. "during the
>> past decades"). ;-)
>>
>
> Generally in non-assembly programming, I prefer the "dest = val"
> ordering for assignments.
I think most of us are biased towards that, simply by predominance of
that variant.
> That's also the most common direction, but
> there are exceptions. I used to have a programmable calculator where
> storage was "val -> dest", and in Forth you have "val dest !" (where !
> means "store"). And then there is MetaFont / MetaPost, where you can
> write "x + 3 = 2 * y - 4; 4 * y - x = 2;" and that assigns to both x and y.
Few languages show some pluralism; one language I'm enjoying currently
is Algol 68. Here it *could* be possible to define both, ':=' and '=:'
as operator, but they support only the first. But for other operators
they played with the symbols, as in PLUSAB ('+:=' similar zu C's '+=')
and PLUSTO ('+=:'). For a SWAP operator I consequently supported the
alternative form '=:=' recently; a nice visual alternative in the zoo
of the possible options swap (a, b), a SWAP b, a =:= b
Janis
> [...]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-04-27 13:28 +0100 |
| Message-ID | <10snkot$2bntq$1@dont-email.me> |
| In reply to | #398030 |
On 27/04/2026 11:35, Janis Papanagnou wrote:
> On 2026-04-27 09:34, David Brown wrote:
>> On 27/04/2026 02:33, Janis Papanagnou wrote:
>>> On 2026-04-26 19:47, Scott Lurndal wrote:
>>>> [...]
>>>>
>>>> Similarly, I prefer AT&T asm syntax (from->to) over
>>>> Intel asm syntax (to<-from) on intel processors..
>>>
>>> I seem to recall that the former was especially historically often
>>> seen, starting with Konrad Zuse's Plankalkül (in the early 1940's).
>>>
>>> Yes, its structure follows the way of "thinking" the assignment.
>>>
>>> Concerning assemblers I'd have no preference if there's some symbol
>>> present to indicate direction (as you used '->' and '<-' above).
>>> But if I recall my assembler days decades ago I think there haven't
>>> been any indications of that, it was just something like "MOV A B".
>>> Don't know whether that has changed "recently" (i.e. "during the
>>> past decades"). ;-)
>>>
>>
>> Generally in non-assembly programming, I prefer the "dest = val"
>> ordering for assignments.
>
> I think most of us are biased towards that, simply by predominance of
> that variant.
Not in shell syntax:
cp A B
copy A B
These copy A to B, not B to A.
>> That's also the most common direction, but there are exceptions. I
>> used to have a programmable calculator where storage was "val ->
>> dest", and in Forth you have "val dest !" (where ! means "store").
>> And then there is MetaFont / MetaPost, where you can write "x + 3 = 2
>> * y - 4; 4 * y - x = 2;" and that assigns to both x and y.
>
> Few languages show some pluralism; one language I'm enjoying currently
> is Algol 68. Here it *could* be possible to define both, ':=' and '=:'
> as operator, but they support only the first. But for other operators
> they played with the symbols, as in PLUSAB ('+:=' similar zu C's '+=')
> and PLUSTO ('+=:'). For a SWAP operator I consequently supported the
> alternative form '=:=' recently; a nice visual alternative in the zoo
> of the possible options swap (a, b), a SWAP b, a =:= b
In my languages I also played with such possibilities for 'swap',
although I used ':=:' for the symbol.
In the end I decided to just use swap(A, B) as being the clearest and
simplest, obvious even to those not familiar with the syntax.
Still, 'swap' isn't that common a feature anyway; many languages think that:
A, B = B, A
will suffice. Until you see examples like this:
A[i+1], B[j-1] = B[i-1], A[j+1]
A[i+1], B[j-1] = B[j-1], A[i+1]
One of these is swapping the same two elements, but it is not obvious:
you have look carefully, and even then you can't be sure if one was
meant to be SWAP and there's a typo, or it's intentional.
Compare with swap(A[i+1], B[j-1]).
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-04-27 17:02 +0200 |
| Message-ID | <10sntqi$3kni0$8@dont-email.me> |
| In reply to | #398031 |
On 2026-04-27 14:28, Bart wrote:
> On 27/04/2026 11:35, Janis Papanagnou wrote:
>>
>> I think most of us are biased towards that, simply by predominance of
>> that variant.
>
> Not in shell syntax:
You are mistaken; below examples are not "shell syntax" but show
only the way the specific Unix tools have been designed to work.
It's a common implementation of Unix tools, though, that's true.
(But there are also prominent counter-examples, of course.)
Shell syntax has the usual direction of assignment; the simplest
is 'a=b' or variants thereof (e.g. in arithmetic, arrays, etc.).
>
> cp A B
> copy A B
>
> These copy A to B, not B to A.
Actually it would be simpler for the tool implementation to have
the target come first; your example above (and similar tools) are
usually defined to accept multiple values; e.g.
cp a b c d e ... dir/
where in
cp dir/ a b c d e ...
one can take the fixed target, shift, and then loop over the rest.
Also if you embed commands with the 'xargs' command having such a
special final argument requires "more effort".
[...]
>>
>> Few languages show some pluralism; one language I'm enjoying currently
>> is Algol 68. Here it *could* be possible to define both, ':=' and '=:'
>> as operator, but they support only the first. But for other operators
>> they played with the symbols, as in PLUSAB ('+:=' similar zu C's '+=')
>> and PLUSTO ('+=:'). For a SWAP operator I consequently supported the
>> alternative form '=:=' recently; a nice visual alternative in the zoo
>> of the possible options swap (a, b), a SWAP b, a =:= b
>
> In my languages I also played with such possibilities for 'swap',
> although I used ':=:' for the symbol.
That symbol is already occupied in Algol 68 (for the 'IS' relation,
likewise :/=: for 'ISNT').
>
> In the end I decided to just use swap(A, B) as being the clearest and
> simplest, obvious even to those not familiar with the syntax.
Yes, using descriptive words is the most reliable to express things
clearly. ("C" failed with '=' and '==' in that respect; in clarity.)
>
> Still, 'swap' isn't that common a feature anyway; many languages think
> that:
>
> A, B = B, A
Other designs use parenthesis, e.g., (a, b) := (b, a) as a special
case of a more general "collateral assignment" construct.
(IMO that's a better readable form than what you've chosen to show
as example.)
>
> will suffice. Until you see examples like this:
>
> A[i+1], B[j-1] = B[i-1], A[j+1]
> A[i+1], B[j-1] = B[j-1], A[i+1]
>
> One of these is swapping the same two elements, but it is not obvious:
> you have look carefully, and even then you can't be sure if one was
> meant to be SWAP and there's a typo, or it's intentional.
I disagree; whether something gets overwritten or not depends just on
how the language handles that! (I seem to recall you know Algol 68;
then lookup how array assignments with descriptors on the same array
are handled.)
(Only if you choose a more primitive or badly designed language you
may have a point.)
I agree that having duplicates of the same elements may be a problem
(in the sense that as language designer should take care of that).
> Compare with swap(A[i+1], B[j-1]).
Or with A[i+1] SWAP B[j-1] A[i+1] =:= B[j-1]
But the semantics of your '=' based example could also be defined in
a safe way.
Given that the 'swap' arguments have reference characteristic (unless
being just done like in the collateral assignment) languages should
sensibly take care when implementing such things.
Janis
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web