From Newsgroup: comp.lang.c

On 2026-04-08 18:25, DFS wrote:

On 4/8/2026 4:22 AM, Janis Papanagnou wrote:

No necessity for peeking since I'd write a Unix 'sort' one-liner
(instead of a bulky "C" program). ;-)

Bulky C is more fun!

Well, opinions differ. I indeed like little obfuscated challenges.
But for production code (whether professional or personal) clear
code is preferable.

"one-liner"?  With multiple pipes and tr and sed and awk, maybe.

It depends. If the entries are in one line each it's just 'sort'.

If you have them all in a one line I'd usually use simply a 'sed'
to create lines, and if the output shall be in lines again, then
another 'sed'. That's all. (Less that 60 characters for all.)

Honestly; mind to explain what the point of this "C" challenge is?

Sure thing: "Print first last (as shown above) but ordered by last first."

That doesn't explain the point of such primitive "challenges".
(But never mind.)

As noted with a previous "challenge" I see neither a challenge
for the "C" language, nor an algorithmic challenge here. (YMMV.)

Janis

[...]

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-04-08 23:04, Scott Lurndal wrote:

Bart <[email protected]> writes:

On 08/04/2026 17:25, DFS wrote:

On 4/8/2026 4:22 AM, Janis Papanagnou wrote:

//count characters in a string
int countchr(char *str, char chr)
{int c=0,cnt=0;while(str[c]!='\0'){if(str[c]==chr){cnt++;}c++;}return
cnt;}

I couldn't quite figure out what it did; counting characters in a string
(like the comment says)? But strlen will do that. Then I noticed that
the extra 'chr' parameter, so maybe it stops at 'chr'.

But when I tried running it as countchr("ABCDEFGH", 'E'), it returned 1,
not 4 or 5.

So I refactored it like this:

int countchr(char *str, char chr) {
int c=0, cnt=0;
while (str[c]!='\0') {
if (str[c] == chr) cnt++;
c++;
}
return cnt;
}

Idiomatically, I might have written

size_t
countchar(const char *str, char match)
{
size_t count = 0u;
for(; *str != '\0'; str++) count += (*str == match);
return count;
}

I'd usually see whether the initialization could also be placed in
the loop; I dislike those "incomplete" "C" loops. Or I'd have used
a 'while' loop which I consider to be clearer

while (*str != '\0')
count += (*str++ == match);

I'd probably even omitted the comparison and relied on the implicit
non-0 (*str) test. (I don't recall that this is a problem, or is it?)

That's at least what I'd call even a bit more idiomatic, reducing the expressions to that extent.

Janis

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-04-08 23:13, DFS wrote:

[...]

And I notice I didn't specify the output format.  I want it to look like this:

Ron Lauzon
Wenfeng Liang
Brendan Long
Jacob Lyles
Jim McCloskey
Mordant
Mike Nichols
Michael Nygard
Malcolm Ocean
Doug Phillips
Mark Ping

Since you asked in another post; then it would be (with Unix tools on
the command-line) just a single 'sed' to make the data line-canonical
for the sort-processing

sed 's/, /\n/g' | sort -k2 -k1

(so just 30 characters, compared to the 60 with a re-lining-up 'sed').

Janis

[...]

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-04-11 08:59, Janis Papanagnou wrote:

On 2026-04-08 23:13, DFS wrote:

[...]

And I notice I didn't specify the output format.  I want it to look
like this:

BTW; you also didn't specify what to do with words that don't have
two name components.

I noticed, besides the already mentioned Greek entry ("Άρης Δάσος") a couple single word entries (darrin, Mordant, ReallyBored, taishi28012).
What to do with those?

Mind that for a sensible data processing you'd fix input data before
doing the processing. (Otherwise you'd get trash-in trash-out quality,
and/or bulky/unmaintainable programs to "fix" data issues on the fly.)

Janis

[...]

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

[email protected] (Dan Cross) writes:

In article <[email protected]>,
Michael S <[email protected]> wrote:

On Wed, 08 Apr 2026 23:35:35 GMT
[email protected] (Scott Lurndal) wrote:

Michael S <[email protected]> writes:

On Wed, 08 Apr 2026 21:04:56 GMT
[email protected] (Scott Lurndal) wrote:

[snip]

Idiomatically, I might have written

size_t
countchar(const char *str, char match)
{
size_t count = 0u;
for(; *str != '\0'; str++) count += (*str == match);
return count;
}

I'd change it to

size_t
countchar(const char *str, char match)
{
size_t count = 0;
for(; *str != 0; str++) count += (*str == match);
return count;
}

Personally, I prefer to properly identify integer constants
with the appropriate type annotation. I always explicitly
check against NULL rather than using !ptr, for example. I
never use an unadorned integer for a character constant,
rather using either 'c' for printables, the legal escapes
(e.g. \n) and for any non-printable, the appropriate
octal escape.

Perhaps some of this is pedantic. I worked with a system
where the null pointer constant was not the value zero, so
I'm aware that !ptr may not actually do the right thing in
such cases.

Which is irrelevant in this specific case.
BTW, I think that (ptr != 0) is guaranteed to work even on systems
with null pointers not being numerically zero. But I am not
certain about it. What I am certain is that on the right side of
assignment to pointer 0 always acts the same as NULL.
But that's too irrelevant for our case.

It's easy enough to verify looking at a canonical source.
Section 6.3.2.3 coupled with 6.5.9 of C18 suggest this is
guaranteed to work.

As to being pedantic w.r.t. '\0', may be you acquired this habit
because of C++? If I am not mistaken, in C++ '\0' has type char
and due to that (or because of, which is IMHO, more appropriate
wording) can in some contexts lead to results different from 0,
with differences as huge as call to completely different procedure.
It does not happen in C where we have no misfeature of type based
static polymorphism.

'\0' is indeed a `char` in C++. But I don't think that really
changes the point, which is more about semantics. Why NOT use a
relevant character constant instead of `0`? It's not whether
one can or not, or whether it's semantically equivalent, or
whether C's `char` type is really an integer in a trenchcoat:
it's using the appropriate constant to match the domain: in this
case, matching character data.

There's no reason to use a constant at all; just write '*str'.
This writing isn't just idiomatic -- it's integral to how the
language was designed, not only for string termination but also
the rules for null pointers and how expressions work in the
context of for(), if(), and while(). Writing != 0 or != '\0' is
a holdover from being used to writing Pascal (or any number of
other earlier languages). When in Rome, do as the Romans do.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 08/04/2026 04:14, DFS wrote:

Martin Hohenberg, Jae Yang, Tim Bando, Daniel Garber, Kyle Burkholder,
Mike Nichols, Mark Ping, Tom Taylor, Arnold F. Williams, George
Brower, Michael Nygard, Brendan Long, Sven Dowideit, Dave Witten,
Jonathan Cast, James Cronin, David L. Jessup, Christopher Chang,
Killer Delicious, Jacob Lyles, Neil Anuskiewicz, Mordant, Clemens
Ladisch, Wojciech Woytniak, Masa Bando, John Carmack, Xingyu Wang,
Jane Tang, Steven Evans, Jan Roudaut, Hsueh Sung, Ken LaCrosse,
taishi28012, John Simpson, Jerod Tufte, Paul Abbott, Stan Witherspoon, Donald Greer, Gratiela Chergu, Michael Ciagala, Dale Carstensen, Chip
Davis, Liudmilla Karukina, Jim McCloskey, Dewey Sasser, Hal
Hildebrand, Connor Wood, Ken Kennedy, darrin, Mark Gardner, William Christensen, Malcolm Ocean, Rod Davenport, Nodarius Darjania, Cheryl
Evry, Wenfeng Liang, Irving Rivas, Bill Soistman, ReallyBored, Άρης Δάσος, Ron Lauzon, TheFred, Paul Theodoropolous, Doug Phillips, Les Vogel, Matt Pollard, Andres Cordova

Print first last (as shown above) but ordered by last first.

I would start with something simple and improve on it:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

// Function to extract last name from full name
const char* get_last_name(const char* full_name) {
const char* last_space = strrchr(full_name, ' ');
if (last_space == NULL) {
return full_name;       // No space → whole string is last name
}
return last_space + 1;      // Return pointer after last space
}

// Comparison function for qsort (sorts by last name)
int compare_by_last_name(const void* a, const void* b) {
const char* name1 = *(const char**)a;
const char* name2 = *(const char**)b;

const char* last1 = get_last_name(name1);
const char* last2 = get_last_name(name2);

return strcmp(last1, last2);
}

int main() {
// Array of names
char* names[] = {
"Martin Hohenberg", "Jae Yang","Tim Bando","Daniel Garber","Kyle Burkholder","Mike
Nichols","Mark Ping","Tom Taylor","Arnold F. Williams","George Brower","Michael Nygard","Brendan Long","Sven Dowideit","Dave Witten","Jonathan Cast","James Cronin","David L. Jessup","Christopher Chang","Killer Delicious","Jacob Lyles","Neil
Anuskiewicz","Mordant","Clemens Ladisch","Wojciech Woytniak","Masa Bando","John Carmack","Xingyu Wang","Jane Tang","Steven Evans","Jan Roudaut","Hsueh Sung","Ken LaCrosse","taishi28012","John Simpson","Jerod Tufte","Paul Abbott","Stan Witherspoon","Donald Greer","Gratiela Chergu","Michael Ciagala","Dale Carstensen","Chip Davis","Liudmilla Karukina","Jim McCloskey","Dewey Sasser","Hal Hildebrand","Connor
Wood","Ken Kennedy","darrin","Mark Gardner","William
Christensen","Malcolm Ocean","Rod Davenport","Nodarius Darjania","Cheryl Evry","Wenfeng Liang","Irving Rivas","Bill Soistman","ReallyBored","???? ?????","Ron Lauzon","TheFred", "Paul Theodoropolous","Doug
Phillips","Les Vogel","Matt Pollard","Andres Cordova"
};

int n = sizeof(names) / sizeof(names[0]);

printf("Before sorting:\n");
for (int i = 0; i < n; i++) {
printf("%s\n", names[i]);
}

// Sort using qsort
qsort(names, n, sizeof(char*), compare_by_last_name);

printf("\nAfter sorting by last name:\n");
for (int i = 0; i < n; i++) {
printf("%s\n", names[i]);
}

return 0;
}

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

In article <[email protected]>,
Tim Rentsch <[email protected]> wrote:

[email protected] (Dan Cross) writes:

In article <[email protected]>,
Michael S <[email protected]> wrote:

On Wed, 08 Apr 2026 23:35:35 GMT
[email protected] (Scott Lurndal) wrote:

Michael S <[email protected]> writes:

On Wed, 08 Apr 2026 21:04:56 GMT
[email protected] (Scott Lurndal) wrote:

[snip]

Idiomatically, I might have written

size_t
countchar(const char *str, char match)
{
size_t count = 0u;
for(; *str != '\0'; str++) count += (*str == match);
return count;
}

I'd change it to

size_t
countchar(const char *str, char match)
{
size_t count = 0;
for(; *str != 0; str++) count += (*str == match);
return count;
}

Personally, I prefer to properly identify integer constants
with the appropriate type annotation. I always explicitly
check against NULL rather than using !ptr, for example. I
never use an unadorned integer for a character constant,
rather using either 'c' for printables, the legal escapes
(e.g. \n) and for any non-printable, the appropriate
octal escape.

Perhaps some of this is pedantic. I worked with a system
where the null pointer constant was not the value zero, so
I'm aware that !ptr may not actually do the right thing in
such cases.

Which is irrelevant in this specific case.
BTW, I think that (ptr != 0) is guaranteed to work even on systems
with null pointers not being numerically zero. But I am not
certain about it. What I am certain is that on the right side of
assignment to pointer 0 always acts the same as NULL.
But that's too irrelevant for our case.

It's easy enough to verify looking at a canonical source.
Section 6.3.2.3 coupled with 6.5.9 of C18 suggest this is
guaranteed to work.

As to being pedantic w.r.t. '\0', may be you acquired this habit
because of C++? If I am not mistaken, in C++ '\0' has type char
and due to that (or because of, which is IMHO, more appropriate
wording) can in some contexts lead to results different from 0,
with differences as huge as call to completely different procedure.
It does not happen in C where we have no misfeature of type based
static polymorphism.

'\0' is indeed a `char` in C++. But I don't think that really
changes the point, which is more about semantics. Why NOT use a
relevant character constant instead of `0`? It's not whether
one can or not, or whether it's semantically equivalent, or
whether C's `char` type is really an integer in a trenchcoat:
it's using the appropriate constant to match the domain: in this
case, matching character data.

There's no reason to use a constant at all; just write '*str'.
This writing isn't just idiomatic -- it's integral to how the
language was designed, not only for string termination but also
the rules for null pointers and how expressions work in the
context of for(), if(), and while(). Writing != 0 or != '\0' is
a holdover from being used to writing Pascal (or any number of
other earlier languages).

This is subjective, and _a_ response from a different school of
thought may be that `*str` is not a boolean type, and thus
should not be used in a boolean context. You may disagree; I
may occasionally disagree myself, but again, it's subjective.

When in Rome, do as the Romans do.

This is the critical part. Many Unix and Unix-like kernels, for
instance, have style guides that demand comparison against an
appropriately type constants, along with other style rules about
the placement of braces, use of whitespace, indentation, and so
on. If one works in those kernels, one doesn't really have a
lot of choice: one must do what the Romans in that instance of
Rome do, regardless of personal preference.

- Dan C.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

[email protected] (Scott Lurndal) writes:

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> 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.

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.

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.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> 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.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Tim Rentsch <[email protected]> writes:

[email protected] (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).
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 4/8/2026 3:22 AM, Janis Papanagnou wrote:

On 2026-04-08 05:14, DFS wrote:

Martin Hohenberg, Jae Yang, Tim Bando, Daniel Garber, Kyle Burkholder,
Mike Nichols, Mark Ping, Tom Taylor, Arnold F. Williams, George
Brower, Michael Nygard, Brendan Long, Sven Dowideit, Dave Witten,
Jonathan Cast, James Cronin, David L. Jessup, Christopher Chang,
Killer Delicious, Jacob Lyles, Neil Anuskiewicz, Mordant, Clemens
Ladisch, Wojciech Woytniak, Masa Bando, John Carmack, Xingyu Wang,
Jane Tang, Steven Evans, Jan Roudaut, Hsueh Sung, Ken LaCrosse,
taishi28012, John Simpson, Jerod Tufte, Paul Abbott, Stan Witherspoon,
Donald Greer, Gratiela Chergu, Michael Ciagala, Dale Carstensen, Chip
Davis, Liudmilla Karukina, Jim McCloskey, Dewey Sasser, Hal
Hildebrand, Connor Wood, Ken Kennedy, darrin, Mark Gardner, William
Christensen, Malcolm Ocean, Rod Davenport, Nodarius Darjania, Cheryl
Evry, Wenfeng Liang, Irving Rivas, Bill Soistman, ReallyBored, Άρης
Δάσος, Ron Lauzon, TheFred, Paul Theodoropolous, Doug Phillips, Les
Vogel, Matt Pollard, Andres Cordova


Print first last [name] (as shown above) but ordered by last first.

In cases like this where data with Latin and Greek characters are
mixed you should clarify or even define how the comparison function
shall operate on mixed data to create a "correct" ordering.

Hereabouts we usually insert the "Άρης Δάσος" (starting with the letter Delta) before or after the letter 'D'; i.e. using an implicit transcription. But this may not suit other cases. Or artificial ones
like this challenge, so you should probably clarify for folks who
are interested to re-implement (or use) a sorting function in "C"
(with or without a locale setting to do the dirty work).

FWIW...


One approach I had defined for some filesystem code of mine:
Normalize encoding as UTF-8 or similar;
Do a byte-for-byte comparison of the UTF-8 strings.

UTF-8 normalization can itself get complicated.
Though, keeping the set of rules minimal can help;
Otherwise, the task can become unreasonable.


Otherwise, the normalization and collation rules were assumed to be independent of locale.

Well, and tend not to be collation-correct even for US ASCII (where,
say, people often expect alphabetic ordering and letters to come first,
unlike ASCII ordering where numbers come first, then upper case, then
lower case, with various symbols between them, ...).



For storage, there were a few options:
Option 1:
Leave everything as UTF-8, using only UTF-8;
Option 2:
Allow CP1252 if name string could be represented exactly;
And, the 1252 would not be confused for valid UTF-8.


The merit of 2 is that, besides purely ASCII filenames, CP1252 names
were a solid second place in my states, followed in the 3rd place by
names with emojis, and 4th place by Chinese characters and similar, ...

Granted, person names are different from filenames so would likely have
a different ranking (well, and you can hope people don't start naming
kids with names containing emojis, ...).

Though, can note that the reasoning in this case was that there was a short-name case (names that fit under a 48-byte limit), and long-name
case (names that exceeded 48 bytes), and the difference between 1252 and
UTF-8 could often be "make or break" for a name fitting within the 48
byte limit (without the complexity of full code-page handling).

Though, in this case, if 1252 was used, one could end up with it doing byte-for-byte comparison between UTF-8 and 1252, but this was OK (well,
and for purposes of sorting, it only cared about the short-name field,
which for long names would contain the first 40 bytes with the last 8
bytes replaced with a hash of the full length name).


In this case, name hash algorithm was defined as, roughly:
uint64_t DfsLongNameHash(char *name)
{
uint64_t h0, h1, h;
char *s;
int i, c, l, n;

l=strlen(name);
s=name; h0=1; h1=0;
n=l>>2;
for(i=0; i<n; i++)
{ h1+=h0; h0+=*(uint32_t *)s; s+=4; }
if(n&3)
{
c=*(uint32_t *)s;
c&=((1U<<((n&3)*8))-1);
h1+=h0; h0+=c;
}
h0=((uint32_t)h0)+(h0>>32); h1=((uint32_t)h1)+(h1>>32);
h0=((uint32_t)h0)+(h0>>32); h1=((uint32_t)h1)+(h1>>32);
h=h0|(h1<<32);
return(h);
}

...


Hasn't seen that much practical use thus far.
Initially it was motivated by:
FAT is kinda limited,
and faking a Unix-style FS on top of FAT is lame.
NTFS was way too needlessly complicated.
EXT2 almost works, but:
Has some needless design cruft that was better handled in NTFS;
General approach makes sense though.
Handling of directories would be needlessly inefficient.
Linear search over variable-sized dirents.


So, ended up with a design partway between NTFS and EXT2, but aiming to
avoid needless complexity and to keep the design reasonably efficient.
Inode table: Hybrid approach,
inode-table is self-defining like the MFT.
Block management strategy superficially similar to EXT2.
Though, using a single global bitmap, rather than block groups;
Bitmap and inode table can grow as needed, ...
Directories used fixed-size dirents organized into an AVL tree.
In this case, was chosen as a compromise.
Linear directories are simpler, but scale poorly.
AVL trees were intermediate between linear and B-Trees.
Efficiency analysis favored AVL trees in this case.

Though, the pain of rebalancing trees on insert/delete left me
questioning the choice. Because delete was too much of a pain, ended up
using a strategy where it would mark nodes as deleted and then (as
convenient) actually remove the entries in subsequent node rotates (and
also making the re-balancing more lax as I had noted that +/- 2 would
result in significantly less rotates than +/- 1).

As, dealing with directory insert/delete handling became one of the more complicated parts of the filesystem.

Over the range of typical directory sizes, AVL trees remained as the
more efficient option, only getting edged out by B-Trees for excessively
large directories (but nearly always having a cheaper lookup cost vs
linear search, even if insert/delete costs are often higher).

...


Though, can note that with such an approach, something seemingly minor
like a change in normalization or collation behavior could break the
ability of the FS driver to open files. Which is a possible area for
concern.


Though, for NTFS, the strategy had been to ship things like the
code-point collation ordering tables along with the filesystem
(theoretically, could depend on the locale the FS was formatted under;
AFAIK in practice a global set of tables was used independent of
locale). Better IMO to keep collation as part of a UI-presentation thing (whether the file browser presents files ordered in a way that makes
sense for the user's locale being a locale-specific thing).


Was simplified slightly by assuming everything is case-sensitive.
Actually, I went a little non-standard by even having the FAT driver as
case sensitive.

...

------------------------------------------------------------------
No peeking!
[...removed without peeking...]
71 SLOC

No necessity for peeking since I'd write a Unix 'sort' one-liner
(instead of a bulky "C" program). ;-)

Honestly; mind to explain what the point of this "C" challenge is?

(From the application user's perspective the most interesting thing
would be a sophisticated handling of "mixed locales", but I assume
you're just using what C's 'str*cmp' functions technically provide
with whatever environment setting, and the challenge is something
else?)

Yeah, mostly agreed here.

Janis

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Tim Rentsch <[email protected]> writes:

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> 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) [email protected]
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

[email protected] (Scott Lurndal) writes:

Tim Rentsch <[email protected]> writes:

[email protected] (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.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

As usual - in a superior language.

#include <iostream>
#include <utility>
#include <string_view>
#include <regex>
#include <vector>
#include <algorithm>

using namespace std;

static constexpr string_view Names = "Martin Hohenberg, Jae Yang, Tim
Bando, Daniel Garber, Kyle Burkholder, Mike Nichols, Mark Ping, Tom
Taylor, Arnold F. Williams, George Brower, Michael Nygard, Brendan Long,
Sven Dowideit, Dave Witten, Jonathan Cast, James Cronin, David L.
Jessup, Christopher Chang, Killer Delicious, Jacob Lyles, Neil
Anuskiewicz, Mordant, Clemens Ladisch, Wojciech Woytniak, Masa Bando,
John Carmack, Xingyu Wang, Jane Tang, Steven Evans, Jan Roudaut, Hsueh
Sung, Ken LaCrosse, taishi28012, John Simpson, Jerod Tufte, Paul Abbott,
Stan Witherspoon, Donald Greer, Gratiela Chergu, Michael Ciagala, Dale Carstensen, Chip Davis, Liudmilla Karukina, Jim McCloskey, Dewey Sasser,
Hal Hildebrand, Connor Wood, Ken Kennedy, darrin, Mark Gardner, William Christensen, Malcolm Ocean, Rod Davenport, Nodarius Darjania, Cheryl
Evry, Wenfeng Liang, Irving Rivas, Bill Soistman, ReallyBored, Άρης Δάσος, Ron Lauzon, TheFred, Paul Theodoropolous, Doug Phillips, Les Vogel, Matt Pollard, Andres Cordova";

int main()
{
regex
rxComma( "\\s*([^,]+)(,|$)" ),
rxRvSurname( "\\s*(\\S+)" ),
rxGapSpaces( "(\\s+)" );
match_results<string_view::iterator> mtch;
match_results<string_view::reverse_iterator> reverseMatch;
using name = pair<string_view, string_view>;
vector<name> names;
for( auto itName = ::Names.begin(); ; itName = mtch[0].second )
{
if( !regex_search( itName, ::Names.end(), mtch, rxComma ) )
break;
if( !regex_search( reverse_iterator( mtch[1].second ), reverse_iterator( mtch[1].first ), reverseMatch, rxRvSurname ) )
continue;
auto
itSurname = reverseMatch[1].second.base(),
itSurnameEnd = reverseMatch[1].first.base();
string_view surname( itSurname, itSurnameEnd );
auto itForename = mtch[1].first;
if( !regex_search( reverse_iterator( itSurname ), reverse_iterator(
itForename ), reverseMatch, rxGapSpaces ) )
continue;
auto itForenameEnd = reverseMatch[1].second.base();
string_view forename( itForename, itForenameEnd );
names.emplace_back( forename, surname );
}
sort( names.begin(), names.end(), []( const name &lhs, const name &rhs ) { return lhs.second < rhs.second; } );
for( const name &nm : names )
{
cout << "\"" << nm.first << "\" - \"" << nm.second << "\"" << endl;
}
}

The cool thing about that that I'm matching a part of the name with
a reverse-iterator, i.e. I do reverse regex parsing (the regex itself
is forward).

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Am 09.04.2026 um 01:59 schrieb Michael S:

BTW, I think that (ptr != 0) is guaranteed to work even on systems with
null pointers not being numerically zero. ...

Sorry, that's ridiculous. Which system ever has used sth. different than
a physical null-pointer for a logical. And do you really expect that to
happen in the future ?
You see uncertainties where ther are non.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 16/04/2026 17:24, Bonita Montero wrote:

As usual - in a superior language.

#include <iostream>
#include <utility>
#include <string_view>
#include <regex>
#include <vector>
#include <algorithm>

using namespace std;

static constexpr string_view Names = "Martin Hohenberg, Jae Yang, Tim
Bando, Daniel Garber, Kyle Burkholder, Mike Nichols, Mark Ping, Tom
Taylor, Arnold F. Williams, George Brower, Michael Nygard, Brendan Long, Sven Dowideit, Dave Witten, Jonathan Cast, James Cronin, David L.
Jessup, Christopher Chang, Killer Delicious, Jacob Lyles, Neil
Anuskiewicz, Mordant, Clemens Ladisch, Wojciech Woytniak, Masa Bando,
John Carmack, Xingyu Wang, Jane Tang, Steven Evans, Jan Roudaut, Hsueh
Sung, Ken LaCrosse, taishi28012, John Simpson, Jerod Tufte, Paul Abbott, Stan Witherspoon, Donald Greer, Gratiela Chergu, Michael Ciagala, Dale Carstensen, Chip Davis, Liudmilla Karukina, Jim McCloskey, Dewey Sasser,
Hal Hildebrand, Connor Wood, Ken Kennedy, darrin, Mark Gardner, William Christensen, Malcolm Ocean, Rod Davenport, Nodarius Darjania, Cheryl
Evry, Wenfeng Liang, Irving Rivas, Bill Soistman, ReallyBored, Άρης Δάσος, Ron Lauzon, TheFred, Paul Theodoropolous, Doug Phillips, Les Vogel, Matt Pollard, Andres Cordova";

int main()
{
    regex
        rxComma( "\\s*([^,]+)(,|$)" ),
        rxRvSurname( "\\s*(\\S+)" ),
        rxGapSpaces( "(\\s+)" );
    match_results<string_view::iterator> mtch;
    match_results<string_view::reverse_iterator> reverseMatch;
    using name = pair<string_view, string_view>;
    vector<name> names;
    for( auto itName = ::Names.begin(); ; itName = mtch[0].second )
    {
        if( !regex_search( itName, ::Names.end(), mtch, rxComma ) )
            break;
        if( !regex_search( reverse_iterator( mtch[1].second ), reverse_iterator( mtch[1].first ), reverseMatch, rxRvSurname ) )
            continue;
        auto
            itSurname = reverseMatch[1].second.base(),
            itSurnameEnd = reverseMatch[1].first.base();
        string_view surname( itSurname, itSurnameEnd );
        auto itForename = mtch[1].first;
        if( !regex_search( reverse_iterator( itSurname ), reverse_iterator( itForename ), reverseMatch, rxGapSpaces ) )
            continue;
        auto itForenameEnd = reverseMatch[1].second.base();
        string_view forename( itForename, itForenameEnd );
        names.emplace_back( forename, surname );
    }
    sort( names.begin(), names.end(), []( const name &lhs, const name &rhs ) { return lhs.second < rhs.second; } );
    for( const name &nm : names )
    {
        cout << "\"" << nm.first << "\" - \"" << nm.second << "\"" <<
endl;
    }
}

The cool thing about that that I'm matching a part of the name with
a reverse-iterator, i.e. I do reverse regex parsing (the regex itself
is forward).

What's not cool is that it takes 4.7 seconds to compile this 45 line
program, unoptimised. and 7.7 seconds optimised.

Does it need to be optimised? I guess so, even if it's just to get the
size down: optimised is 136KB, unoptimised it's 319KB.

Tiny C builds the C version in pretty much zero seconds, for a 8KB program.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Am 16.04.2026 um 19:38 schrieb Bart:

What's not cool is that it takes 4.7 seconds to compile this 45 line program, unoptimised. and 7.7 seconds optimised.

Doesn't matter if you need not a third of the time to develop the code.
And if you like more performance you can use C++20 modules.

Does it need to be optimised? I guess so, even if it's just to get the
size down: optimised is 136KB, unoptimised it's 319KB.

Doesn't matter.

Tiny C builds the C version in pretty much zero seconds, for a 8KB program.

Is this really an advantage ? You C guys really suck.
You continue to see details without noting the overall picture.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

In article <10rr402$1r3mi$[email protected]>,
Bonita Montero <[email protected]> wrote:

Am 09.04.2026 um 01:59 schrieb Michael S:

BTW, I think that (ptr != 0) is guaranteed to work even on systems with
null pointers not being numerically zero. ...

Sorry, that's ridiculous. Which system ever has used sth. different than
a physical null-pointer for a logical. And do you really expect that to >happen in the future ?
You see uncertainties where ther are non.

Hmm, I wonder if the AS/400 has this.

- Dan C.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Am 16.04.2026 um 21:54 schrieb Dan Cross:

In article <10rr402$1r3mi$[email protected]>,

Bonita Montero <[email protected]> wrote:

Sorry, that's ridiculous. Which system ever has used sth. different than
a physical null-pointer for a logical. And do you really expect that to
happen in the future ?
You see uncertainties where ther are non.

Hmm, I wonder if the AS/400 has this.

With the AS/400 the NULL-pointer is physically zero. But the AS/400
has typed registers so that a NULL-pointer is sth. different than a
register with an zero integer.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

In article <10r537m$in2o$[email protected]>,
Janis Papanagnou <[email protected]> wrote:
...

Honestly; mind to explain what the point of this "C" challenge is?

To generate traffic on an otherwise sterile and (almost) dead newsgroup on
an (almost) dead platform.

It (and, more generally, its author) has done an admirable job of that.

Or, to put it another way, what is the point of comp.lang.c?

Answer that, and you will be most of the way to answering the original question.
--
I've been watching cat videos on YouTube. More content and closer to
the truth than anything on Fox.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Tue, 7 Apr 2026 23:14:41 -0400, DFS wrote:

Martin Hohenberg, Jae Yang, Tim Bando, Daniel Garber, Kyle Burkholder,
Mike Nichols, Mark Ping, Tom Taylor, Arnold F. Williams, George Brower, >Michael Nygard, Brendan Long, Sven Dowideit, Dave Witten, Jonathan Cast, >James Cronin, David L. Jessup, Christopher Chang, Killer Delicious,
Jacob Lyles, Neil Anuskiewicz, Mordant, Clemens Ladisch, Wojciech
Woytniak, Masa Bando, John Carmack, Xingyu Wang, Jane Tang, Steven
Evans, Jan Roudaut, Hsueh Sung, Ken LaCrosse, taishi28012, John Simpson, >Jerod Tufte, Paul Abbott, Stan Witherspoon, Donald Greer, Gratiela
Chergu, Michael Ciagala, Dale Carstensen, Chip Davis, Liudmilla
Karukina, Jim McCloskey, Dewey Sasser, Hal Hildebrand, Connor Wood, Ken >Kennedy, darrin, Mark Gardner, William Christensen, Malcolm Ocean, Rod >Davenport, Nodarius Darjania, Cheryl Evry, Wenfeng Liang, Irving Rivas,
Bill Soistman, ReallyBored, ???? ?????, Ron Lauzon, TheFred, Paul >Theodoropolous, Doug Phillips, Les Vogel, Matt Pollard, Andres Cordova

Print first last (as shown above) but ordered by last first.

ot

this would be one APL program in "brace" form and its result, because
here it seems is difficult print 2 chars chars

s{leftarrow}{apostrophe}Martin Hohenberg, Jae Yang, Tim Bando,
Daniel Garber, Kyle Burkholder, Mike Nichols, Mark Ping, Tom Taylor,
Arnold F. Williams, George Brower, Michael Nygard, Brendan Long, Sven
Dowideit, Dave Witten, Jonathan Cast, James Cronin, David L. Jessup, Christopher Chang, Killer Delicious, Jacob Lyles, Neil Anuskiewicz,
Mordant, Clemens Ladisch, Wojciech Woytniak, Masa Bando, John Carmack,
Xingyu Wang, Jane Tang, Steven Evans, Jan Roudaut, Hsueh Sung, Ken
LaCrosse, taishi28012, John Simpson, Jerod Tufte, Paul Abbott, Stan Witherspoon, Donald Greer, Gratiela Chergu, Michael Ciagala, Dale
Carstensen, Chip Davis, Liudmilla Karukina, Jim McCloskey, Dewey
Sasser, Hal Hildebrand, Connor Wood, Ken Kennedy, darrin, Mark
Gardner, William Christensen, Malcolm Ocean, Rod Davenport, Nodarius
Darjania, Cheryl Evry, Wenfeng Liang, Irving Rivas, Bill Soistman,
ReallyBored, {\x00CE}{\x2020}{\x00CF}{\x0081}{\x00CE}{\x00B7}
{\x00CF}{\x201A}
{\x00CE}{\x201D}{\x00CE}{\x00AC}{\x00CF}{\x0192}{\x00CE} {\x00BF}{\x00CF}{\x201A}, Ron Lauzon, TheFred, Paul Theodoropolous,
Doug Phillips, Les Vogel, Matt Pollard, Andres
Cordova{apostrophe}{cr}{lf}

{commabar}{leftbrace}k[{deltastile}{rightshoe}{uparrow}{dieresis}{leftbrace}1{downarrow}{omega}{rightbrace}{dieresis}k{leftarrow}{leftbrace}({omega}{notequal}{apostrophe}
{apostrophe}){leftshoe}{omega}{rightbrace}{dieresis}({omega}{notequal}{apostrophe},{apostrophe}){leftshoe}{omega}]{rightbrace}s{cr}{lf}

Mordant
taishi28012
darrin
ReallyBored
TheFred
Paul Abbott
Neil Anuskiewicz
Tim Bando
Masa Bando
George Brower
Kyle Burkholder
John Carmack
Dale Carstensen
Jonathan Cast
Christopher Chang
Gratiela Chergu
William Christensen
Michael Ciagala
Andres Cordova
James Cronin
Nodarius Darjania
Rod Davenport
Chip Davis
Killer Delicious
Sven Dowideit
Steven Evans
Cheryl Evry
Arnold F. Williams
Daniel Garber
Mark Gardner
Donald Greer
Hal Hildebrand
Martin Hohenberg
Liudmilla Karukina
Ken Kennedy
David L. Jessup
Ken LaCrosse
Clemens Ladisch
Ron Lauzon
Wenfeng Liang
Brendan Long
Jacob Lyles
Jim McCloskey
Mike Nichols
Michael Nygard
Malcolm Ocean
Doug Phillips
Mark Ping
Matt Pollard
Irving Rivas
Jan Roudaut
Dewey Sasser
John Simpson
Bill Soistman
Hsueh Sung
Jane Tang
Tom Taylor
Paul Theodoropolous
Jerod Tufte
Les Vogel
Xingyu Wang
Stan Witherspoon
Dave Witten
Connor Wood
Wojciech Woytniak
Jae Yang

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

$ cat names.txt | tr -d '\n' | sed 's/,/\n/g' | sed 's/^ //g' | awk 'NF ==
3 { print $1, $3, $2 } NF == 2 { print $1, $2 } NF ==1 { print $1 }' |
sort -k 2,2 -k 1,1 | awk 'NF == 3 { print $1, $3, $2 } NF == 2 { print
$1, $2 } NF ==1 { print $1 }'
darrin
Mordant
ReallyBored
taishi28012
TheFred
Paul Abbott
Neil Anuskiewicz
Masa Bando
Tim Bando
George Brower
Kyle Burkholder
John Carmack
Dale Carstensen
Jonathan Cast
Christopher Chang
Gratiela Chergu
William Christensen
Michael Ciagala
Andres Cordova
James Cronin
Nodarius Darjania
Rod Davenport
Chip Davis
Killer Delicious
Sven Dowideit
Steven Evans
Cheryl Evry
Daniel Garber
Mark Gardner
Donald Greer
Hal Hildebrand
Martin Hohenberg
David L. Jessup
Liudmilla Karukina
Ken Kennedy
Ken LaCrosse
Clemens Ladisch
Ron Lauzon
Wenfeng Liang
Brendan Long
Jacob Lyles
Jim McCloskey
Mike Nichols
Michael Nygard
Malcolm Ocean
Doug Phillips
Mark Ping
Matt Pollard
Irving Rivas
Jan Roudaut
Dewey Sasser
John Simpson
Bill Soistman
Hsueh Sung
Jane Tang
Tom Taylor
Paul Theodoropolous
Jerod Tufte
Les Vogel
Xingyu Wang
Arnold F. Williams
Stan Witherspoon
Dave Witten
Connor Wood
Wojciech Woytniak
Jae Yang
Άρης Δάσος


On Tue, 7 Apr 2026 23:14:41 -0400, DFS wrote:

Martin Hohenberg, Jae Yang, Tim Bando, Daniel Garber, Kyle Burkholder,
Mike Nichols, Mark Ping, Tom Taylor, Arnold F. Williams, George Brower, Michael Nygard, Brendan Long, Sven Dowideit, Dave Witten, Jonathan Cast, James Cronin, David L. Jessup, Christopher Chang, Killer Delicious,
Jacob Lyles, Neil Anuskiewicz, Mordant, Clemens Ladisch, Wojciech
Woytniak, Masa Bando, John Carmack, Xingyu Wang, Jane Tang, Steven
Evans, Jan Roudaut, Hsueh Sung, Ken LaCrosse, taishi28012, John Simpson, Jerod Tufte, Paul Abbott, Stan Witherspoon, Donald Greer, Gratiela
Chergu, Michael Ciagala, Dale Carstensen, Chip Davis, Liudmilla
Karukina, Jim McCloskey, Dewey Sasser, Hal Hildebrand, Connor Wood, Ken Kennedy, darrin, Mark Gardner, William Christensen, Malcolm Ocean, Rod Davenport, Nodarius Darjania, Cheryl Evry, Wenfeng Liang, Irving Rivas,
Bill Soistman, ReallyBored, Άρης Δάσος, Ron Lauzon, TheFred, Paul Theodoropolous, Doug Phillips, Les Vogel, Matt Pollard, Andres Cordova

Print first last (as shown above) but ordered by last first.

------------------------------------------------------------------
No peeking! ------------------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

char names[2000] = {"Martin Hohenberg, Jae Yang, Tim Bando, Daniel
Garber, Kyle Burkholder, Mike Nichols, Mark Ping, Tom Taylor, Arnold F. Williams, George Brower, Michael Nygard, Brendan Long, Sven Dowideit,
Dave Witten, Jonathan Cast, James Cronin, David L. Jessup, Christopher
Chang, Killer Delicious, Jacob Lyles, Neil Anuskiewicz, Mordant, Clemens Ladisch, Wojciech Woytniak, Masa Bando, John Carmack, Xingyu Wang, Jane
Tang, Steven Evans, Jan Roudaut, Hsueh Sung, Ken LaCrosse, taishi28012,
John Simpson, Jerod Tufte, Paul Abbott, Stan Witherspoon, Donald Greer, Gratiela Chergu, Michael Ciagala, Dale Carstensen, Chip Davis, Liudmilla Karukina, Jim McCloskey, Dewey Sasser, Hal Hildebrand, Connor Wood, Ken Kennedy, darrin, Mark Gardner, William Christensen, Malcolm Ocean, Rod Davenport, Nodarius Darjania, Cheryl Evry, Wenfeng Liang, Irving Rivas,
Bill Soistman, ReallyBored, Άρης Δάσος, Ron Lauzon, TheFred, Paul Theodoropolous, Doug Phillips, Les Vogel, Matt Pollard, Andres
Cordova"};

//count characters in a string int countchr(char *str, char chr)
{int c=0,cnt=0;while(str[c]!='\0'){if(str[c]==chr){cnt++;}c++;}return
cnt;}

//compare for qsort int comparechar( const void *a, const void *b)
{
const char **chara = (const char **)a;
const char **charb = (const char **)b;
return strcasecmp(*chara, *charb);
//return strcmp(*chara, *charb);
}

//left trim spaces void ltrim(char *str)
{
int totrim = strspn(str," ");
if (totrim > 0)
{
int len = strlen(str);
if (totrim == len)
{ str[0] = '\0'; } else
{memmove(str, str + totrim, len + 1 - totrim);}
}
}

int main(void)
{

//vars
char delim[2] = ",";
int i=0,j=0;

//number of names is commas + 1 int namecnt = countchr(names,',')

+ 1;

//name array: one column for first-last, one for last-first char
*narr[2][namecnt];

char *flname, lfname[30]; // full names char *fname,

*lname; //

part names char tmp[30]="";

// parse full names from string // then parse first and last from

full

name // add both into array char *dup = strdup(names);
while((flname = strsep(&dup,delim)) != NULL )
{
ltrim(flname);
if(countchr(flname,' ')>0)
{
lname = strrchr(flname,' ')+1;
memset(tmp, '\0', sizeof(tmp));
strncat(tmp,flname,strlen(flname)-

strlen(lname)-1);

fname = strdup(tmp);
}
else {
lname = strdup(flname);
fname = strdup("");
fname[strlen(fname)-2] = '\0';
}

sprintf(lfname,"%s %s",lname,fname); narr[0][i]=

strdup(flname);

narr[1][i]= strdup(lfname);
i++;
}

//add list of last-first names into array then sort it char
*sarr[namecnt];
for(i=0;i<namecnt;i++) {sarr[i] = narr[1][i];}
qsort(sarr, namecnt, sizeof(char*), comparechar);

//print first-last in order by last-first for(i=0;i<namecnt;i++)
{
for(j=0;j<namecnt;j++)
{
if(narr[1][j] == sarr[i])
{
printf("%d %s\n",i+1, narr[0][j]);
break;
}
}
}

return 0;
}
------------------------------------------------------------------
71 SLOC

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 16/04/2026 17:24, Bonita Montero wrote:

    sort( names.begin(), names.end(), []( const name &lhs, const name &rhs ) { return lhs.second < rhs.second; } );

I think this needs to be a case-insensitive sort.

While the OP's data only had capitalised surnames (with one exception),
their solution used a string-sensitive compare.

The exception is the name "taishi28012". With your code, that name
doesn't appear at all in the output.

If I add a dummy first name to this, then it appears last of all the
ASCII names, but before the Greek name.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 4/18/2026 5:16 AM, Rosario19 wrote:

On Tue, 7 Apr 2026 23:14:41 -0400, DFS wrote:

Martin Hohenberg, Jae Yang, Tim Bando, Daniel Garber, Kyle Burkholder,
Mike Nichols, Mark Ping, Tom Taylor, Arnold F. Williams, George Brower,
Michael Nygard, Brendan Long, Sven Dowideit, Dave Witten, Jonathan Cast,
James Cronin, David L. Jessup, Christopher Chang, Killer Delicious,
Jacob Lyles, Neil Anuskiewicz, Mordant, Clemens Ladisch, Wojciech
Woytniak, Masa Bando, John Carmack, Xingyu Wang, Jane Tang, Steven
Evans, Jan Roudaut, Hsueh Sung, Ken LaCrosse, taishi28012, John Simpson,
Jerod Tufte, Paul Abbott, Stan Witherspoon, Donald Greer, Gratiela
Chergu, Michael Ciagala, Dale Carstensen, Chip Davis, Liudmilla
Karukina, Jim McCloskey, Dewey Sasser, Hal Hildebrand, Connor Wood, Ken
Kennedy, darrin, Mark Gardner, William Christensen, Malcolm Ocean, Rod
Davenport, Nodarius Darjania, Cheryl Evry, Wenfeng Liang, Irving Rivas,
Bill Soistman, ReallyBored, ???? ?????, Ron Lauzon, TheFred, Paul
Theodoropolous, Doug Phillips, Les Vogel, Matt Pollard, Andres Cordova


Print first last (as shown above) but ordered by last first.

ot

this would be one APL program in "brace" form and its result, because
here it seems is difficult print 2 chars chars

s{leftarrow}{apostrophe}Martin Hohenberg, Jae Yang, Tim Bando,
Daniel Garber, Kyle Burkholder, Mike Nichols, Mark Ping, Tom Taylor,
Arnold F. Williams, George Brower, Michael Nygard, Brendan Long, Sven Dowideit, Dave Witten, Jonathan Cast, James Cronin, David L. Jessup, Christopher Chang, Killer Delicious, Jacob Lyles, Neil Anuskiewicz,
Mordant, Clemens Ladisch, Wojciech Woytniak, Masa Bando, John Carmack,
Xingyu Wang, Jane Tang, Steven Evans, Jan Roudaut, Hsueh Sung, Ken
LaCrosse, taishi28012, John Simpson, Jerod Tufte, Paul Abbott, Stan Witherspoon, Donald Greer, Gratiela Chergu, Michael Ciagala, Dale
Carstensen, Chip Davis, Liudmilla Karukina, Jim McCloskey, Dewey
Sasser, Hal Hildebrand, Connor Wood, Ken Kennedy, darrin, Mark
Gardner, William Christensen, Malcolm Ocean, Rod Davenport, Nodarius Darjania, Cheryl Evry, Wenfeng Liang, Irving Rivas, Bill Soistman, ReallyBored, {\x00CE}{\x2020}{\x00CF}{\x0081}{\x00CE}{\x00B7} {\x00CF}{\x201A}
{\x00CE}{\x201D}{\x00CE}{\x00AC}{\x00CF}{\x0192}{\x00CE} {\x00BF}{\x00CF}{\x201A}, Ron Lauzon, TheFred, Paul Theodoropolous,
Doug Phillips, Les Vogel, Matt Pollard, Andres
Cordova{apostrophe}{cr}{lf}

{commabar}{leftbrace}k[{deltastile}{rightshoe}{uparrow}{dieresis}{leftbrace}1{downarrow}{omega}{rightbrace}{dieresis}k{leftarrow}{leftbrace}({omega}{notequal}{apostrophe}
{apostrophe}){leftshoe}{omega}{rightbrace}{dieresis}({omega}{notequal}{apostrophe},{apostrophe}){leftshoe}{omega}]{rightbrace}s{cr}{lf}

Mordant
taishi28012
darrin
ReallyBored
TheFred
Paul Abbott
Neil Anuskiewicz

--------------------------------

Tim Bando
Masa Bando

--------------------------------
FAIL

George Brower
Kyle Burkholder
John Carmack
Dale Carstensen
Jonathan Cast
Christopher Chang
Gratiela Chergu
William Christensen
Michael Ciagala
Andres Cordova
James Cronin
Nodarius Darjania
Rod Davenport
Chip Davis
Killer Delicious
Sven Dowideit
Steven Evans
Cheryl Evry
Arnold F. Williams
Daniel Garber
Mark Gardner
Donald Greer
Hal Hildebrand
Martin Hohenberg
Liudmilla Karukina
Ken Kennedy
David L. Jessup
Ken LaCrosse
Clemens Ladisch
Ron Lauzon
Wenfeng Liang
Brendan Long
Jacob Lyles
Jim McCloskey
Mike Nichols
Michael Nygard
Malcolm Ocean
Doug Phillips
Mark Ping
Matt Pollard
Irving Rivas
Jan Roudaut
Dewey Sasser
John Simpson
Bill Soistman
Hsueh Sung
Jane Tang
Tom Taylor
Paul Theodoropolous
Jerod Tufte
Les Vogel
Xingyu Wang
Stan Witherspoon
Dave Witten
Connor Wood
Wojciech Woytniak
Jae Yang

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/04/2026 13:11, DFS wrote:

On 4/18/2026 5:16 AM, Rosario19 wrote:

On Tue, 7 Apr 2026 23:14:41 -0400, DFS  wrote:

Martin Hohenberg, Jae Yang, Tim Bando, Daniel Garber, Kyle Burkholder,
Mike Nichols, Mark Ping, Tom Taylor, Arnold F. Williams, George Brower,
Michael Nygard, Brendan Long, Sven Dowideit, Dave Witten, Jonathan Cast, >>> James Cronin, David L. Jessup, Christopher Chang, Killer Delicious,
Jacob Lyles, Neil Anuskiewicz, Mordant, Clemens Ladisch, Wojciech
Woytniak, Masa Bando, John Carmack, Xingyu Wang, Jane Tang, Steven
Evans, Jan Roudaut, Hsueh Sung, Ken LaCrosse, taishi28012, John Simpson, >>> Jerod Tufte, Paul Abbott, Stan Witherspoon, Donald Greer, Gratiela
Chergu, Michael Ciagala, Dale Carstensen, Chip Davis, Liudmilla
Karukina, Jim McCloskey, Dewey Sasser, Hal Hildebrand, Connor Wood, Ken
Kennedy, darrin, Mark Gardner, William Christensen, Malcolm Ocean, Rod
Davenport, Nodarius Darjania, Cheryl Evry, Wenfeng Liang, Irving Rivas,
Bill Soistman, ReallyBored, ???? ?????, Ron Lauzon, TheFred, Paul
Theodoropolous, Doug Phillips, Les Vogel, Matt Pollard, Andres Cordova


Print first last (as shown above) but ordered by last first.

ot

this would be one APL program in "brace" form and its result, because
here it seems is difficult print 2 chars chars

       s{leftarrow}{apostrophe}Martin Hohenberg, Jae Yang, Tim Bando, >> Daniel Garber, Kyle Burkholder, Mike Nichols, Mark Ping, Tom Taylor,
Arnold F. Williams, George Brower, Michael Nygard, Brendan Long, Sven
Dowideit, Dave Witten, Jonathan Cast, James Cronin, David L. Jessup,
Christopher Chang, Killer Delicious, Jacob Lyles, Neil Anuskiewicz,
Mordant, Clemens Ladisch, Wojciech Woytniak, Masa Bando, John Carmack,
Xingyu Wang, Jane Tang, Steven Evans, Jan Roudaut, Hsueh Sung, Ken
LaCrosse, taishi28012, John Simpson, Jerod Tufte, Paul Abbott, Stan
Witherspoon, Donald Greer, Gratiela Chergu, Michael Ciagala, Dale
Carstensen, Chip Davis, Liudmilla Karukina, Jim McCloskey, Dewey
Sasser, Hal Hildebrand, Connor Wood, Ken Kennedy, darrin, Mark
Gardner, William Christensen, Malcolm Ocean, Rod Davenport, Nodarius
Darjania, Cheryl Evry, Wenfeng Liang, Irving Rivas, Bill Soistman,
ReallyBored, {\x00CE}{\x2020}{\x00CF}{\x0081}{\x00CE}{\x00B7}
{\x00CF}{\x201A}
{\x00CE}{\x201D}{\x00CE}{\x00AC}{\x00CF}{\x0192}{\x00CE}
{\x00BF}{\x00CF}{\x201A}, Ron Lauzon, TheFred, Paul Theodoropolous,
Doug Phillips, Les Vogel, Matt Pollard, Andres
Cordova{apostrophe}{cr}{lf}

{commabar}{leftbrace}k[{deltastile}{rightshoe}{uparrow}{dieresis}
{leftbrace}1{downarrow}{omega}{rightbrace}{dieresis}k{leftarrow}
{leftbrace}({omega}{notequal}{apostrophe}
{apostrophe}){leftshoe}{omega}{rightbrace}{dieresis}({omega}{notequal}
{apostrophe},{apostrophe}){leftshoe}{omega}]{rightbrace}s{cr}{lf}

   Mordant
   taishi28012
   darrin
   ReallyBored
   TheFred
   Paul Abbott
   Neil Anuskiewicz

--------------------------------

   Tim Bando
   Masa Bando

--------------------------------
FAIL

So sorting presumably is case-sensitive, and last name first, then first
names in order?

You weren't entirely clear in your OP, where it only talks about first
and last names, but some entries have only one name, and some have three.

Perhaps some reference output should have been posted (I saw it
somewhere but can't find in the thread, and don't know if it came from you).

I posted a version in script code, but mistakenly in the cookie thread,
when I got the idea that solutions in any language were allowed. That
one sorted on last name only (but seems to get the Bandos in the right
order somehow).

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Am 18.04.2026 um 12:22 schrieb Bart:

I think this needs to be a case-insensitive sort.

While the OP's data only had capitalised surnames (with one exception), their solution used a string-sensitive compare.

The exception is the name "taishi28012". With your code, that name
doesn't appear at all in the output.

If I add a dummy first name to this, then it appears last of all the
ASCII names, but before the Greek name.

Now everything is fine: surnames without forenames are handled and
the search is case-insensitive.


#include <iostream>
#include <utility>
#include <string_view>
#include <regex>
#include <vector>
#include <algorithm>
#include <compare>

using namespace std;

static constexpr const char *Names = "Martin Hohenberg, Jae Yang, Tim
Bando, Daniel Garber, Kyle Burkholder, Mike Nichols, Mark Ping, Tom
Taylor, Arnold F. Williams, George Brower, Michael Nygard, Brendan Long,
Sven Dowideit, Dave Witten, Jonathan Cast, James Cronin, David L.
Jessup, Christopher Chang, Killer Delicious, Jacob Lyles, Neil
Anuskiewicz, Mordant, Clemens Ladisch, Wojciech Woytniak, Masa Bando,
John Carmack, Xingyu Wang, Jane Tang, Steven Evans, Jan Roudaut, Hsueh
Sung, Ken LaCrosse, taishi28012, John Simpson, Jerod Tufte, Paul Abbott,
Stan Witherspoon, Donald Greer, Gratiela Chergu, Michael Ciagala, Dale Carstensen, Chip Davis, Liudmilla Karukina, Jim McCloskey, Dewey Sasser,
Hal Hildebrand, Connor Wood, Ken Kennedy, darrin, Mark Gardner, William Christensen, Malcolm Ocean, Rod Davenport, Nodarius Darjania, Cheryl
Evry, Wenfeng Liang, Irving Rivas, Bill Soistman, ReallyBored, Άρης Δάσος, Ron Lauzon, TheFred, Paul Theodoropolous, Doug Phillips, Les Vogel, Matt Pollard, Andres Cordova";

int svicmp( string_view lhs, string_view rhs );

int main()
{
string_view svNames = ::Names;
regex
rxTotal( "\\s*([^,]+)(?:,|$)" ),
rxRvSurname( "\\s*(\\S+)" ),
rxRvGap( "\\s+" );
match_results<string_view::iterator> totalMtch;
match_results<string_view::reverse_iterator> rvMatch;
struct name { string_view forename, surname; };
vector<name> names;
for( auto itName = svNames.begin(); regex_search( itName, svNames.end(), totalMtch, rxTotal ); itName = totalMtch[0].second )
{
if( !regex_search( reverse_iterator( totalMtch[1].second ), reverse_iterator( totalMtch[1].first ), rvMatch, rxRvSurname ) )
continue;
auto
itForename = totalMtch[1].first,
itSurname = rvMatch[1].second.base(),
itSurnameEnd = rvMatch[1].first.base();
string_view surname( itSurname, itSurnameEnd ), forename;
if( regex_search( reverse_iterator( itSurname ), reverse_iterator(
itForename ), rvMatch, rxRvGap ) )
forename = string_view( itForename, rvMatch[0].second.base() );
else
if( itSurname != itForename )
continue;
names.emplace_back( forename, surname );
}
sort( names.begin(), names.end(), []( const name &lhs, const name &rhs )
{
int cmpSurname = svicmp( lhs.surname, rhs.surname );
if( cmpSurname != 0 )
return cmpSurname < 0;
return lhs.forename < rhs.forename;
} );
for( const name &nm : names )
cout << "\"" << nm.surname << "\", \"" << nm.forename << "\"" << endl;
}

int svicmp( string_view lhs, string_view rhs )
{
constexpr auto *lwtoi = +[]( char c ) -> int { return (unsigned char)tolower( c ); };
size_t c = min( lhs.size(), rhs.size() );
for( size_t i = 0; i < c; ++i )
if( int d = lwtoi( lhs[i] ) - lwtoi( rhs[i] ); d )
return d;
return lhs.size() < rhs.size();
}


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Now I've extracted the parsing part in a separate lambda. You cann
call it with pars( true_type() ) if you wnat regex-parsing. You can
call it with parse( false_type() ) if you want manual parsing (faster).

#include <iostream>
#include <utility>
#include <string_view>
#include <regex>
#include <vector>
#include <algorithm>
#include <compare>

using namespace std;

static constexpr const char *Names = "Martin Hohenberg, Jae Yang, Tim
Bando, Daniel Garber, Kyle Burkholder, Mike Nichols, Mark Ping, Tom
Taylor, Arnold F. Williams, George Brower, Michael Nygard, Brendan Long,
Sven Dowideit, Dave Witten, Jonathan Cast, James Cronin, David L.
Jessup, Christopher Chang, Killer Delicious, Jacob Lyles, Neil
Anuskiewicz, Mordant, Clemens Ladisch, Wojciech Woytniak, Masa Bando,
John Carmack, Xingyu Wang, Jane Tang, Steven Evans, Jan Roudaut, Hsueh
Sung, Ken LaCrosse, taishi28012, John Simpson, Jerod Tufte, Paul Abbott,
Stan Witherspoon, Donald Greer, Gratiela Chergu, Michael Ciagala, Dale Carstensen, Chip Davis, Liudmilla Karukina, Jim McCloskey, Dewey Sasser,
Hal Hildebrand, Connor Wood, Ken Kennedy, darrin, Mark Gardner, William Christensen, Malcolm Ocean, Rod Davenport, Nodarius Darjania, Cheryl
Evry, Wenfeng Liang, Irving Rivas, Bill Soistman, ReallyBored, Άρης Δάσος, Ron Lauzon, TheFred, Paul Theodoropolous, Doug Phillips, Les Vogel, Matt Pollard, Andres Cordova";

int svicmp( string_view lhs, string_view rhs );

int main()
{
string_view svNames = ::Names;
struct name { string_view forename, surname; };
vector<name> names;
auto parse = [&]<bool Regex>( bool_constant<Regex> )
{
if constexpr( Regex )
{
regex
rxTotal( "\\s*([^,]+)(?:,|$)" ),
rxRvSurname( "\\s*(\\S+)" ),
rxRvGap( "\\s+" );
match_results<string_view::iterator> totalMtch;
match_results<string_view::reverse_iterator> rvMatch;
for( auto itName = svNames.begin(); regex_search( itName,
svNames.end(), totalMtch, rxTotal ); itName = totalMtch[0].second )
{
if( !regex_search( reverse_iterator( totalMtch[1].second ),
reverse_iterator( totalMtch[1].first ), rvMatch, rxRvSurname ) )
continue;
auto
itForename = totalMtch[1].first,
itSurname = rvMatch[1].second.base(),
itSurnameEnd = rvMatch[1].first.base();
string_view surname( itSurname, itSurnameEnd ), forename;
if( regex_search( reverse_iterator( itSurname ), reverse_iterator(
itForename ), rvMatch, rxRvGap ) )
forename = string_view( itForename, rvMatch[0].second.base() );
else
if( itSurname != itForename )
continue;
names.emplace_back( forename, surname );
}
}
else
{
for( auto where = svNames.begin(); where != svNames.end(); )
{
static constexpr auto *whitespace = +[]( char c ) { return c == ' '
|| c == '\t' || c == '\r' || c == '\n'; };
static constexpr auto *nonWs = +[]( char c ) { return !whitespace( c
); };
auto
itNameBegin = where,
itNameEnd = find( itNameBegin, svNames.end(), ',' );
if( itNameEnd == itNameBegin )
break;
where = itNameEnd + (itNameEnd != svNames.end());
auto itSurnameEnd = find_if( reverse_iterator( itNameEnd ),
reverse_iterator( itNameBegin ), nonWs ).base();
if( itSurnameEnd == itNameBegin )
continue;
auto itSurname = find_if( reverse_iterator( itSurnameEnd ),
reverse_iterator( itNameBegin ), whitespace ).base();
string_view surname( itSurname, itSurnameEnd ), forename;
auto
itForenameEnd = find_if( reverse_iterator( itSurname ),
reverse_iterator( itNameBegin ), nonWs ).base(),
itForenameBegin = find_if( itNameBegin, itForenameEnd, nonWs );
forename = string_view( itForenameBegin, itForenameEnd );
names.emplace_back( forename, surname );
}
}
};
parse( false_type() );
sort( names.begin(), names.end(), []( const name &lhs, const name &rhs )
{
int cmpSurname = svicmp( lhs.surname, rhs.surname );
if( cmpSurname != 0 )
return cmpSurname < 0;
return svicmp( lhs.forename, rhs.forename ) < 0;
} );
for( const name &nm : names )
cout << "\"" << nm.surname << "\", \"" << nm.forename << "\"" << endl;
}

int svicmp( string_view lhs, string_view rhs )
{
constexpr auto *lwtoi = +[]( char c ) -> int { return (unsigned char)tolower( c ); };
size_t c = min( lhs.size(), rhs.size() );
for( size_t i = 0; i < c; ++i )
if( int d = lwtoi( lhs[i] ) - lwtoi( rhs[i] ); d )
return d;
return lhs.size() < rhs.size();
}
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-04-18 12:19, gggggggggggunit wrote:

$ cat names.txt | tr -d '\n' | sed 's/,/\n/g' | sed 's/^ //g' | awk 'NF ==
3 { print $1, $3, $2 } NF == 2 { print $1, $2 } NF ==1 { print $1 }' |
sort -k 2,2 -k 1,1 | awk 'NF == 3 { print $1, $3, $2 } NF == 2 { print
$1, $2 } NF ==1 { print $1 }'

Uh-oh! - Why so complicated?

(The cat is unnecessary, the tr as well, two seds can be combined,
the awk's are unnecessarily bulky, ...)

And this proposal also doesn't seem to sort the single letter data
(to be interpreted as primary key like surnames) into the sequence.

One terser way (including considering single word entities as the
name to get sorted in like a surname) can be

sed 's/, /\n/g' names.txt | awk '{print $NF"\t"$0}' |
sort |
sed 's/.*\t//'


Janis

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

In article <10s20jf$2b5i9$[email protected]>,
Janis Papanagnou <[email protected]> wrote:
...

One terser way (including considering single word entities as the
name to get sorted in like a surname) can be

sed 's/, /\n/g' names.txt | awk '{print $NF"\t"$0}' |
sort |
sed 's/.*\t//'

First, on the code of "code golfing" this: Surely, any construct of the
form: sed ... | awk ...

can be simplified into a single call to awk, since (with exceptions so few
as to be irrelevant) anything sed can do, awk can do.

And, of course, whatever the above command line is doing (I haven't
followed this thread closely enough to know what it is actually about), can
be done in a single invocation of GAWK (or TAWK), which has built-in
sorting. It could also be done in a single invocation of any AWK (or Perl
or whatever) if you are willing to write your own sort routine.

And, of course, other posters should be along any minute with Perl (or Ruby
or Python or ...) one-liners as well.

Second, I would imagine that whoever constructed the original line (to
which you responded) probably developed it from scratch by stringing things together and is quite proud of the effort, so he saw no need to trim it
down for posting. Hence the appearance as it is.
--
"It does a lot of things half well and it's just a garbage heap of ideas that are
mutually exclusive."

- Ken Thompson, on C++ -
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

In article <10s2o7p$25ao7$[email protected]>,
Kenny McCormack <[email protected]> wrote:

In article <10s20jf$2b5i9$[email protected]>,
Janis Papanagnou <[email protected]> wrote:
...

One terser way (including considering single word entities as the
name to get sorted in like a surname) can be

sed 's/, /\n/g' names.txt | awk '{print $NF"\t"$0}' |
sort |
sed 's/.*\t//'

First, on the code of "code golfing" this: Surely, any construct of the
form: sed ... | awk ...

can be simplified into a single call to awk, since (with exceptions so few
as to be irrelevant) anything sed can do, awk can do.

Probably. But I'm not sure that's all that useful in the
general case. The `sed` command here is translating logical
records into lines; the `awk` command is then prefixing those
with the last token (and a tab). Then sorting, so that records
are sorted by the last token, and then removing that token (and
the tab).

And, of course, whatever the above command line is doing (I haven't
followed this thread closely enough to know what it is actually about), can >be done in a single invocation of GAWK (or TAWK), which has built-in
sorting. It could also be done in a single invocation of any AWK (or Perl
or whatever) if you are willing to write your own sort routine.

One could, of course, do this in a single `awk` invocation. I
suspect it would be rather more awkward.

And, of course, other posters should be along any minute with Perl (or Ruby >or Python or ...) one-liners as well.

Second, I would imagine that whoever constructed the original line (to
which you responded) probably developed it from scratch by stringing things >together and is quite proud of the effort, so he saw no need to trim it
down for posting. Hence the appearance as it is.

*shrug* there's always a possibility to learn.

I saw this and it made me wonder whether one could just use the
`sort` command directly, and tell it to sort using the second
field. However, some records don't _have_ a second key (they're
single word) and some have 3 (some records have a middle initial
for instance); these are things that the `sort` command just
cannot handle, sadly.

Then it made me think that it would be nice if there was a way
to rotate the fields on a line; sadly, I'm not aware of a
standard command that does that. But it's not too hard to write
as its own little script.

You then have something like,

`sed 's/, */\n'g' data | rotwords -r | sort | rotwords -l`

`rotwords -r` does a right-rotation (so the last field is moved
to the front) and `rotwords -l` does a left rotation (so the
first field is moved to the rear).

It was kind of a fun exercise.

- Dan C.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sat, 18 Apr 2026 11:16:48 +0200, Rosario19 wrote:

{commabar}{leftbrace}k[{deltastile}{rightshoe}{uparrow}{dieresis}{leftbrace}1{downarrow}{omega}{rightbrace}{dieresis}k{leftarrow}{leftbrace}({omega}{notequal}{apostrophe}
{apostrophe}){leftshoe}{omega}{rightbrace}{dieresis}({omega}{notequal}{apostrophe},{apostrophe}){leftshoe}{omega}]{rightbrace}s{cr}{lf}

Mordant
taishi28012
darrin
ReallyBored
TheFred
Paul Abbott
Neil Anuskiewicz
Tim Bando
Masa Bando
George Brower
Kyle Burkholder
John Carmack
Dale Carstensen
Jonathan Cast
Christopher Chang
Gratiela Chergu
William Christensen
Michael Ciagala
Andres Cordova
James Cronin
Nodarius Darjania
Rod Davenport
Chip Davis
Killer Delicious
Sven Dowideit
Steven Evans
Cheryl Evry
Arnold F. Williams
Daniel Garber
Mark Gardner
Donald Greer
Hal Hildebrand
Martin Hohenberg
Liudmilla Karukina
Ken Kennedy
David L. Jessup
Ken LaCrosse
Clemens Ladisch
Ron Lauzon
Wenfeng Liang
Brendan Long
Jacob Lyles
Jim McCloskey
Mike Nichols
Michael Nygard
Malcolm Ocean
Doug Phillips
Mark Ping
Matt Pollard
Irving Rivas
Jan Roudaut
Dewey Sasser
John Simpson
Bill Soistman
Hsueh Sung
Jane Tang
Tom Taylor
Paul Theodoropolous
Jerod Tufte
Les Vogel
Xingyu Wang
Stan Witherspoon
Dave Witten
Connor Wood
Wojciech Woytniak
Jae Yang

this is a C version

#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <string.h>

#define R return
#define P printf

char names[] = {"Martin Hohenberg, Jae Yang, Tim Bando, Daniel \
Garber, Kyle Burkholder, Mike Nichols, Mark Ping, Tom Taylor, Arnold
F. \
Williams, George Brower, Michael Nygard, Brendan Long, Sven Dowideit,
\
Dave Witten, Jonathan Cast, James Cronin, David L. Jessup, Christopher
\
Chang, Killer Delicious, Jacob Lyles, Neil Anuskiewicz, Mordant,
Clemens \
Ladisch, Wojciech Woytniak, Masa Bando, John Carmack, Xingyu Wang,
Jane \
Tang, Steven Evans, Jan Roudaut, Hsueh Sung, Ken LaCrosse,
taishi28012, \
John Simpson, Jerod Tufte, Paul Abbott, Stan Witherspoon, Donald
Greer, \
Gratiela Chergu, Michael Ciagala, Dale Carstensen, Chip Davis,
Liudmilla \
Karukina, Jim McCloskey, Dewey Sasser, Hal Hildebrand, Connor Wood,
Ken \
Kennedy, darrin, Mark Gardner, William Christensen, Malcolm Ocean, Rod
\
Davenport, Nodarius Darjania, Cheryl Evry, Wenfeng Liang, Irving
Rivas, \
Bill Soistman, ReallyBored, Ron Lauzon, TheFred, Paul \
Theodoropolous, Doug Phillips, Les Vogel, Matt Pollard, Andres
Cordova"};

int toNextWord(char* a)
{int k,c,cnt;
if(a[0]==0) R 0;
if(a[1]==0||a[1]==',') R 0;
k=0;
if(a[k]==',')++k;
for(cnt=0;c=a[k];++k)
{if(c==0||c==',') R 0;
if(isalnum(c))
{if(cnt==1) R k;
for(++cnt;isalnum(c=a[k]);++k);
if(c==','||c==0)R 0;
}
}
R 0;
}

char** rompiVettori(char* a)
{int i, c, cnt, j, k;
char **p, pc;

for(i=0,cnt=0;c=a[i];++i)
{if(c==',')++cnt;if(i>2e6||cnt>2e4) R 0;}
cnt+=8;p=(char**)malloc(cnt*sizeof(char*));if(p==0) R 0;
p[0]=a;
for(i=0,j=1;c=a[i];++i)
{if(c==',')p[j++]=a+i;
if(i>2e6||j>2e4){free(p); R 0;}
}
k=j;
for(j=0;j<k;++j)
{i=toNextWord(p[j]);
p[j]=p[j]+i;
//P("%x %c%c ",p[j],p[j][0], p[j][1]);
}
p[j]=0;
R p;
}

int wordcmp(const void* aa, const void* bb)
{int ca,cb,i,j;
char *a=*(char**)aa, *b=*(char**)bb;

if(a==0)R -1;
if(b==0)R 1;
//P("%x %x\n", a, b);
if(!isalnum(*a))R -1;
if(!isalnum(*b))R 1;
for(i=0;(ca=a[i])&&(cb=b[i]);++i)
{if(!isalnum(ca)) R -1;
if(!isalnum(cb)) R 1;
ca=toupper(ca); cb=toupper(cb);
if(ca<cb)R -1;
if(ca>cb)R 1;
}
R -1;
}

int main()
{int i,j,c;
char **p=rompiVettori(names), *pc, *pf;

if(p==0)R 0;

for(j=0;names[j];++j);
pf=names+j;

/*
P("fine=%x p=%x\n", pf,p);
P("p[0]=%x names=%x\n", p[0], names);
for(i=0;p[i];++i)
P("%c%c ", p[i][0], p[i][1]);
P("i=%d\n", i);
*/

for(i=0;p[i];++i)
;
qsort(p,i,sizeof(char*),wordcmp);

for(i=0;p[i];++i)
{for(pc=p[i];pc>names;--pc)
if(*pc==',')break;
if(*pc==',')++pc;
for(j=0;pc+j<pf&&isspace(pc[j]);++j);
for(;pc+j<pf&&(c=pc[j])&&','!=c;++j)
{P("%c", c);}
P("\n");
}

free(p);
return 0;
}

---------------------------------
result:
---------------------------------
TheFred
taishi28012
darrin
ReallyBored
Mordant
Paul Abbott
Neil Anuskiewicz
Tim Bando
Masa Bando
George Brower
Kyle Burkholder
John Carmack
Dale Carstensen
Jonathan Cast
Christopher Chang
Gratiela Chergu
William Christensen
Michael Ciagala
Andres Cordova
James Cronin
Nodarius Darjania
Rod Davenport
Chip Davis
Killer Delicious
Sven Dowideit
Steven Evans
Cheryl Evry
Arnold F. Williams
Daniel Garber
Mark Gardner
Donald Greer
Hal Hildebrand
Martin Hohenberg
Liudmilla Karukina
Ken Kennedy
David L. Jessup
Ken LaCrosse
Clemens Ladisch
Ron Lauzon
Wenfeng Liang
Brendan Long
Jacob Lyles
Jim McCloskey
Mike Nichols
Michael Nygard
Malcolm Ocean
Doug Phillips
Mark Ping
Matt Pollard
Irving Rivas
Jan Roudaut
Dewey Sasser
John Simpson
Bill Soistman
Hsueh Sung
Jane Tang
Tom Taylor
Paul Theodoropolous
Jerod Tufte
Les Vogel
Xingyu Wang
Stan Witherspoon
Dave Witten
Connor Wood
Wojciech Woytniak
Jae Yang

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 4/20/2026 3:20 PM, Rosario19 wrote:

this is a C version

<snip>

---------------------------------
result:
---------------------------------
TheFred
taishi28012
darrin
ReallyBored
Mordant
Paul Abbott
Neil Anuskiewicz

------------------

Tim Bando
Masa Bando

------------------
fail

George Brower
Kyle Burkholder
John Carmack
Dale Carstensen
Jonathan Cast
Christopher Chang
Gratiela Chergu
William Christensen
Michael Ciagala
Andres Cordova
James Cronin
Nodarius Darjania
Rod Davenport
Chip Davis
Killer Delicious
Sven Dowideit
Steven Evans
Cheryl Evry

------------------------

Arnold F. Williams

------------------------
fail

Daniel Garber
Mark Gardner
Donald Greer
Hal Hildebrand
Martin Hohenberg
Liudmilla Karukina
Ken Kennedy
David L. Jessup
Ken LaCrosse
Clemens Ladisch
Ron Lauzon
Wenfeng Liang
Brendan Long
Jacob Lyles
Jim McCloskey
Mike Nichols
Michael Nygard
Malcolm Ocean
Doug Phillips
Mark Ping
Matt Pollard
Irving Rivas
Jan Roudaut
Dewey Sasser
John Simpson
Bill Soistman
Hsueh Sung
Jane Tang
Tom Taylor
Paul Theodoropolous
Jerod Tufte
Les Vogel
Xingyu Wang
Stan Witherspoon
Dave Witten
Connor Wood
Wojciech Woytniak
Jae Yang

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Rosario19 <[email protected]d> writes:
[...]

this is a C version

[...]

#define R return
#define P printf

Nope.

[...]
--
Keith Thompson (The_Other_Keith) [email protected]
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sat, 18 Apr 2026 11:16:48 +0200, Rosario19 wrote:

{commabar}{leftbrace}k[{deltastile}{rightshoe}{uparrow}{dieresis}{leftbrace}1{downarrow}{omega}{rightbrace}{dieresis}k{leftarrow}{leftbrace}({omega}{notequal}{apostrophe}
{apostrophe}){leftshoe}{omega}{rightbrace}{dieresis}({omega}{notequal}{apostrophe},{apostrophe}){leftshoe}{omega}]{rightbrace}s{cr}{lf}

{commabar}{leftbrace}k[{deltastile}{rightshoe}{uparrow}{dieresis}{leftbrace}1{downarrow}{omega}{rightbrace}{dieresis}k{leftarrow}{leftbrace}({omega}{notequal}{apostrophe}
{apostrophe}){leftshoe}{omega}{rightbrace}{dieresis}({omega}{notequal}{apostrophe},{apostrophe}){leftshoe}{omega}]{rightbrace}s{cr}{lf}

they are 40 chars if one not count input lenght and the assignament to
a varible of it.

The comment:

?{k[???¨{1??}¨k?{(??' ')??}¨(??',')??]}s
s input -------------------------------------------------- ({omega}{notequal}{apostrophe},{apostrophe}){leftshoe}{omega}
(??',')?? break the input s=? in the
way each element is a string that contain elements between ,, -------------------------------------------------- {leftbrace}({omega}{notequal}{apostrophe}{apostrophe}){leftshoe}{omega}{rightbrace}{dieresis}
{(??' ')??}¨ break each element of
elements the above result array for separate name and surname --------------------------------------------------
k{leftarrow}
k?
call that k, k is a list contain elements as ('firstName',
'secondname')
-------------------------------------------------- {leftbrace}1{downarrow}{omega}{rightbrace}{dieresis}
{1??}¨ from each element of k, cut
the first
--------------------------------------------------
{uparrow}{dieresis}
?¨ so remain the second...
disclose it
--------------------------------------------------
{rightshoe}
? build one matrix of the second names this is
only because ? return indices ordered lexicographic on lines --------------------------------------------------
{deltastile}
? order indices --------------------------------------------------
{k[?..........] show k of these index --------------------------------------------------
{commabar}
? show one name surname for line

for me in APL the process of programming is show in the screen each
change of input using the next function (or imagine that)
in C the same.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Tue, 21 Apr 2026 05:00:56 +0200, Rosario19 wrote:

for me in APL the process of programming is show in the screen each
change of input using the next function (or imagine that)
in C the same.

In C there is to think more than APL for edge cases that can happen
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Mon, 20 Apr 2026 16:43:28 -0400, DFS wrote:

On 4/20/2026 3:20 PM, Rosario19 wrote:

this is a C version

<snip>

---------------------------------
result:
---------------------------------
TheFred
taishi28012
darrin
ReallyBored
Mordant
Paul Abbott
Neil Anuskiewicz

------------------

Tim Bando
Masa Bando

------------------
fail

the spec.. not speak about order by first name but only for the second
name. So that is all UB

George Brower
Kyle Burkholder
John Carmack
Dale Carstensen
Jonathan Cast
Christopher Chang
Gratiela Chergu
William Christensen
Michael Ciagala
Andres Cordova
James Cronin
Nodarius Darjania
Rod Davenport
Chip Davis
Killer Delicious
Sven Dowideit
Steven Evans
Cheryl Evry

------------------------

Arnold F. Williams

------------------------
fail

the spec.. not speak about if the second names is just F. so F is a
valid second name.

Daniel Garber
Mark Gardner
Donald Greer
Hal Hildebrand
Martin Hohenberg
Liudmilla Karukina
Ken Kennedy
David L. Jessup
Ken LaCrosse
Clemens Ladisch
Ron Lauzon
Wenfeng Liang
Brendan Long
Jacob Lyles
Jim McCloskey
Mike Nichols
Michael Nygard
Malcolm Ocean
Doug Phillips
Mark Ping
Matt Pollard
Irving Rivas
Jan Roudaut
Dewey Sasser
John Simpson
Bill Soistman
Hsueh Sung
Jane Tang
Tom Taylor
Paul Theodoropolous
Jerod Tufte
Les Vogel
Xingyu Wang
Stan Witherspoon
Dave Witten
Connor Wood
Wojciech Woytniak
Jae Yang

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 4/20/2026 11:09 PM, Rosario19 wrote:

On Mon, 20 Apr 2026 16:43:28 -0400, DFS wrote:

On 4/20/2026 3:20 PM, Rosario19 wrote:

this is a C version

<snip>

---------------------------------
result:
---------------------------------
TheFred
taishi28012
darrin
ReallyBored
Mordant
Paul Abbott
Neil Anuskiewicz

------------------

Tim Bando
Masa Bando

------------------
fail

the spec.. not speak about order by first name but only for the second
name. So that is all UB

The 'spec' was clear: order by last, first.

George Brower
Kyle Burkholder
John Carmack
Dale Carstensen
Jonathan Cast
Christopher Chang
Gratiela Chergu
William Christensen
Michael Ciagala
Andres Cordova
James Cronin
Nodarius Darjania
Rod Davenport
Chip Davis
Killer Delicious
Sven Dowideit
Steven Evans
Cheryl Evry

------------------------

Arnold F. Williams

------------------------
fail

the spec.. not speak about if the second names is just F. so F is a
valid second name.

"Williams" is the last name, not the second name.

The 'spec' was clear: order by last, first.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

In article <10s653e$11uo1$[email protected]>,
Keith Thompson <[email protected]> wrote:

Rosario19 <[email protected]d> writes:
[...]

this is a C version

[...]

#define R return
#define P printf

Nope.

[...]

I think they put stuff like that in their postings just to piss you off.

They know how easy it is to light you up.
--
Never, ever, ever forget that "Both sides do it" is strictly a Republican meme.

It is always the side that sucks that insists on saying "Well, you suck, too".

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 21/04/2026 13:46, DFS wrote:

On 4/20/2026 11:09 PM, Rosario19 wrote:

On Mon, 20 Apr 2026 16:43:28 -0400, DFS wrote:

On 4/20/2026 3:20 PM, Rosario19 wrote:

this is a C version

<snip>

---------------------------------
result:
---------------------------------
TheFred
taishi28012
darrin
ReallyBored
Mordant
Paul Abbott
Neil Anuskiewicz

------------------

Tim Bando
Masa Bando

------------------
fail

the spec.. not speak about order by first name but only for the second
name. So that is all UB

The 'spec' was clear: order by last, first.

The spec didn't mention case-sensitive compare.

It didn't mention what happens when there is one name.

It didn't mention what happens when there are three or more names, or
middle initials.

It didn't say anything about how much white space, or how much less,
could be anticipated. So any new input that varies from your example
might not work.

It didn't give any examples of what the output needs to look, at least
not in your OP. (They can see it by running your submission, but it says
no peeking.)


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 4/21/2026 11:08 AM, Bart wrote:

On 21/04/2026 13:46, DFS wrote:

On 4/20/2026 11:09 PM, Rosario19 wrote:

On Mon, 20 Apr 2026 16:43:28 -0400, DFS wrote:

On 4/20/2026 3:20 PM, Rosario19 wrote:

this is a C version

<snip>

---------------------------------
result:
---------------------------------
TheFred
taishi28012
darrin
ReallyBored
Mordant
Paul Abbott
Neil Anuskiewicz

------------------

Tim Bando
Masa Bando

------------------
fail

the spec.. not speak about order by first name but only for the second
name. So that is all UB

The 'spec' was clear: order by last, first.

The spec didn't mention case-sensitive compare.

It didn't mention what happens when there is one name.

It didn't mention what happens when there are three or more names, or
middle initials.

It didn't say anything about how much white space, or how much less,

could be anticipated. So any new input that varies from your example
might not work.

It didn't give any examples of what the output needs to look, at least
not in your OP. (They can see it by running your submission, but it says
no peeking.)

You don't really need all that handholding do you?

None of those issues would be typical of what the PHB would ask you to
do. "Sort this list by last name then first name" is all I would expect
to get. Asking about case-sensitivity and 4 names and whitespace would
make you look like a ninny.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 21/04/2026 16:33, DFS wrote:

On 4/21/2026 11:08 AM, Bart wrote:

On 21/04/2026 13:46, DFS wrote:

On 4/20/2026 11:09 PM, Rosario19 wrote:

On Mon, 20 Apr 2026 16:43:28 -0400, DFS wrote:

On 4/20/2026 3:20 PM, Rosario19 wrote:

this is a C version

<snip>

---------------------------------
result:
---------------------------------
TheFred
taishi28012
darrin
ReallyBored
Mordant
Paul Abbott
Neil Anuskiewicz

------------------

Tim Bando
Masa Bando

------------------
fail

the spec.. not speak about order by first name but only for the second >>>> name. So that is all UB

The 'spec' was clear: order by last, first.

The spec didn't mention case-sensitive compare.

It didn't mention what happens when there is one name.

It didn't mention what happens when there are three or more names, or
middle initials.

It didn't say anything about how much white space, or how much less,

could be anticipated. So any new input that varies from your example
might not work.

It didn't give any examples of what the output needs to look, at least
not in your OP. (They can see it by running your submission, but it
says no peeking.)

You don't really need all that handholding do you?

None of those issues would be typical of what the PHB would ask you to
do.  "Sort this list by last name then first name" is all I would expect
to get.  Asking about case-sensitivity and 4 names and whitespace would make you look like a ninny.

So you don't care? Then your specification is sloppy.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Bart <[email protected]> writes:

On 21/04/2026 16:33, DFS wrote:

On 4/21/2026 11:08 AM, Bart wrote:

It didn't give any examples of what the output needs to look, at least
not in your OP. (They can see it by running your submission, but it
says no peeking.)

You don't really need all that handholding do you?

None of those issues would be typical of what the PHB would ask you to
do.  "Sort this list by last name then first name" is all I would expect >> to get.  Asking about case-sensitivity and 4 names and whitespace would
make you look like a ninny.

You seem to be confusing a comic strip with reality.

In the real world, for professional developers, detailed
specifications are common. Forty years ago, detailed
specifications were common (we had three levels of
specification for each project back in 1983; a concept
spec, a detailed specification and a test specification).

Even the two startups I've been associated with had clear
and concise specifications for each project.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Tue, 21 Apr 2026 17:38:03 GMT
[email protected] (Scott Lurndal) wrote:

Bart <[email protected]> writes:

On 21/04/2026 16:33, DFS wrote:

On 4/21/2026 11:08 AM, Bart wrote:

It didn't give any examples of what the output needs to look, at
least not in your OP. (They can see it by running your
submission, but it says no peeking.)

You don't really need all that handholding do you?

None of those issues would be typical of what the PHB would ask
you to do.  "Sort this list by last name then first name" is all
I would expect to get.  Asking about case-sensitivity and 4 names
and whitespace would make you look like a ninny.

You seem to be confusing a comic strip with reality.

In the real world, for professional developers, detailed
specifications are common. Forty years ago, detailed
specifications were common (we had three levels of
specification for each project back in 1983; a concept
spec, a detailed specification and a test specification).

Even the two startups I've been associated with had clear
and concise specifications for each project.

Methinks, the segment of the industry that employed you for last nn
(40?) years is an exception rather than rule.
In industry as a whole imprecise specs are far more common. Also, specs
are not constant. If the software is user-facing then the biggest batch
of clarifications of the spec tend to come after alpha version was
shipped to friendly customers. But even after that if the project is
not dead then there tends to be continuous flow of changes and
clarifications of specs.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Michael S <[email protected]> writes:

On Tue, 21 Apr 2026 17:38:03 GMT
[email protected] (Scott Lurndal) wrote:

Bart <[email protected]> writes:

On 21/04/2026 16:33, DFS wrote: =20

On 4/21/2026 11:08 AM, Bart wrote: =20

=20

It didn't give any examples of what the output needs to look, at
least not in your OP. (They can see it by running your
submission, but it says no peeking.) =20

=20
=20
You don't really need all that handholding do you?
=20
None of those issues would be typical of what the PHB would ask
you to do.=C2=A0 "Sort this list by last name then first name" is all
I would expect to get.=C2=A0 Asking about case-sensitivity and 4 names
and whitespace would make you look like a ninny. =20

=20
You seem to be confusing a comic strip with reality.
=20
In the real world, for professional developers, detailed
specifications are common. Forty years ago, detailed
specifications were common (we had three levels of
specification for each project back in 1983; a concept
spec, a detailed specification and a test specification).
=20
Even the two startups I've been associated with had clear
and concise specifications for each project.
=20

Methinks, the segment of the industry that employed you for last nn
(40?) years is an exception rather than rule.

Computer system manufacturers and fabless semiconductor
companies. Mainframes, Minicomputers, MPP machines, complex SOCs.

Operating systems, hypervisors, simulators, firmware.

Granted, I've never worked in web services space (aside a
couple of years at the dot-com bust spent working on a Java-based B2B XML data-flow engine with some of the ex-SUN Java developers).

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 4/21/2026 6:00 AM, Kenny McCormack wrote:

In article <10s653e$11uo1$[email protected]>,
Keith Thompson <[email protected]> wrote:

Rosario19 <[email protected]d> writes:
[...]

this is a C version

[...]

#define R return
#define P printf

Nope.

[...]

I think they put stuff like that in their postings just to piss you off.

They know how easy it is to light you up.

Humm... I have tried to abstract away using macros. So, for say, ct_np_x86_foo_bar,

#define ct_foo_bar ct_np_x86_foo_bar

?
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 4/21/2026 1:25 PM, Bart wrote:

On 21/04/2026 16:33, DFS wrote:

On 4/21/2026 11:08 AM, Bart wrote:

On 21/04/2026 13:46, DFS wrote:

On 4/20/2026 11:09 PM, Rosario19 wrote:

On Mon, 20 Apr 2026 16:43:28 -0400, DFS wrote:

On 4/20/2026 3:20 PM, Rosario19 wrote:

this is a C version

<snip>

---------------------------------
result:
---------------------------------
TheFred
taishi28012
darrin
ReallyBored
Mordant
Paul Abbott
Neil Anuskiewicz

------------------

Tim Bando
Masa Bando

------------------
fail

the spec.. not speak about order by first name but only for the second >>>>> name. So that is all UB

The 'spec' was clear: order by last, first.

The spec didn't mention case-sensitive compare.

It didn't mention what happens when there is one name.

It didn't mention what happens when there are three or more names, or
middle initials.

It didn't say anything about how much white space, or how much less, >>> could be anticipated. So any new input that varies from your example

might not work.

It didn't give any examples of what the output needs to look, at
least not in your OP. (They can see it by running your submission,
but it says no peeking.)

You don't really need all that handholding do you?

None of those issues would be typical of what the PHB would ask you to
do.  "Sort this list by last name then first name" is all I would
expect to get.  Asking about case-sensitivity and 4 names and
whitespace would make you look like a ninny.

So you don't care? Then your specification is sloppy.

You misspelled realistic.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 21/04/2026 21:31, DFS wrote:

On 4/21/2026 1:25 PM, Bart wrote:

On 21/04/2026 16:33, DFS wrote:

On 4/21/2026 11:08 AM, Bart wrote:

On 21/04/2026 13:46, DFS wrote:

On 4/20/2026 11:09 PM, Rosario19 wrote:

On Mon, 20 Apr 2026 16:43:28 -0400, DFS wrote:

On 4/20/2026 3:20 PM, Rosario19 wrote:

this is a C version

<snip>

---------------------------------
result:
---------------------------------
TheFred
taishi28012
darrin
ReallyBored
Mordant
Paul Abbott
Neil Anuskiewicz

------------------

Tim Bando
Masa Bando

------------------
fail

the spec.. not speak about order by first name but only for the
second
name. So that is all UB

The 'spec' was clear: order by last, first.

The spec didn't mention case-sensitive compare.

It didn't mention what happens when there is one name.

It didn't mention what happens when there are three or more names, or
middle initials.

It didn't say anything about how much white space, or how much

less,

could be anticipated. So any new input that varies from your example
might not work.

It didn't give any examples of what the output needs to look, at
least not in your OP. (They can see it by running your submission,
but it says no peeking.)

You don't really need all that handholding do you?

None of those issues would be typical of what the PHB would ask you
to do.  "Sort this list by last name then first name" is all I would
expect to get.  Asking about case-sensitivity and 4 names and
whitespace would make you look like a ninny.

So you don't care? Then your specification is sloppy.

You misspelled realistic.

If there is no proper spec then here's my submission:

#include <stdio.h>

int main() {
puts(
"1 Paul Abbott\n"
"2 Neil Anuskiewicz\n"
"3 Masa Bando\n"
"4 Tim Bando\n"
"5 George Brower\n"
"6 Kyle Burkholder\n"
"7 John Carmack\n"
"8 Dale Carstensen\n"
"9 Jonathan Cast\n"
"10 Christopher Chang\n"
"11 Gratiela Chergu\n"
"12 William Christensen\n"
"13 Michael Ciagala\n"
"14 Andres Cordova\n"
"15 James Cronin\n"
"16 Nodarius Darjania\n"
"17 darrin\n"
"18 Rod Davenport\n"
"19 Chip Davis\n"
"20 Killer Delicious\n"
"21 Sven Dowideit\n"
"22 Steven Evans\n"
"23 Cheryl Evry\n"
"24 Daniel Garber\n"
"25 Mark Gardner\n"
"26 Donald Greer\n"
"27 Hal Hildebrand\n"
"28 Martin Hohenberg\n"
"29 David L. Jessup\n"
"30 Liudmilla Karukina\n"
"31 Ken Kennedy\n"
"32 Ken LaCrosse\n"
"33 Clemens Ladisch\n"
"34 Ron Lauzon\n"
"35 Wenfeng Liang\n"
"36 Brendan Long\n"
"37 Jacob Lyles\n"
"38 Jim McCloskey\n"
"39 Mordant\n"
"40 Mike Nichols\n"
"41 Michael Nygard\n"
"42 Malcolm Ocean\n"
"43 Doug Phillips\n"
"44 Mark Ping\n"
"45 Matt Pollard\n"
"46 ReallyBored\n"
"47 Irving Rivas\n"
"48 Jan Roudaut\n"
"49 Dewey Sasser\n"
"50 John Simpson\n"
"51 Bill Soistman\n"
"52 Hsueh Sung\n"
"53 taishi28012\n"
"54 Jane Tang\n"
"55 Tom Taylor\n"
"56 TheFred\n"
"57 Paul Theodoropolous\n"
"58 Jerod Tufte\n"
"59 Les Vogel\n"
"60 Xingyu Wang\n"
"61 Arnold F. Williams\n"
"62 Stan Witherspoon\n"
"63 Dave Witten\n"
"64 Connor Wood\n"
"65 Wojciech Woytniak\n"
"66 Jae Yang\n"
"67 Άρης Δάσος\n"
);
}


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-04-19 21:32, Dan Cross wrote:

In article <10s2o7p$25ao7$[email protected]>,
Kenny McCormack <[email protected]> wrote:

In article <10s20jf$2b5i9$[email protected]>,
Janis Papanagnou <[email protected]> wrote:
...

sed 's/, /\n/g' names.txt | awk '{print $NF"\t"$0}' |
sort |
sed 's/.*\t//'

First, on the code of "code golfing" this: Surely, any construct of the
form: sed ... | awk ...

Probably. But I'm not sure that's all that useful in the
general case. The `sed` command here is translating logical
records into lines; the `awk` command is then prefixing those
with the last token (and a tab). Then sorting, so that records
are sorted by the last token, and then removing that token (and
the tab).

The way I did above is a generally applicable pattern (to keep
the 'sort' simple), it can also be extended to multi-level keys.

And, of course, whatever the above command line is doing [...]

One could, of course, do this in a single `awk` invocation. I
suspect it would be rather more awkward.

Indeed. (That was actually why I used the simple 'sed' substitution
here.)

[...]

[...]

I saw this and it made me wonder whether one could just use the
`sort` command directly, and tell it to sort using the second
field. However, some records don't _have_ a second key (they're
single word) and some have 3 (some records have a middle initial
for instance); these are things that the `sort` command just
cannot handle, sadly.

Exactly. The other poster's code tried to do that field rotation
with the bulky Awk code (but he did it wrong, and the input data
was so unstructured/trashy anyway).

If the input data quality would be better (WRT consistent number
of fields or sensible separation of fields by separators) then
the shell code could be made even more simple. Fixing the data
quality in the first place would generally be my first priority.
(But okay, here we have what was provided.)

Then it made me think that it would be nice if there was a way
to rotate the fields on a line; sadly, I'm not aware of a
standard command that does that. But it's not too hard to write
as its own little script.

You then have something like,

`sed 's/, */\n'g' data | rotwords -r | sort | rotwords -l`

`rotwords -r` does a right-rotation (so the last field is moved
to the front) and `rotwords -l` does a left rotation (so the
first field is moved to the rear).

It was kind of a fun exercise.

Yes. Just note that rotation might fit here (and certainly also
in other application cases) but not as general method to identify
the key-components in the specific desired sorting order.

Janis

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-04-21 20:22, Scott Lurndal wrote:

Michael S <[email protected]> writes:

Methinks, the segment of the industry that employed you for last nn
(40?) years is an exception rather than rule.

Computer system manufacturers and fabless semiconductor
companies. Mainframes, Minicomputers, MPP machines, complex SOCs.

Operating systems, hypervisors, simulators, firmware.

Granted, I've never worked in web services space (aside a
couple of years at the dot-com bust spent working on a Java-based B2B XML data-flow engine with some of the ex-SUN Java developers).

I've had the opportunity to work in various professional IT contexts
where many levels of specifications were standard; telecommunication,
financial services, government, and I know that this is also standard
in aviation, automotive, healthcare, and in running computing centers.

(I don't know where the other poster got his impression from. - Maybe
because of so many bad-quality software being around?)

Janis

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 21/04/2026 19:50, Michael S wrote:

On Tue, 21 Apr 2026 17:38:03 GMT
[email protected] (Scott Lurndal) wrote:

Bart <[email protected]> writes:

On 21/04/2026 16:33, DFS wrote:

On 4/21/2026 11:08 AM, Bart wrote:

It didn't give any examples of what the output needs to look, at
least not in your OP. (They can see it by running your
submission, but it says no peeking.)

You don't really need all that handholding do you?

None of those issues would be typical of what the PHB would ask
you to do.  "Sort this list by last name then first name" is all
I would expect to get.  Asking about case-sensitivity and 4 names
and whitespace would make you look like a ninny.

You seem to be confusing a comic strip with reality.

In the real world, for professional developers, detailed
specifications are common. Forty years ago, detailed
specifications were common (we had three levels of
specification for each project back in 1983; a concept
spec, a detailed specification and a test specification).

Even the two startups I've been associated with had clear
and concise specifications for each project.

Methinks, the segment of the industry that employed you for last nn
(40?) years is an exception rather than rule.
In industry as a whole imprecise specs are far more common. Also, specs
are not constant. If the software is user-facing then the biggest batch
of clarifications of the spec tend to come after alpha version was
shipped to friendly customers. But even after that if the project is
not dead then there tends to be continuous flow of changes and
clarifications of specs.

Or perhaps he has just been lucky.

I've had specifications (for hardware and software - we typically do
both) from customers that were hundreds of pages long, so detailed that
they were basically impossible to fulfil. At the other end of the
scale, we made a control system for a CNC saw machine where the only
concrete specification was the colour it should be painted. Often the
process of helping turning customers' ideas into some kind of reasonable specification is part of the service we provide. And usually there is a continuum as specifications change along the way (as you describe).

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 4/16/2026 12:24 PM, Bonita Montero wrote:

As usual - in a superior language.

I found the definitive explanation of the visual impact of C++:

"C++ looks like someone threw up on your screen"

https://www.quora.com/Which-programming-language-has-the-most-visually-clean-syntax-in-your-opinion

#include <iostream>
#include <utility>
#include <string_view>
#include <regex>
#include <vector>
#include <algorithm>

using namespace std;

static constexpr string_view Names = "Martin Hohenberg, Jae Yang, Tim
Bando, Daniel Garber, Kyle Burkholder, Mike Nichols, Mark Ping, Tom
Taylor, Arnold F. Williams, George Brower, Michael Nygard, Brendan Long, Sven Dowideit, Dave Witten, Jonathan Cast, James Cronin, David L.
Jessup, Christopher Chang, Killer Delicious, Jacob Lyles, Neil
Anuskiewicz, Mordant, Clemens Ladisch, Wojciech Woytniak, Masa Bando,
John Carmack, Xingyu Wang, Jane Tang, Steven Evans, Jan Roudaut, Hsueh
Sung, Ken LaCrosse, taishi28012, John Simpson, Jerod Tufte, Paul Abbott, Stan Witherspoon, Donald Greer, Gratiela Chergu, Michael Ciagala, Dale Carstensen, Chip Davis, Liudmilla Karukina, Jim McCloskey, Dewey Sasser,
Hal Hildebrand, Connor Wood, Ken Kennedy, darrin, Mark Gardner, William Christensen, Malcolm Ocean, Rod Davenport, Nodarius Darjania, Cheryl
Evry, Wenfeng Liang, Irving Rivas, Bill Soistman, ReallyBored, Άρης Δάσος, Ron Lauzon, TheFred, Paul Theodoropolous, Doug Phillips, Les Vogel, Matt Pollard, Andres Cordova";

int main()
{
    regex
        rxComma( "\\s*([^,]+)(,|$)" ),
        rxRvSurname( "\\s*(\\S+)" ),
        rxGapSpaces( "(\\s+)" );
    match_results<string_view::iterator> mtch;
    match_results<string_view::reverse_iterator> reverseMatch;
    using name = pair<string_view, string_view>;
    vector<name> names;
    for( auto itName = ::Names.begin(); ; itName = mtch[0].second )
    {
        if( !regex_search( itName, ::Names.end(), mtch, rxComma ) )
            break;
        if( !regex_search( reverse_iterator( mtch[1].second ), reverse_iterator( mtch[1].first ), reverseMatch, rxRvSurname ) )
            continue;
        auto
            itSurname = reverseMatch[1].second.base(),
            itSurnameEnd = reverseMatch[1].first.base();
        string_view surname( itSurname, itSurnameEnd );
        auto itForename = mtch[1].first;
        if( !regex_search( reverse_iterator( itSurname ), reverse_iterator( itForename ), reverseMatch, rxGapSpaces ) )
            continue;
        auto itForenameEnd = reverseMatch[1].second.base();
        string_view forename( itForename, itForenameEnd );
        names.emplace_back( forename, surname );
    }
    sort( names.begin(), names.end(), []( const name &lhs, const name &rhs ) { return lhs.second < rhs.second; } );
    for( const name &nm : names )
    {
        cout << "\"" << nm.first << "\" - \"" << nm.second << "\"" <<
endl;
    }
}

The cool thing about that that I'm matching a part of the name with
a reverse-iterator, i.e. I do reverse regex parsing (the regex itself
is forward).

Why do you need the regex crutch?

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

DFS <[email protected]> writes:

On 4/16/2026 12:24 PM, Bonita Montero wrote:

As usual - in a superior language.

I found the definitive explanation of the visual impact of C++:

"C++ looks like someone threw up on your screen"

https://www.quora.com/Which-programming-language-has-the-most-visually-clean-syntax-in-your-opinion

[...]

Bonita's habit of posting C++ code to comp.lang.c is inappropriate.

Debating the merits of C++ is equally inappropriate.
--
Keith Thompson (The_Other_Keith) [email protected]
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Wed, 22 Apr 2026 09:18:05 +0200
David Brown <[email protected]> wrote:

On 21/04/2026 19:50, Michael S wrote:

On Tue, 21 Apr 2026 17:38:03 GMT
[email protected] (Scott Lurndal) wrote:

Bart <[email protected]> writes:

On 21/04/2026 16:33, DFS wrote:

On 4/21/2026 11:08 AM, Bart wrote:

It didn't give any examples of what the output needs to look, at
least not in your OP. (They can see it by running your
submission, but it says no peeking.)

You don't really need all that handholding do you?

None of those issues would be typical of what the PHB would ask
you to do.  "Sort this list by last name then first name" is all
I would expect to get.  Asking about case-sensitivity and 4
names and whitespace would make you look like a ninny.

You seem to be confusing a comic strip with reality.

In the real world, for professional developers, detailed
specifications are common. Forty years ago, detailed
specifications were common (we had three levels of
specification for each project back in 1983; a concept
spec, a detailed specification and a test specification).

Even the two startups I've been associated with had clear
and concise specifications for each project.

Methinks, the segment of the industry that employed you for last nn
(40?) years is an exception rather than rule.
In industry as a whole imprecise specs are far more common. Also,
specs are not constant. If the software is user-facing then the
biggest batch of clarifications of the spec tend to come after
alpha version was shipped to friendly customers. But even after
that if the project is not dead then there tends to be continuous
flow of changes and clarifications of specs.

Or perhaps he has just been lucky.

I'd guess, it has more to do with being in the middle of solution stack
rather than on one or another edge.
In the middle specs are more stable and precise.

I've had specifications (for hardware and software - we typically do
both) from customers that were hundreds of pages long, so detailed
that they were basically impossible to fulfil.

The worst is when client, instead of telling you what result he wants to
get, insists on specifying how to do it.
Personally, when I see customer like that I look for way of not being
involved in the project. Because the most common end results is both
sides dissatisfied. But that is not the worst part of it. A mutual
stress during whole process of development is worse.

At the other end of
the scale, we made a control system for a CNC saw machine where the
only concrete specification was the colour it should be painted.

What it was?

Often the process of helping turning customers' ideas into some kind
of reasonable specification is part of the service we provide. And
usually there is a continuum as specifications change along the way
(as you describe).

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 22/04/2026 12:22, Michael S wrote:

On Wed, 22 Apr 2026 09:18:05 +0200
David Brown <[email protected]> wrote:

On 21/04/2026 19:50, Michael S wrote:

On Tue, 21 Apr 2026 17:38:03 GMT
[email protected] (Scott Lurndal) wrote:

Bart <[email protected]> writes:

On 21/04/2026 16:33, DFS wrote:

On 4/21/2026 11:08 AM, Bart wrote:

It didn't give any examples of what the output needs to look, at >>>>>>> least not in your OP. (They can see it by running your
submission, but it says no peeking.)

You don't really need all that handholding do you?

None of those issues would be typical of what the PHB would ask
you to do.  "Sort this list by last name then first name" is all >>>>>> I would expect to get.  Asking about case-sensitivity and 4
names and whitespace would make you look like a ninny.

You seem to be confusing a comic strip with reality.

In the real world, for professional developers, detailed
specifications are common. Forty years ago, detailed
specifications were common (we had three levels of
specification for each project back in 1983; a concept
spec, a detailed specification and a test specification).

Even the two startups I've been associated with had clear
and concise specifications for each project.

Methinks, the segment of the industry that employed you for last nn
(40?) years is an exception rather than rule.
In industry as a whole imprecise specs are far more common. Also,
specs are not constant. If the software is user-facing then the
biggest batch of clarifications of the spec tend to come after
alpha version was shipped to friendly customers. But even after
that if the project is not dead then there tends to be continuous
flow of changes and clarifications of specs.

Or perhaps he has just been lucky.

I'd guess, it has more to do with being in the middle of solution stack rather than on one or another edge.
In the middle specs are more stable and precise.

That makes sense. Different parts of a job typically have different
levels of specification. And it can also vary depending on how many
people are working on the project - big tasks require more detail and
more coordination for the different developers working on specialist
parts. For smaller projects and groups (we are quite a small
development group), it can be more practical to leave things up to the developer to decide.

I've had specifications (for hardware and software - we typically do
both) from customers that were hundreds of pages long, so detailed
that they were basically impossible to fulfil.

The worst is when client, instead of telling you what result he wants to
get, insists on specifying how to do it.

That can be bad, yes - especially when you know there are better ways to handle things. Or when you tell the customer their solution is
impossible and they need to do it another way, and they tell you they've already made all the marketing material and dummy models before ever
talking to the technical people. You see that especially from startup companies from business schools - they have their idea, their finance
people, their marketing people, their sales people, their slogans,
websites, promotional videos, cost projections, etc., and only then, six
weeks before they have planned delivery, do they talk to someone who can
make electronics or write a program.

(It sounds like I am complaining - the majority of my customers have
been fine. Not all projects work out in the end, but that can be for
many reasons.)

Personally, when I see customer like that I look for way of not being involved in the project. Because the most common end results is both
sides dissatisfied. But that is not the worst part of it. A mutual
stress during whole process of development is worse.

At the other end of
the scale, we made a control system for a CNC saw machine where the
only concrete specification was the colour it should be painted.

What it was?

It was a multi-saw system for cutting roof beams with different sizes
and angles. We talked to the folks who made the mechanics, and we
talked a lot to the guy who was going to be using the machine in the
end, so we made a very successful system in the end. The customer
himself had no idea - but he paid his bills, so everyone was happy.

Often the process of helping turning customers' ideas into some kind
of reasonable specification is part of the service we provide. And
usually there is a continuum as specifications change along the way
(as you describe).

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Wed, 22 Apr 2026 12:38:13 +0200
David Brown <[email protected]> wrote:

On 22/04/2026 12:22, Michael S wrote:

On Wed, 22 Apr 2026 09:18:05 +0200
David Brown <[email protected]> wrote:

At the other end of
the scale, we made a control system for a CNC saw machine where the
only concrete specification was the colour it should be painted.

What it was?

It was a multi-saw system for cutting roof beams with different sizes
and angles. We talked to the folks who made the mechanics, and we
talked a lot to the guy who was going to be using the machine in the
end, so we made a very successful system in the end. The customer
himself had no idea - but he paid his bills, so everyone was happy.

I was asking what colour it was.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 22/04/2026 12:58, Michael S wrote:

On Wed, 22 Apr 2026 12:38:13 +0200
David Brown <[email protected]> wrote:

On 22/04/2026 12:22, Michael S wrote:

On Wed, 22 Apr 2026 09:18:05 +0200
David Brown <[email protected]> wrote:

At the other end of
the scale, we made a control system for a CNC saw machine where the
only concrete specification was the colour it should be painted.

What it was?

It was a multi-saw system for cutting roof beams with different sizes
and angles. We talked to the folks who made the mechanics, and we
talked a lot to the guy who was going to be using the machine in the
end, so we made a very successful system in the end. The customer
himself had no idea - but he paid his bills, so everyone was happy.

I was asking what colour it was.

Oh, sorry. A particular shade of dark green, matching other machines
they had made.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 4/22/2026 6:16 AM, Keith Thompson wrote:

DFS <[email protected]> writes:

On 4/16/2026 12:24 PM, Bonita Montero wrote:

As usual - in a superior language.

I found the definitive explanation of the visual impact of C++:

"C++ looks like someone threw up on your screen"

https://www.quora.com/Which-programming-language-has-the-most-visually-clean-syntax-in-your-opinion

[...]

Bonita's habit of posting C++ code to comp.lang.c is inappropriate.

Debating the merits of C++ is equally inappropriate.

So is discussing sorting algorithms.



--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-04-22 11:33, DFS wrote:

On 4/16/2026 12:24 PM, Bonita Montero wrote:

As usual - in a superior language.

I found the definitive explanation of the visual impact of C++:

"C++ looks like someone threw up on your screen"

[snip link]

The "nice" thing is that on the Internet you find any opinion you
like to be seconded. - It makes little sense to post any arbitrary
selected link.

Skimming over that specific page you find people mentioning their
preferences for Pearl or Lisp as positive paragons. (It's beyond
me why anyone would consider these languages or C/C++ as positive
paragons.) - It makes little sense to discuss personal preferences.

Concerning Bonita's language of choice, C++, it should be reminded
that he usually compares its features by the respective explicitly
programmed code in "C". - That's a point, but it makes little sense
to repeat that language difference here.

Janis

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-04-22 12:38, David Brown wrote:

On 22/04/2026 12:22, Michael S wrote:

On Wed, 22 Apr 2026 09:18:05 +0200
David Brown <[email protected]> wrote:

On 21/04/2026 19:50, Michael S wrote:

On Tue, 21 Apr 2026 17:38:03 GMT
[email protected] (Scott Lurndal) wrote:

In the real world, for professional developers, detailed
specifications are common.   Forty years ago, detailed
specifications were common (we had three levels of
specification for each project back in 1983; a concept
spec, a detailed specification and a test specification).

Even the two startups I've been associated with had clear
and concise specifications for each project.

Methinks, the segment of the industry that employed you for last nn
(40?) years is an exception rather than rule. [...]

I'd guess, it has more to do with being in the middle of solution stack
rather than on one or another edge.
In the middle specs are more stable and precise.

That makes sense.  Different parts of a job typically have different
levels of specification.  And it can also vary depending on how many
people are working on the project - big tasks require more detail and
more coordination for the different developers working on specialist parts.  For smaller projects and groups (we are quite a small
development group), it can be more practical to leave things up to the developer to decide.

In bigger projects we typically had (English phrases chosen by me)
* user requirements specification (from the customer)
* product requirements specification (from the vendor; negotiated)
* technical specifications (derived from the former)
* test-specifications (derived from the former two)
Depending on the project there may be more specifications necessary
or some considered unnecessary. Referring to international and local
standards help to reduce the size of specification documents.

I've had specifications (for hardware and software - we typically do
both) from customers that were hundreds of pages long, so detailed
that they were basically impossible to fulfil.

That's why there's the "product requirements specification".

(Of course if the customer requirements exceed the capabilities of
the development company they should better abstain, or make use of subcontractors.)

The worst is when client, instead of telling you what result he wants to
get, insists on specifying how to do it.

Usually the customer defines the "What" and the vendor the "How". In
some cases the customer has a valid reason for detailing some aspects
of the implementation.

It should be reminded that there's also "agile" forms of development
existing (Scrum, Kanban, etc.) where you dynamically adjust necessary
changes with the customer. This is more flexible but a global document
with requirements should in my experience be anyway existing (at least
to provide the fenceposts).

That can be bad, yes - especially when you know there are better ways to handle things.  Or when you tell the customer their solution is
impossible and they need to do it another way, and they tell you they've already made all the marketing material and dummy models before ever
talking to the technical people.  You see that especially from startup companies from business schools - they have their idea, their finance people, their marketing people, their sales people, their slogans,
websites, promotional videos, cost projections, etc., and only then, six weeks before they have planned delivery, do they talk to someone who can make electronics or write a program.

That sounds bad. - But the vendor has (probably not in all cases
but regularly at least) the option to convince the customer by his
expertise and the factual needs. That's where the first two above
mentioned specifications have their role; negotiating what to do.

(It sounds like I am complaining - the majority of my customers have
been fine.  Not all projects work out in the end, but that can be for
many reasons.)

Yes. Both sides have an interest that something sensible gets created.

Personally, when I see customer like that I look for way of not being
involved in the project. Because the most common end results is both
sides dissatisfied.

It's good if you can talk to your management to point out problems.
That requires a good management. Ideally it knows what can sensibly
by done or ask the technical experts about its practicality.

But that is not the worst part of it. A mutual
stress during whole process of development is worse.

Amen.

Janis

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-04-22 08:11, Janis Papanagnou wrote:
...

Concerning Bonita's language of choice, C++, it should be reminded
that he usually ...

Completely off-topic and of no importance, I'm just curious:
I would have thought, based upon my experiences with latin languages,
that Bonita would be a woman's name. Has Bonita said that Bonita is
male? I only see other people's responses to Bonita's messages, so I
would probably have missed it.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-04-23 03:27, James Kuyper wrote:

Completely off-topic and of no importance, I'm just curious:
I would have thought, based upon my experiences with latin languages,
that Bonita would be a woman's name. Has Bonita said that Bonita is
male? I only see other people's responses to Bonita's messages, so I
would probably have missed it.

You are most probably right; both, Bonita and Montero, appear to be
of Spanish origin. And I was sloppy in addressing her correctly. 8-/
My sincere apologies to Bonita! - I somehow and wrongly thought that
it was a pseudonym; probably because I think she's a German resident,
but then there's also residents in Germany with Greek names.[*] ;-)

Thanks for pointing me to the obvious that I also obviously missed.

Janis

[*] Serves me right. Some time ago I was wrongly addressed as female
because of the association with the phonetic similar Janice and with
the famous Janis Joplin being obviously female. Now given the famous
Yanis Varoufakis things should be more obvious.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Janis Papanagnou <[email protected]> writes:

On 2026-04-23 03:27, James Kuyper wrote:

Completely off-topic and of no importance, I'm just curious:
I would have thought, based upon my experiences with latin languages,
that Bonita would be a woman's name. Has Bonita said that Bonita is
male? I only see other people's responses to Bonita's messages, so I
would probably have missed it.

You are most probably right; both, Bonita and Montero, appear to be
of Spanish origin. And I was sloppy in addressing her correctly. 8-/
My sincere apologies to Bonita! - I somehow and wrongly thought that
it was a pseudonym; probably because I think she's a German resident,
but then there's also residents in Germany with Greek names.[*] ;-)

It's the internet. Anyone can be anyone. Bonita posts
auf Deutschland and has a profile pic on Stack Overflow,
FWIW.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-04-23 16:45, Scott Lurndal wrote:

It's the internet. Anyone can be anyone. Bonita posts
auf Deutschland and has a profile pic on Stack Overflow,
FWIW.

I usually don't make investigations about persons posting before
answering to their posts. Though I had seen the picture before I
made my previous post. - As you say, "anyone can be anyone"; and
names and pictures can also be chosen arbitrarily (e.g. for sake
of privacy).

But I've no reason to doubt that she's female. (Unless she, the
poster, corrects me.) And the origin of the name should certainly
have been obvious to me.

Janis

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

DFS <[email protected]> writes:

On 4/22/2026 6:16 AM, Keith Thompson wrote:

[...]

Bonita's habit of posting C++ code to comp.lang.c is inappropriate.

Debating the merits of C++ is equally inappropriate.

So is discussing sorting algorithms.

Discussing sorting algorithms is perfectly appropriate, if the
discussion also has something to do with the C language or how
to write programs in C.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

In article <10sa75i$25o8u$[email protected]>,
Keith Thompson <[email protected]> wrote:

DFS <[email protected]> writes:

On 4/16/2026 12:24 PM, Bonita Montero wrote:

As usual - in a superior language.

I found the definitive explanation of the visual impact of C++:

"C++ looks like someone threw up on your screen"

https://www.quora.com/Which-programming-language-has-the-most-visually-clean-syntax-in-your-opinion

[...]

Bonita's habit of posting C++ code to comp.lang.c is inappropriate.

Debating the merits of C++ is equally inappropriate.

The king has spoken.
--
They say that Trump is a stupid man's idea of a clever man, a poor man's
idea of a rich man, and a weak man's idea of a strong man.

Well, Melania is an unclassy man's idea of classy.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Am 22.04.2026 um 11:33 schrieb DFS:

On 4/16/2026 12:24 PM, Bonita Montero wrote:

As usual - in a superior language.

I found the definitive explanation of the visual impact of C++:

"C++ looks like someone threw up on your screen"

https://www.quora.com/Which-programming-language-has-the-most-visually- clean-syntax-in-your-opinion

For an average C++-developer that's easy.
The problem is not the language but you.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Am 23.04.2026 um 17:11 schrieb Tim Rentsch:

Discussing sorting algorithms is perfectly appropriate, if the
discussion also has something to do with the C language or how
to write programs in C.

If the current context loses its connection to C, it's off-topic.
So you're not following your own rules. I might as well post C++
code. ;-)
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

In article <10sdnid$37qfp$[email protected]>,
Bonita Montero <[email protected]> wrote:

Am 23.04.2026 um 17:11 schrieb Tim Rentsch:

Discussing sorting algorithms is perfectly appropriate, if the
discussion also has something to do with the C language or how
to write programs in C.

If the current context loses its connection to C, it's off-topic.
So you're not following your own rules. I might as well post C++
code. ;-)

It would be so much more interesting and entertaining if you posted in D or Swift - both of which are, like C++, C-like.
--
The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/PennJillette
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Janis Papanagnou <[email protected]> writes:
[...]

[*] Serves me right. Some time ago I was wrongly addressed as female
because of the association with the phonetic similar Janice and with
the famous Janis Joplin being obviously female. Now given the famous
Yanis Varoufakis things should be more obvious.

I've made the same incorrect assumption in your case, but I think
I managed not to address you incorrectly. (I doubt that Yanis
Varoufakis is famous outside Greece, so that's not likely to be
helpful.)
--
Keith Thompson (The_Other_Keith) [email protected]
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 4/23/2026 10:45 AM, Scott Lurndal wrote:

Bonita posts auf Deutschland and has a profile
pic on Stack Overflow, FWIW.

https://chat.stackoverflow.com/users/6469690/bonita-montero

That 2021? profile pic shows a seemingly young female. But Montero
trolls clc aggressively like a male - its clc behavior is extremely
unusual for a female.

Montero, is that you in the pic? How old are you?
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-04-24 01:36, Keith Thompson wrote:

[...] (I doubt that Yanis
Varoufakis is famous outside Greece, so that's not likely to be
helpful.)

Oh, I'm positive that's not true! - Myself I certainly don't know
him from Greece, since I'm not living in that country. - Not sure
where you're residing, but he's famous (or infamous) in Europe at
least since the Euro-crisis 20 years ago! - He also studied in GB
and later became university teacher in Essex and Cambridge. And
finally he also became visiting professor in the US (Austin/Texas).
Frankly, I wonder that you missed his name completely. But, okay,
he's not technician but an economist. And so he's probably better
known in Europe than in the US.

Janis

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

DFS <[email protected]> writes:

On 4/23/2026 10:45 AM, Scott Lurndal wrote:

Bonita posts auf Deutschland and has a profile
pic on Stack Overflow, FWIW.

https://chat.stackoverflow.com/users/6469690/bonita-montero

That 2021? profile pic shows a seemingly young female. But Montero
trolls clc aggressively like a male - its clc behavior is extremely
unusual for a female.

Montero, is that you in the pic? How old are you?

This kind of inquiry is inappropriate. Anyone can of course tell
us how old they are if they choose to, but insisting that someone
discloses personal information is rude and verges on stalking,
to say nothing of its irrelevance to the topic of this newsgroup.

You post as "DFS". I don't know your age, your sex, what you
look like, or anything about you other than what you post here.
And that's fine.

(Just one suggestion. If you want to use a fake email address,
don't use a real domain that belongs to someone else. dfs.com is a
shopping site, and my guess is that you're not actually affiliated
with it. Consider something like "dfs.example.com".)
--
Keith Thompson (The_Other_Keith) [email protected]
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Janis Papanagnou <[email protected]> writes:

On 2026-04-24 01:36, Keith Thompson wrote:

[...] (I doubt that Yanis
Varoufakis is famous outside Greece, so that's not likely to be
helpful.)

Oh, I'm positive that's not true! - Myself I certainly don't know
him from Greece, since I'm not living in that country. - Not sure
where you're residing, but he's famous (or infamous) in Europe at
least since the Euro-crisis 20 years ago! - He also studied in GB
and later became university teacher in Essex and Cambridge. And
finally he also became visiting professor in the US (Austin/Texas).
Frankly, I wonder that you missed his name completely. But, okay,
he's not technician but an economist. And so he's probably better
known in Europe than in the US.

I'm American. We're barely aware that Europe exists. 8-)}
--
Keith Thompson (The_Other_Keith) [email protected]
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

[f'up-to set]

2026-04-24, DFS <[email protected]> schrieb:

[Schnipp]

That 2021? profile pic shows a seemingly young female. But Montero
trolls clc aggressively like a male - its clc behavior is extremely
unusual for a female.

This as much off-topic as the c++-dribble of Bonita.

(And it is irrelevant)
--
Jan v/d Broek [email protected]

"We're through being cool."
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Am 24.04.2026 um 02:31 schrieb DFS:

That 2021? profile pic shows a seemingly young female.  But Montero
trolls clc aggressively like a male - its clc behavior is extremely
unusual for a female.

The pic is older. I'm from 1976.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 24/04/2026 02:31, DFS wrote:

On 4/23/2026 10:45 AM, Scott Lurndal wrote:

Bonita posts auf Deutschland and has a profile
pic on Stack Overflow, FWIW.

https://chat.stackoverflow.com/users/6469690/bonita-montero

That 2021? profile pic shows a seemingly young female.  But Montero
trolls clc aggressively like a male - its clc behavior is extremely
unusual for a female.

Montero, is that you in the pic?  How old are you?

We don't need to try to look up people's details, or speculate. We
don't need to ask personal questions. We don't need prejudice or
bigotry. ("Males do this, females do that" - that's bigotry. People
are responsible for their own actions and attitudes. If you think
Bonita posts aggressively in c.l.c., that's because it is the way she
posts. It is neither because of nor despite of being female, German,
Italian, a C++ programmer, or any other characteristic that you think
fits, true or untrue.)

If people want to give personal information, that's their choice. I
think it is nice to have the basics right, such as a real name (I am
aware that "David Brown" is about as anonymous a name as you can get in
an English language context - though my email address is valid), but
that's a choice too. For practical reasons of writing, it's useful to
know what pronouns to use for someone - and if we don't know for sure,
we make a best guess. If we get it wrong, and that person is bothered
about it, we'll be corrected and try to remember for the future. (Note
that a person may choose to use different pronouns along with anonymity
on Usenet - that's up to them.)


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Thu, 23 Apr 2026 15:51:13 +0200
Janis Papanagnou <[email protected]> wrote:

On 2026-04-23 03:27, James Kuyper wrote:

Completely off-topic and of no importance, I'm just curious:
I would have thought, based upon my experiences with latin
languages, that Bonita would be a woman's name. Has Bonita said
that Bonita is male? I only see other people's responses to
Bonita's messages, so I would probably have missed it.

You are most probably right; both, Bonita and Montero, appear to be
of Spanish origin.

Majority of hits by search engines suggests either Mitsubishi vehicle,
which is known as Pajero in majority of Europe, supposedly including
Germany, or album of American rapper, named after said vehicle.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-04-24 13:20, Michael S wrote:

On Thu, 23 Apr 2026 15:51:13 +0200
Janis Papanagnou <[email protected]> wrote:

You are most probably right; both, Bonita and Montero, appear to be
of Spanish origin.

Majority of hits by search engines suggests either Mitsubishi vehicle,
which is known as Pajero in majority of Europe, supposedly including
Germany, or album of American rapper, named after said vehicle.

With the contemporary versions of Google I tend to not search
only for keywords but rather ask a question (here: "origin of
name bonita montero") that results in more accurate results.
While I dislike a couple aspects of AI, such question-response
feature I consider a progress.

Janis

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

In article <10sehs6$3dgcd$[email protected]>,
Keith Thompson <[email protected]> wrote:

DFS <[email protected]> writes:

On 4/23/2026 10:45 AM, Scott Lurndal wrote:

Bonita posts auf Deutschland and has a profile
pic on Stack Overflow, FWIW.

https://chat.stackoverflow.com/users/6469690/bonita-montero

That 2021? profile pic shows a seemingly young female. But Montero
trolls clc aggressively like a male - its clc behavior is extremely
unusual for a female.

Montero, is that you in the pic? How old are you?

This kind of inquiry is inappropriate.

The king has spoken. All heed and obey.
--
Most Southerners interest in, knowledge of, and participation in politics begins with
and ends with: Screw the blacks. If a guy is onboard with that, he's our guy!

Get them back in chains where they belong!
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 4/23/2026 6:50 PM, Keith Thompson wrote:

Janis Papanagnou <[email protected]> writes:

On 2026-04-24 01:36, Keith Thompson wrote:

[...] (I doubt that Yanis
Varoufakis is famous outside Greece, so that's not likely to be
helpful.)

Oh, I'm positive that's not true! - Myself I certainly don't know
him from Greece, since I'm not living in that country. - Not sure
where you're residing, but he's famous (or infamous) in Europe at
least since the Euro-crisis 20 years ago! - He also studied in GB
and later became university teacher in Essex and Cambridge. And
finally he also became visiting professor in the US (Austin/Texas).
Frankly, I wonder that you missed his name completely. But, okay,
he's not technician but an economist. And so he's probably better
known in Europe than in the US.

I'm American. We're barely aware that Europe exists. 8-)}

ROFL! :^D
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 4/23/2026 2:10 PM, Bonita Montero wrote:

Am 22.04.2026 um 11:33 schrieb DFS:

On 4/16/2026 12:24 PM, Bonita Montero wrote:

As usual - in a superior language.

I found the definitive explanation of the visual impact of C++:

"C++ looks like someone threw up on your screen"

https://www.quora.com/Which-programming-language-has-the-most-visually- clean-syntax-in-your-opinion

For an average C++-developer that's easy.
The problem is not the language but you.

Maybe, maybe not.

Do Google searches for

"who likes the way C++ programs look"
"who likes the way C programs look"

without the quotes

And the AI overview will give some insight.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> writes:

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> 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.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Tim Rentsch <[email protected]> writes:

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> writes:

Keith Thompson <[email protected]> writes:

Tim Rentsch <[email protected]> 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) [email protected]
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21f-Linux NewsLink 1.2