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.
------------------------------------------------------------------No necessity for peeking since I'd write a Unix 'sort' one-liner
No peeking!
[...removed without peeking...]
71 SLOC
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).
------------------------------------------------------------------No necessity for peeking since I'd write a Unix 'sort' one-liner
No peeking!
[...removed without peeking...]
71 SLOC
(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?)
On 4/8/2026 4: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).
------------------------------------------------------------------No necessity for peeking since I'd write a Unix 'sort' one-liner
No peeking!
[...removed without peeking...]
71 SLOC
(instead of a bulky "C" program). ;-)
Bulky C is more fun!
"one-liner"? With multiple pipes and tr and sed and awk, maybe.
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."
(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?)
Just looking to see how a variety of excellent C programmers would
approach a string/split/sort challenge.
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;
}
Bart <bc@freeuk.com> 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;
}
On 08/04/2026 17:25, DFS wrote:
On 4/8/2026 4: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).
------------------------------------------------------------------No necessity for peeking since I'd write a Unix 'sort' one-liner
No peeking!
[...removed without peeking...]
71 SLOC
(instead of a bulky "C" program). ;-)
Bulky C is more fun!
"one-liner"? With multiple pipes and tr and sed and awk, maybe.
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."
(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?)
Just looking to see how a variety of excellent C programmers would
approach a string/split/sort challenge.
These are more higher level tasks than you'd want to use C for.
And everyone's going to do it a slightly different way.
You also seem to value LoC as a metric. Your version was labeled as 71
SLOC, I assume including this function:
//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;
}
Now it's clearer! It's counting occurrences of 'chr' within 'str'.
This adds 6 SLOC, but IMO it's worth it. Striving to get the smallest
LOC meant poorer quality code, not helped by the misleading comment, or
the choice of 'c' as the index.
I'd write it like this:
int countchr(char *s, char ch) {
int n = 0;
while (*s) {
if (*s == ch) n++;
++s;
}
return n;
}
Then if worried about line-count, I might try:
int countchr(char *s, char ch) {
int n = 0;
while (*s) n += (*s++ == ch);
return n;
}
This is actually 12 characters shorter when your version, even with space-based indents (normally I use hard tabs) and extra white space.
On Wed, 08 Apr 2026 21:04:56 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Bart <bc@freeuk.com> 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 change it to
size_t
countchar(const char *str, char match)
{
size_t count = 0;
for(; *str != 0; str++) count += (*str == match);
return count;
}
Michael S <already5chosen@yahoo.com> writes:
On Wed, 08 Apr 2026 21:04:56 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Bart <bc@freeuk.com> 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 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.
Michael S <already5chosen@yahoo.com> writes:
On Wed, 08 Apr 2026 21:04:56 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Bart <bc@freeuk.com> 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 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.
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.
Michael S <already5chosen@yahoo.com> writes:
On Wed, 08 Apr 2026 21:04:56 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Bart <bc@freeuk.com> 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 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.
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.
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.
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.
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
The semantics of !ptr has been codified to mean 1 for null pointers
since the original C standard. Heck, even during the 1970s when C
allowed assigning integers directly to pointers, K&R said that
assigning 0 to a pointer produces a pointer guaranteed to be
different than a pointer to any object. Any C implementation where
!ptr does the wrong thing should be avoided like the plague.
Any C implementation where !ptr does the wrong thing almost certainly
does not exist. It's difficult to imagine that a C compiler with
such a fundamental bug would ever go out the door.
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.
On Wed, 08 Apr 2026 23:35:35 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Michael S <already5chosen@yahoo.com> writes:
On Wed, 08 Apr 2026 21:04:56 GMT
scott@slp53.sl.home (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.
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.
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!
"one-liner"? With multiple pipes and tr and sed and awk, maybe.
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."
[...]
Bart <bc@freeuk.com> 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;
}
[...]
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
[...]
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:
In article <20260409025901.00002bc6@yahoo.com>,
Michael S <already5chosen@yahoo.com> wrote:
On Wed, 08 Apr 2026 23:35:35 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Michael S <already5chosen@yahoo.com> writes:
On Wed, 08 Apr 2026 21:04:56 GMT
scott@slp53.sl.home (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.
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.
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <20260409025901.00002bc6@yahoo.com>,
Michael S <already5chosen@yahoo.com> wrote:
On Wed, 08 Apr 2026 23:35:35 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Michael S <already5chosen@yahoo.com> writes:
On Wed, 08 Apr 2026 21:04:56 GMT
scott@slp53.sl.home (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.
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
The semantics of !ptr has been codified to mean 1 for null pointers
since the original C standard. Heck, even during the 1970s when C
allowed assigning integers directly to pointers, K&R said that
assigning 0 to a pointer produces a pointer guaranteed to be
different than a pointer to any object. Any C implementation where
!ptr does the wrong thing should be avoided like the plague.
Any C implementation where !ptr does the wrong thing almost certainly
does not exist. It's difficult to imagine that a C compiler with
such a fundamental bug would ever go out the door.
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.
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
The semantics of !ptr has been codified to mean 1 for null pointers
since the original C standard. Heck, even during the 1970s when C
allowed assigning integers directly to pointers, K&R said that
assigning 0 to a pointer produces a pointer guaranteed to be
different than a pointer to any object. Any C implementation where
!ptr does the wrong thing should be avoided like the plague.
Any C implementation where !ptr does the wrong thing almost certainly
does not exist. It's difficult to imagine that a C compiler with
such a fundamental bug would ever go out the door.
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.
scott@slp53.sl.home (Scott Lurndal) writes:
Or even obsolete. The systems in question were all retired by
2010, and never had a C compiler. The system was BCD and the
six digit 'undigit' value of EEEEEE was chosen as the NIL (NULL)
pointer value.
It would be nice if in the future it were stated directly when a
non-C environment is the context of a comment. I mistakenly
understood that what you were saying had to do with experience
using some unusual C compiler.
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).
------------------------------------------------------------------No necessity for peeking since I'd write a Unix 'sort' one-liner
No peeking!
[...removed without peeking...]
71 SLOC
(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?)
Janis
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
The semantics of !ptr has been codified to mean 1 for null pointers
since the original C standard. Heck, even during the 1970s when C
allowed assigning integers directly to pointers, K&R said that
assigning 0 to a pointer produces a pointer guaranteed to be
different than a pointer to any object. Any C implementation where
!ptr does the wrong thing should be avoided like the plague.
Any C implementation where !ptr does the wrong thing almost certainly
does not exist. It's difficult to imagine that a C compiler with
such a fundamental bug would ever go out the door.
My usual preference is to draw conclusions based on evidence rather imagination or supposition.
It's barely possible that compiler that uses a representation other
than all-bits-zero for null pointers might have such a bug, but
(a) anyone creating such an implementation will almost certainly
be extremely careful to get such things right, and (b) I'm not sure
that any such compilers even exist, except perhaps for old systems
that would be considered exotic today.
Here again this sounds like just supposition. How much experience
do you have, and how extensive, using non-mainstream C compilers?
For myself I can't say I much at all, but I have seen one where
believe it or not assert() was implemented wrongly. assert()! I
certainly wouldn't have guessed that before actually seeing it.
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
scott@slp53.sl.home (Scott Lurndal) writes:
Or even obsolete. The systems in question were all retired by
2010, and never had a C compiler. The system was BCD and the
six digit 'undigit' value of EEEEEE was chosen as the NIL (NULL)
pointer value.
It would be nice if in the future it were stated directly when a
non-C environment is the context of a comment. I mistakenly
understood that what you were saying had to do with experience
using some unusual C compiler.
I was in the OS group at the time. The languages group had
started looking at writing a C compiler for the architecture, but
it never panned out (and there was little interest from the
predominantly COBOL customer base).
BTW, I think that (ptr != 0) is guaranteed to work even on systems with
null pointers not being numerically zero. ...
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.
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.
In article <10rr402$1r3mi$1@raubtier-asyl.eternal-september.org>,
Bonita Montero <Bonita.Montero@gmail.com> 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.
Honestly; mind to explain what the point of this "C" challenge is?
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
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)+ 1;
{
//vars
char delim[2] = ",";
int i=0,j=0;
//number of names is commas + 1 int namecnt = countchr(names,',')
*lname; //
//name array: one column for first-last, one for last-first char
*narr[2][namecnt];
char *flname, lfname[30]; // full names char *fname,
part names char tmp[30]="";full
// parse full names from string // then parse first and last from
name // add both into array char *dup = strdup(names);strlen(lname)-1);
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)-
fname = strdup(tmp);strdup(flname);
}
else {
lname = strdup(flname);
fname = strdup("");
fname[strlen(fname)-2] = '\0';
}
sprintf(lfname,"%s %s",lname,fname); narr[0][i]=
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
sort( names.begin(), names.end(), []( const name &lhs, const name &rhs ) { return lhs.second < rhs.second; } );
On Tue, 7 Apr 2026 23:14:41 -0400, DFS wrote:
Martin Hohenberg, Jae Yang, Tim Bando, Daniel Garber, Kyle Burkholder,ot
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.
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
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,ot
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.
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
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.
$ cat names.txt | tr -d '\n' | sed 's/,/\n/g' | sed 's/^ //g' | awk 'NF ==Uh-oh! - Why so complicated?
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 }'
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//'
In article <10s20jf$2b5i9$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> 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.
{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
---------------------------------
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
this is a C version
#define R return
#define P printf
{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}
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.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,113 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 492402:17:20 |
| Calls: | 14,249 |
| Files: | 186,315 |
| D/L today: |
82 files (21,384K bytes) |
| Messages: | 2,515,138 |