On 12/09/2024 13:20, Janis Papanagnou wrote:

On 12.09.2024 13:29, Bart wrote:

On 12/09/2024 03:22, Bonita Montero wrote:

Am 11.09.2024 um 22:19 schrieb Bart:

C++ is a simpler language? You're having a laugh!

The solutions are simpler because you've a fifth of the code as in C.

In this case, it actually needed somewhat more code, even if the line

count was half.

But your solutions are always incomprehensible because they strive for
the most advanced features possible.

I don't know of the other poster's solutions. But a quick browse seems
to show nothing incomprehensible or anything that should be difficult
to understand. (YMMV; especially if you're not familiar with C++ then
I'm sure the code may look like noise to you.)

In the given context of C and C++ I've always perceived the features
of C++ to add to comprehensibility of source code where the respective
C code required writing clumsy code and needed (unnecessary) syntactic ballast to implement similar functions and program constructs.

Your undifferentiated complaint sounds more like someone not willing
to understand the other concepts or have a reluctance or laziness to
make yourself familiar with them.

I'm saying it's not necessary to use such advanced features to do some
trivial parsing.

I've given a C solution below. (To test outside of Windows, remove
windows.h and set cmdline to any string containing a test input or use a
local function to get the program's command line as one string.)

It uses no special features. Anybody can understand such code. Anybody
can port it to another language far more easily than the C++. (Actually
I wrote it first in my language then ported it to C. I only needed to do
1- to 0-based conversion.)

There are two things missing compared with the C++ (other than it uses
UTF8 strings):

* Individual parameters are capped in length (to 1023 chars here). This
can be solved by determining only the span of the item then working from
that.

* Handling an unknown number of parameters is not automatic:

For the latter, the example uses a fixed array size. For a dynamic array
size, call 'strtoargs' with a count of 0 to first determine the number
of args, then allocate an array and call again to populate it.


-------------------------------------------
#include <windows.h>
#include <stdio.h>
#include <string.h>

int strtoargs(char* cmd, char** dest, int count) {
enum {ilen=1024};
char item[ilen];
int n=0, length, c;
char *p=cmd, *q, *end=&item[ilen-1];

while (c=*p++) {
if (c==' ' || c=='\t')
continue;
else if (c=='"') {
length=0;
q=item;

while (c=*p++, c!='"') {
if (c==0) {
--p;
break;
} else {
if (q<end) *q++ = c;
}
}
goto store;
} else {
length=0;
q=item;
--p;

while (c=*p++, c!=' ' && c!='\t') {
if (c==0) {
--p;
break;
} else {
if (q<end) *q++ = c;
}
}

store: *q=0;
++n;
if (n<=count) dest[n-1]=strdup(item);
}
}
return n;
}

int main(void) {
char* cmdline;
enum {cap=30};
char* args[cap];
int n;

cmdline = GetCommandLineA();

n=strtoargs(cmdline, args, cap);

for (int i=0; i<n; ++i) {
if (i<cap)
printf("%d %s\n", i, args[i]);
else
printf("%d <overflow>\n", i);
}
}
-------------------------------------------

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/09/2024 14:44, Bart wrote:

On 12/09/2024 13:20, Janis Papanagnou wrote:

On 12.09.2024 13:29, Bart wrote:

On 12/09/2024 03:22, Bonita Montero wrote:

Am 11.09.2024 um 22:19 schrieb Bart:

C++ is a simpler language? You're having a laugh!

The solutions are simpler because you've a fifth of the code as in C.

In this case, it actually needed somewhat more code, even if the line

count was half.

But your solutions are always incomprehensible because they strive for
the most advanced features possible.

I don't know of the other poster's solutions. But a quick browse seems
to show nothing incomprehensible or anything that should be difficult
to understand. (YMMV; especially if you're not familiar with C++ then
I'm sure the code may look like noise to you.)

In the given context of C and C++ I've always perceived the features
of C++ to add to comprehensibility of source code where the respective
C code required writing clumsy code and needed (unnecessary) syntactic
ballast to implement similar functions and program constructs.

Your undifferentiated complaint sounds more like someone not willing
to understand the other concepts or have a reluctance or laziness to
make yourself familiar with them.

I'm saying it's not necessary to use such advanced features to do some trivial parsing.

I've given a C solution below.

BTW here are the sources sizes for the tokeniser function. (For C++ I've included the 'using' statement.)

Spaces Hard tabs

C++ 829 682 characters
C 959 634
M 785 548 (My original of the C version)

So my C version is actually smaller than the C++ when using hard tabs.

In any case, the C++ is not significantly smaller than the C, and
certainly not a fifth the size.

For proper higher level solutions in different languages, below is one
of mine. That function is 107 bytes with hard tabs.

(It's not possible to just split the string on white space because of
quoted items with embedded spaces.)

-------------------------------
func strtoargs(cmdline)=
args::=()
sreadln(cmdline)

while k:=sread("n") do
args &:= k
od
args
end

println strtoargs(getcommandlinea())

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12.09.2024 16:04, Bonita Montero wrote:

Am 12.09.2024 um 14:20 schrieb Janis Papanagnou:

I don't know of the other poster's solutions. But a quick browse seems
to show nothing incomprehensible or anything that should be difficult
to understand. (YMMV; especially if you're not familiar with C++ then
I'm sure the code may look like noise to you.)

C++ shared a property with C: The language facilties are mostly that
simple that it's easy to roughly imagine the resulting code. So C++
can be written with the same mindset.

Not only "roughly imagine"; I think the imperative languages have
so many common basic concepts that you can have a quite good idea,
especially if you know more than just two or three such languages.

But there are features, even basic ones, that are not existing in
"C" thus making especially folks who are focused to some specific
restricted or poorer language(s) obviously get confused.

Yes, C++ can be written with a "C" mindset. But this is nothing
I'd suggest. Better make yourself familiar with the new concepts
(OO, genericity, or even simple things like references). - IMO.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 12 Sep 2024 14:44:03 +0100
Bart <bc@freeuk.com> wrote:

On 12/09/2024 13:20, Janis Papanagnou wrote:

On 12.09.2024 13:29, Bart wrote:

On 12/09/2024 03:22, Bonita Montero wrote:

Am 11.09.2024 um 22:19 schrieb Bart:

C++ is a simpler language? You're having a laugh!

The solutions are simpler because you've a fifth of the code as
in C.

In this case, it actually needed somewhat more code, even if the
line

count was half.

But your solutions are always incomprehensible because they strive
for the most advanced features possible.

I don't know of the other poster's solutions. But a quick browse
seems to show nothing incomprehensible or anything that should be
difficult to understand. (YMMV; especially if you're not familiar
with C++ then I'm sure the code may look like noise to you.)

In the given context of C and C++ I've always perceived the features
of C++ to add to comprehensibility of source code where the
respective C code required writing clumsy code and needed
(unnecessary) syntactic ballast to implement similar functions and
program constructs.

Your undifferentiated complaint sounds more like someone not willing
to understand the other concepts or have a reluctance or laziness to
make yourself familiar with them.

I'm saying it's not necessary to use such advanced features to do
some trivial parsing.

I've given a C solution below. (To test outside of Windows, remove
windows.h and set cmdline to any string containing a test input or
use a local function to get the program's command line as one string.)

It uses no special features. Anybody can understand such code.
Anybody can port it to another language far more easily than the C++. (Actually I wrote it first in my language then ported it to C. I only
needed to do 1- to 0-based conversion.)

There are two things missing compared with the C++ (other than it
uses UTF8 strings):

* Individual parameters are capped in length (to 1023 chars here).
This can be solved by determining only the span of the item then
working from that.

* Handling an unknown number of parameters is not automatic:

For the latter, the example uses a fixed array size. For a dynamic
array size, call 'strtoargs' with a count of 0 to first determine the
number of args, then allocate an array and call again to populate it.

-------------------------------------------
#include <windows.h>
#include <stdio.h>
#include <string.h>

int strtoargs(char* cmd, char** dest, int count) {
enum {ilen=1024};
char item[ilen];
int n=0, length, c;
char *p=cmd, *q, *end=&item[ilen-1];

while (c=*p++) {
if (c==' ' || c=='\t')
continue;
else if (c=='"') {
length=0;
q=item;

while (c=*p++, c!='"') {
if (c==0) {
--p;
break;
} else {
if (q<end) *q++ = c;
}
}
goto store;
} else {
length=0;
q=item;
--p;

while (c=*p++, c!=' ' && c!='\t') {
if (c==0) {
--p;
break;
} else {
if (q<end) *q++ = c;
}
}

store: *q=0;
++n;
if (n<=count) dest[n-1]=strdup(item);
}
}
return n;
}

int main(void) {
char* cmdline;
enum {cap=30};
char* args[cap];
int n;

cmdline = GetCommandLineA();

n=strtoargs(cmdline, args, cap);

for (int i=0; i<n; ++i) {
if (i<cap)
printf("%d %s\n", i, args[i]);
else
printf("%d <overflow>\n", i);
}
}
-------------------------------------------

Apart from unnecessary ilen limit, of unnecessary goto into block (I
have nothing against forward gotos out of blocks, but gotos into blocks
make me nervous) and of variable 'length' that serves no purpose, your
code simply does not fulfill requirements of OP.
I can immediately see two gotchas: no handling of escaped double
quotation marks \" and no handling of single quotation marks. Quite
possibly there are additional omissions.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S <already5chosen@yahoo.com> writes:

On Thu, 12 Sep 2024 14:44:03 +0100
Bart <bc@freeuk.com> wrote:

On 12/09/2024 13:20, Janis Papanagnou wrote:

* Handling an unknown number of parameters is not automatic:

For the latter, the example uses a fixed array size. For a dynamic
array size, call 'strtoargs' with a count of 0 to first determine the
number of args, then allocate an array and call again to populate it.


-------------------------------------------
#include <windows.h>
#include <stdio.h>
#include <string.h>

int strtoargs(char* cmd, char** dest, int count) {
enum {ilen=1024};
char item[ilen];
int n=0, length, c;
char *p=cmd, *q, *end=&item[ilen-1];

while (c=*p++) {
if (c==' ' || c=='\t')
continue;
else if (c=='"') {
length=0;
q=item;

while (c=*p++, c!='"') {
if (c==0) {
--p;
break;
} else {
if (q<end) *q++ = c;
}
}
goto store;
} else {
length=0;
q=item;
--p;

while (c=*p++, c!=' ' && c!='\t') {
if (c==0) {
--p;
break;
} else {
if (q<end) *q++ = c;
}
}

store: *q=0;
++n;
if (n<=count) dest[n-1]=strdup(item);
}
}
return n;
}

int main(void) {
char* cmdline;
enum {cap=30};
char* args[cap];
int n;

cmdline = GetCommandLineA();

n=strtoargs(cmdline, args, cap);

for (int i=0; i<n; ++i) {
if (i<cap)
printf("%d %s\n", i, args[i]);
else
printf("%d <overflow>\n", i);
}
}
-------------------------------------------

Apart from unnecessary ilen limit, of unnecessary goto into block (I
have nothing against forward gotos out of blocks, but gotos into blocks
make me nervous) and of variable 'length' that serves no purpose, your
code simply does not fulfill requirements of OP.
I can immediately see two gotchas: no handling of escaped double
quotation marks \" and no handling of single quotation marks. Quite
possibly there are additional omissions.

/*
* For most commands, we'll split the rest of the line into
* individual arguments, separated by whitespace. However,
* some commands may wish to process the entire remainder of
* the line as a single argument. Those commands will set the
* ce_splitargs field to zero in the command table.
*/
if (cep->ce_splitargs) {
argcount = 0;
cp = line;
while (*cp != '\0') {
if (argcount == MAX_ARGCOUNT) {
fprintf(stdout,
"Error: More than %d arguments unsupported\n",
MAX_ARGCOUNT);
return 1;
}
while (*cp != '\0' && isspace(*cp)) cp++;
if (*cp == '\0') continue;
if (*cp == '"') {
in_quote = true;
cp++;
}
arglist[argcount++] = cp;
if (in_quote) {
while (*cp != '\0' && *cp != '"') cp++;
in_quote = false;
} else {
while (*cp != '\0' && !isspace(*cp)) cp++;
}
if (*cp == '\0') continue;
*cp++ = '\0';
}
} else {
arglist[0] = command;
arglist[1] = line;
argcount = 2;
}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12.09.2024 16:16, Bart wrote:

Spaces Hard tabs

C++ 829 682 characters

You are counting spaces, tabs and characters to characterize programs'
quality or legibility or what? - Abandon all hope ye who enter here.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 12 Sep 2024 15:37:33 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

<snip code from unidentified source>

Huh?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12.09.2024 17:47, Bonita Montero wrote:

Am 12.09.2024 um 17:30 schrieb Janis Papanagnou:

Not only "roughly imagine"; I think the imperative languages have
so many common basic concepts that you can have a quite good idea,
especially if you know more than just two or three such languages.

Then tell me which lanuage a) has this kind of mostly minimized language-facilities and b) you can layout data structures 1:1
like they fit into memory (platform-dependent).

Don't know what you're trying to say here or what it is you aim
at. If you think it's worth discussing please elaborate.

Yes, C++ can be written with a "C" mindset. But this is nothing
I'd suggest. Better make yourself familiar with the new concepts
(OO, genericity, or even simple things like references). - IMO.

I'm using mostly all new features as you can see from my code.
But the mindset is still the same.

I don't know you or your background or much of your programming.
So please understand that I'm not inclined to make any comments
about you or your code; this would be all speculative and not
contribute anything to the discussion. If you had the impression
that what I said was referring to you personally you were wrong.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/09/2024 16:46, Janis Papanagnou wrote:

On 12.09.2024 16:16, Bart wrote:

Spaces Hard tabs

C++ 829 682 characters

You are counting spaces, tabs and characters to characterize programs' quality or legibility or what? - Abandon all hope ye who enter here.

I'm counting the number of characters needed to express the function.
Since one of BM's claims is that the C++ example was smaller than C.

The difference between the two columns is whether indentation uses hard
tabs or spaces. The C version is more deeply indentated so that makes a difference. (Also the width of the tabs, but everything was measured
with tabs set to 4 characters.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/09/2024 16:16, Michael S wrote:

On Thu, 12 Sep 2024 14:44:03 +0100
Bart <bc@freeuk.com> wrote:

Apart from unnecessary ilen limit, of unnecessary goto into block (I
have nothing against forward gotos out of blocks, but gotos into blocks
make me nervous) and of variable 'length' that serves no purpose, your
code simply does not fulfill requirements of OP.
I can immediately see two gotchas: no handling of escaped double
quotation marks \" and no handling of single quotation marks. Quite
possibly there are additional omissions.

BM's C++ version doesn't handle embedded quotes or single quotes either. Neither expand wildcards into sequences of filename arguments.

But you're right about 'length' which in the end was not used. It makes
the C version even smaller without it.

I wasn't trying to match the OP's requirements, as I don't know what
they are.

If this has to exactly match how the OS parses the command line into
separate parameters, then that's likely to be a significantly more
complex program, especially if it is to run on Linux.

There's probably no point in trying to create such program; you'd need
to find a way of utilising the OS to do the work.

Note that I wasn't posting to solve the OP's problem, but as a
counter-example to that C++ code which literally hurt my eyes to look at.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <vbv6r1$bhc9$1@raubtier-asyl.eternal-september.org>,
Bonita Montero <Bonita.Montero@gmail.com> wrote:

Am 12.09.2024 um 18:28 schrieb Bart:

BM's C++ version doesn't handle embedded quotes or single quotes either.
Neither expand wildcards into sequences of filename arguments.

Ok, that must be impossible with C++.
I just wanted to show how to do it basically and what are the
advantages: no intermediate data structure through functional
progtamming and debug iterators.

All of which would have been fine - and they'd probably all be raving about what a clever boy you are - if you'd only posted it to an appropriate newsgroup.

--
Many (most?) Trump voters voted for him because they thought if they
supported Trump enough, they'd get to *be* Trump.

Similarly, Trump believes that if *he* praises Putin enough, he'll get to *be* Putin.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 12 Sep 2024 19:02:35 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:

Am 12.09.2024 um 18:28 schrieb Bart:

BM's C++ version doesn't handle embedded quotes or single quotes
either.
Neither expand wildcards into sequences of filename arguments.

Ok, that must be impossible with C++.
I just wanted to show how to do it basically and what are the
advantages: no intermediate data structure through functional
progtamming and debug iterators.

Callback is as easy in C as in C++.
Debug iterators not needed in such simple program. At least, I don't
need them.
Here is an equivalent of your parser written in C. It does not look 5
times longer.

Attention! That is an equivalent of Bonita's code, no more and
hopefully no less. The routine does not fulfill requirements of OP!

#include <stddef.h>

void parse(const char* src,
void (*OnToken)(const char* beg, size_t len, void* context),
void* context) {
char c0 = ' ', c1 = '\t';
const char* beg = 0;
for (;;src++) {
char c = *src;
if (c == c0 || c == c1 || c == 0) {
if (beg) {
OnToken(beg, src-beg, context);
c0 = ' ', c1 = '\t';
beg = 0;
}
if (c == 0)
break;
} else if (!beg) {
beg = src;
if (c == '"') {
c0 = c1 = c;
++beg;
}
}
}
}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 12 Sep 2024 17:08:24 +0200, Bonita Montero wrote:

I tried to experiment with that with /proc/<pid>/cmdline. The first
problem was that the arguments aren't space delimited, but broken up
with zeroes.

That’s not a “problem”: it actually simplifies the parsing, because you can unambiguously extract the original command arguments without having to apply any complicated parsing/quoting/unquoting rules.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 12 Sep 2024 17:47:23 +0200, Bonita Montero wrote:

Then tell me which lanuage a) has this kind of mostly minimized language-facilities and b) you can layout data structures 1:1 like they
fit into memory (platform-dependent).

Python.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 Sep 2024 07:27:47 +0200, Bonita Montero wrote:

Am 13.09.2024 um 04:43 schrieb Lawrence D'Oliveiro:

On Thu, 12 Sep 2024 17:47:23 +0200, Bonita Montero wrote:

Then tell me which lanuage a) has this kind of mostly minimized
language-facilities and b) you can layout data structures 1:1 like
they fit into memory (platform-dependent).

Python.

Have a look at <https://gitlab.com/ldo/inotipy_examples/-/blob/master/fanotify_7_example?ref_type=heads>,
and compare the C original from <https://manpages.debian.org/7/fanotify.7.en.html>. The Python code is
half the size and can use high-level async calls.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 Sep 2024 07:28:34 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:

Am 12.09.2024 um 21:38 schrieb Michael S:

Callback is as easy in C as in C++.

Absolutely not because callbacks can't have state in C.

So what is 'context' parameter in my code?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 Sep 2024 06:49:20 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Fri, 13 Sep 2024 07:27:47 +0200, Bonita Montero wrote:

Am 13.09.2024 um 04:43 schrieb Lawrence D'Oliveiro:

On Thu, 12 Sep 2024 17:47:23 +0200, Bonita Montero wrote:

Then tell me which lanuage a) has this kind of mostly minimized
language-facilities and b) you can layout data structures 1:1 like
they fit into memory (platform-dependent).

Python.

Have a look at <https://gitlab.com/ldo/inotipy_examples/-/blob/master/fanotify_7_example?ref_type=heads>,
and compare the C original from <https://manpages.debian.org/7/fanotify.7.en.html>. The Python code is
half the size and can use high-level async calls.

What exactly your response has to do with producing data structures
with predefined layout?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 Sep 2024 14:12:32 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:

Am 13.09.2024 um 10:38 schrieb Michael S:

On Fri, 13 Sep 2024 07:28:34 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:

Am 12.09.2024 um 21:38 schrieb Michael S:

Callback is as easy in C as in C++.

Absolutely not because callbacks can't have state in C.

So what is 'context' parameter in my code?

In C++ the state is an own internal "this"-like object and you dont't
need any explicit parameters.

So, do you admit that callback in C can have state?

Just a [&] and the lambda refers to the whole outer context.

Bad software engineering practice that easily leads to incomprehensible
code.
When in C++ and not in mood for C-style, I very much prefer functors. Ideologically they are the same as C-style context, but a little
sugarized syntactically.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S <already5chosen@yahoo.com> writes:

[..iterate over words in a string..]

#include <stddef.h>

void parse(const char* src,
void (*OnToken)(const char* beg, size_t len, void* context),
void* context) {
char c0 = ' ', c1 = '\t';
const char* beg = 0;
for (;;src++) {
char c = *src;
if (c == c0 || c == c1 || c == 0) {
if (beg) {
OnToken(beg, src-beg, context);
c0 = ' ', c1 = '\t';
beg = 0;
}
if (c == 0)
break;
} else if (!beg) {
beg = src;
if (c == '"') {
c0 = c1 = c;
++beg;
}
}
}
}

I couldn't resist writing some code along similar lines. The
entry point is words_do(), which returns one on success and
zero if the end of string is reached inside double quotes.


typedef struct gopher_s *Gopher;
struct gopher_s { void (*f)( Gopher, const char *, const char * ); };

static _Bool collect_word( const char *, const char *, _Bool, Gopher ); static _Bool is_space( char );


_Bool
words_do( const char *s, Gopher go ){
char c = *s;

return
is_space(c) ? words_do( s+1, go ) :
c ? collect_word( s, s, 1, go ) :
/***************/ 1;
}

_Bool
collect_word( const char *s, const char *r, _Bool w, Gopher go ){
char c = *s;

return
c == 0 ? go->f( go, r, s ), w :
is_space(c) && w ? go->f( go, r, s ), words_do( s, go ) :
/***************/ collect_word( s+1, r, w ^ c == '"', go );
}

_Bool
is_space( char c ){
return c == ' ' || c == '\t';
}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 Sep 2024 11:49:35 +0300, Michael S wrote:

What exactly your response has to do with producing data structures with predefined layout?

Look at those structures: they have a specific predefined layout.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 Sep 2024 14:12:32 +0200, Bonita Montero wrote:

In C++ the state is an own internal "this"-like object and you dont't
need any explicit parameters.

But you need a calling convention that passes “this” explicitly.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/09/2024 23:04, Lawrence D'Oliveiro wrote:

On Fri, 13 Sep 2024 11:49:35 +0300, Michael S wrote:

What exactly your response has to do with producing data structures with
predefined layout?

Look at those structures: they have a specific predefined layout.

Look at them where? One link is a man-page with several C structs
defined (triple-spaced for some reason).

But I can't see anything in the Python link that looks like it might be defining a struct layout.

So I would also question what it has to do with it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 14 Sep 2024 01:42:05 +0200, Bonita Montero wrote:

Am 14.09.2024 um 00:24 schrieb Lawrence D'Oliveiro:

On Fri, 13 Sep 2024 14:12:32 +0200, Bonita Montero wrote:

In C++ the state is an own internal "this"-like object and you dont't
need any explicit parameters.

But you need a calling convention that passes “this” explicitly.

That's not part of the C++-language.

If the implementation doesn’t do it, it doesn’t work.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 Sep 2024 23:48:38 +0100, Bart wrote:

On 13/09/2024 23:04, Lawrence D'Oliveiro wrote:

On Fri, 13 Sep 2024 11:49:35 +0300, Michael S wrote:

What exactly your response has to do with producing data structures
with predefined layout?

Look at those structures: they have a specific predefined layout.

One link is a man-page with several C structs defined ...

Correct. Structures that the Python wrapper is able to map exactly.

And the choice between which particular structure variants to use is
dynamic, dependent on the event type. So the Python wrapper is able to dynamically generate a suitable type-safe wrapper -- something that a statically-typed language cannot do.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/09/2024 02:41, Lawrence D'Oliveiro wrote:

On Fri, 13 Sep 2024 23:48:38 +0100, Bart wrote:

On 13/09/2024 23:04, Lawrence D'Oliveiro wrote:

On Fri, 13 Sep 2024 11:49:35 +0300, Michael S wrote:

What exactly your response has to do with producing data structures
with predefined layout?

Look at those structures: they have a specific predefined layout.

One link is a man-page with several C structs defined ...

Correct. Structures that the Python wrapper is able to map exactly.

And the choice between which particular structure variants to use is
dynamic, dependent on the event type. So the Python wrapper is able to dynamically generate a suitable type-safe wrapper -- something that a statically-typed language cannot do.

So, where IS the struct defined in that Python code? Which line number?

If it is the defined is elsewhere, then that Python proves nothing.

For example, where is this struct:

struct fanotify_event_info_header {
__u8 info_type;
__u8 pad;
__u16 len;
};

defined in that Python? I have an idea how this might be done using the
ctypes module for example, but it's not pretty. However I'm not even
seeing that.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 14 Sep 2024 10:58:34 +0100, Bart wrote:

So, where IS the struct defined in that Python code?

In the API wrapper module, of course.

<https://gitlab.com/ldo/inotipy>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 13 Sep 2024 09:05:04 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

Michael S <already5chosen@yahoo.com> writes:

[..iterate over words in a string..]

#include <stddef.h>

void parse(const char* src,
void (*OnToken)(const char* beg, size_t len, void* context),
void* context) {
char c0 = ' ', c1 = '\t';
const char* beg = 0;
for (;;src++) {
char c = *src;
if (c == c0 || c == c1 || c == 0) {
if (beg) {
OnToken(beg, src-beg, context);
c0 = ' ', c1 = '\t';
beg = 0;
}
if (c == 0)
break;
} else if (!beg) {
beg = src;
if (c == '"') {
c0 = c1 = c;
++beg;
}
}
}
}

I couldn't resist writing some code along similar lines. The
entry point is words_do(), which returns one on success and
zero if the end of string is reached inside double quotes.

typedef struct gopher_s *Gopher;
struct gopher_s { void (*f)( Gopher, const char *, const char * ); };

static _Bool collect_word( const char *, const char *, _Bool,
Gopher ); static _Bool is_space( char );

_Bool
words_do( const char *s, Gopher go ){
char c = *s;

return
is_space(c) ? words_do( s+1, go )
: c ? collect_word( s, s, 1, go )
: /***************/ 1;
}

_Bool
collect_word( const char *s, const char *r, _Bool w, Gopher go ){
char c = *s;

return
c == 0 ? go->f( go, r, s ), w
: is_space(c) && w ? go->f( go, r, s ), words_do( s, go )
: /***************/ collect_word( s+1, r, w ^ c == '"', go );
}

_Bool
is_space( char c ){
return c == ' ' || c == '\t';
}

Can you give an example implementation of go->f() ?
It seems to me that it would have to use CONTAINING_RECORD or
container_of or analogous non-standard macro.

Also, while formally the program is written in C, by spirit it's
something else. May be, Lisp.
Lisp compilers are known to be very good at tail call elimination.
C compilers also can do it, but not reliably. In this particular case I
am afraid that common C compilers will implement it as written, i.e.
without turning recursion into iteration.

Tested on godbolt.
gcc -O2 turns it into iteration starting from v.4.4
clang -O2 turns it into iteration starting from v.4.0
Latest icc still does not turn it into iteration at least along one
code paths.
Latest MSVC implements it as written, 100% recursion.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S <already5chosen@yahoo.com> writes:

[comments reordered]

Also, while formally the program is written in C, by spirit it's
something else. May be, Lisp.

I would call it a functional style, but still C. Not a C style
as most people are used to seeing it, I grant you that. I still
think of it as C though.

Lisp compilers are known to be very good at tail call elimination.
C compilers also can do it, but not reliably. In this particular
case I am afraid that common C compilers will implement it as
written, i.e. without turning recursion into iteration.

I routinely use gcc and clang, and both are good at turning
this kind of mutual recursion into iteration (-Os or higher,
although clang was able to eliminate all the recursion at -O1).
I agree the recursion elimination is not as reliable as one
would like; in practice though I find it quite usable.

Tested on godbolt.
gcc -O2 turns it into iteration starting from v.4.4
clang -O2 turns it into iteration starting from v.4.0

Both as expected.

Latest icc still does not turn it into iteration at least along one
code paths.

That's disappointing, but good to know.

Latest MSVC implements it as written, 100% recursion.

I'm not surprised at all. In my admittedly very limited experience,
MSVC is garbage.

Can you give an example implementation of go->f() ?
It seems to me that it would have to use CONTAINING_RECORD or
container_of or analogous non-standard macro.

You say that like you think such macros don't have well-defined
behavior. If I needed such a macro probably I would just
define it myself (and would be confident that it would
work correctly).

In this case I don't need a macro because I would put the gopher
struct at the beginning of the containing struct. For example:

#include <stdio.h>

typedef struct {
struct gopher_s go;
unsigned words;
} WordCounter;


static void
print_word( Gopher go, const char *s, const char *t ){
WordCounter *context = (void*) go;
int n = t-s;

printf( " word: %.*s\n", n, s );
context->words ++;
}


int
main(){
WordCounter wc = { { print_word }, 0 };
char *words = "\tthe quick \"brown fox\" jumps over the lazy dog.";

words_do( words, &wc.go );
printf( "\n" );
printf( " There were %u words found\n", wc.words );
return 0;
}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 16 Sep 2024 00:52:26 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

Michael S <already5chosen@yahoo.com> writes:

[comments reordered]

Also, while formally the program is written in C, by spirit it's
something else. May be, Lisp.

I would call it a functional style, but still C. Not a C style
as most people are used to seeing it, I grant you that. I still
think of it as C though.

Lisp compilers are known to be very good at tail call elimination.
C compilers also can do it, but not reliably. In this particular
case I am afraid that common C compilers will implement it as
written, i.e. without turning recursion into iteration.

I routinely use gcc and clang, and both are good at turning
this kind of mutual recursion into iteration (-Os or higher,
although clang was able to eliminate all the recursion at -O1).
I agree the recursion elimination is not as reliable as one
would like; in practice though I find it quite usable.

Tested on godbolt.
gcc -O2 turns it into iteration starting from v.4.4
clang -O2 turns it into iteration starting from v.4.0

Both as expected.

So, only 15 years for gcc and only 7 years for clang.

Latest icc still does not turn it into iteration at least along one
code paths.

That's disappointing, but good to know.

Latest MSVC implements it as written, 100% recursion.

I'm not surprised at all. In my admittedly very limited experience,
MSVC is garbage.

For sort of code that is important to me, gcc, clang and MSVC tend to
generate code of similar quality. clang is most suspect of the three to sometimes unexpectedly produce utter crap. On the other hand, it is
sometimes most brilliant.
In case of gcc, I hate that recently they put tree-slp-vectorize under
-O2 umbrella.

Can you give an example implementation of go->f() ?
It seems to me that it would have to use CONTAINING_RECORD or
container_of or analogous non-standard macro.

You say that like you think such macros don't have well-defined
behavior. If I needed such a macro probably I would just
define it myself (and would be confident that it would
work correctly).

In this case I don't need a macro because I would put the gopher
struct at the beginning of the containing struct. For example:

#include <stdio.h>

typedef struct {
struct gopher_s go;
unsigned words;
} WordCounter;

static void
print_word( Gopher go, const char *s, const char *t ){
WordCounter *context = (void*) go;

That's what I was missing. Simple and adequate.

int n = t-s;

printf( " word: %.*s\n", n, s );
context->words ++;
}

int
main(){
WordCounter wc = { { print_word }, 0 };
char *words = "\tthe quick \"brown fox\" jumps over the lazy dog.";

words_do( words, &wc.go );
printf( "\n" );
printf( " There were %u words found\n", wc.words );
return 0;
}

There are couple of differences between your and my parsing.
1. "42""43"
You parse it as a single word, I split. It seems, your behavior is
closer to that of both bash and cmd.exe
2. I strip " characters from "-delimited words. You seem to leave them.
In this case what I do is more similar to both bash and cmd.exe

Not that it matters.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S <already5chosen@yahoo.com> writes:

On Mon, 16 Sep 2024 00:52:26 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

Michael S <already5chosen@yahoo.com> writes:

[comments reordered]

Also, while formally the program is written in C, by spirit it's
something else. May be, Lisp.

I would call it a functional style, but still C. Not a C style
as most people are used to seeing it, I grant you that. I still
think of it as C though.

Lisp compilers are known to be very good at tail call elimination.
C compilers also can do it, but not reliably. In this particular
case I am afraid that common C compilers will implement it as
written, i.e. without turning recursion into iteration.

I routinely use gcc and clang, and both are good at turning
this kind of mutual recursion into iteration (-Os or higher,
although clang was able to eliminate all the recursion at -O1).
I agree the recursion elimination is not as reliable as one
would like; in practice though I find it quite usable.

Tested on godbolt.
gcc -O2 turns it into iteration starting from v.4.4
clang -O2 turns it into iteration starting from v.4.0
Latest icc still does not turn it into iteration at least along one
code paths.

That's disappointing, but good to know.

Latest MSVC implements it as written, 100% recursion.

I'm not surprised at all. In my admittedly very limited experience,
MSVC is garbage.

For sort of code that is important to me, gcc, clang and MSVC tend to generate code of similar quality.

To clarify, my earlier comment about MSVC is about what it thinks
the language is, not anything about quality of generated code. But
the lack of tail call elimination fits in with what else I have
seen.

clang is most suspect of the three to sometimes unexpectedly
produce utter crap. On the other hand, it is sometimes most
brilliant.

That's interesting. Recently I encountered a problem where clang
did just fine but gcc generated bad code under -O3.

In case of gcc, I hate that recently they put tree-slp-vectorize
under -O2 umbrella.

Yes, gcc is like a box of chocolates - you never know what you're
going to get.

Can you give an example implementation of go->f() ?
It seems to me that it would have to use CONTAINING_RECORD or
container_of or analogous non-standard macro.

You say that like you think such macros don't have well-defined
behavior. If I needed such a macro probably I would just
define it myself (and would be confident that it would
work correctly).

In this case I don't need a macro because I would put the gopher
struct at the beginning of the containing struct. For example:

#include <stdio.h>

typedef struct {
struct gopher_s go;
unsigned words;
} WordCounter;


static void
print_word( Gopher go, const char *s, const char *t ){
WordCounter *context = (void*) go;

That's what I was missing. Simple and adequate.

I now prefer this technique for callbacks. Cuts down on the
number of parameters, safer than a (void*) parameter, and it puts
the function pointer near the context state so it's easier to
connect the two (and less worry about them getting out of sync).

int n = t-s;

printf( " word: %.*s\n", n, s );
context->words ++;
}

int
main(){
WordCounter wc = { { print_word }, 0 };
char *words = "\tthe quick \"brown fox\" jumps over the lazy dog.";

words_do( words, &wc.go );
printf( "\n" );
printf( " There were %u words found\n", wc.words );
return 0;
}

There are couple of differences between your and my parsing.
1. "42""43"
You parse it as a single word, I split. It seems, your behavior is
closer to that of both bash and cmd.exe

Yes. I chose that deliberately because I often use patterns like
foo."$suffix" and it made sense to allow quoted subparts for that
reason.

2. I strip " characters from "-delimited words. You seem to leave them.
In this case what I do is more similar to both bash and cmd.exe

I do, both because it's easier, and in case the caller wants to
know where the quotes are. If it's important to strip them out
it's up to the caller to do that.

Not that it matters.

Yeah. These choices are only minor details; the general
approach taken is the main thing.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S <already5chosen@yahoo.com> wrote:

On Fri, 13 Sep 2024 09:05:04 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

Michael S <already5chosen@yahoo.com> writes:

[..iterate over words in a string..]

I couldn't resist writing some code along similar lines. The
entry point is words_do(), which returns one on success and
zero if the end of string is reached inside double quotes.


typedef struct gopher_s *Gopher;
struct gopher_s { void (*f)( Gopher, const char *, const char * ); };

static _Bool collect_word( const char *, const char *, _Bool,
Gopher ); static _Bool is_space( char );


_Bool
words_do( const char *s, Gopher go ){
char c = *s;

return
is_space(c) ? words_do( s+1, go )
: c ? collect_word( s, s, 1, go )
: /***************/ 1;
}

_Bool
collect_word( const char *s, const char *r, _Bool w, Gopher go ){
char c = *s;

return
c == 0 ? go->f( go, r, s ), w
: is_space(c) && w ? go->f( go, r, s ), words_do( s, go )
: /***************/ collect_word( s+1, r, w ^ c == '"', go );
}

_Bool
is_space( char c ){
return c == ' ' || c == '\t';
}

<snip>

Tested on godbolt.
gcc -O2 turns it into iteration starting from v.4.4
clang -O2 turns it into iteration starting from v.4.0
Latest icc still does not turn it into iteration at least along one
code paths.
Latest MSVC implements it as written, 100% recursion.

I tested using gcc 12. AFAICS calls to 'go->f' in 'collect_word'
are not tail calls and gcc 12 compiles them as normal call.
The other calls are compiled to jumps. But call to 'collect_word'
in 'words_do' is not "sibicall" and dependig in calling convention
compiler may treat it narmal call. Two other calls, that is
call to 'words_do' in 'words_do' and call to 'collect_word' in
'collect_word' are clearly tail self recursion and compiler
should always optimize them to a jump.

--
Waldek Hebisch

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/09/2024 00:46, Michael S wrote:

On Tue, 17 Sep 2024 22:34:33 -0000 (UTC)
antispam@fricas.org wrote:

Michael S <already5chosen@yahoo.com> wrote:

On Fri, 13 Sep 2024 09:05:04 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

Michael S <already5chosen@yahoo.com> writes:

[..iterate over words in a string..]

I couldn't resist writing some code along similar lines. The
entry point is words_do(), which returns one on success and
zero if the end of string is reached inside double quotes.


typedef struct gopher_s *Gopher;
struct gopher_s { void (*f)( Gopher, const char *, const char * );
};

static _Bool collect_word( const char *, const char *, _Bool,
Gopher ); static _Bool is_space( char );


_Bool
words_do( const char *s, Gopher go ){
char c = *s;

return
is_space(c) ? words_do( s+1, go )
: c ? collect_word( s, s, 1, go )
: /***************/ 1;
}

_Bool
collect_word( const char *s, const char *r, _Bool w, Gopher go ){
char c = *s;

return
c == 0 ? go->f( go, r, s ), w
: is_space(c) && w ? go->f( go, r, s ), words_do( s, go )
: /***************/ collect_word( s+1, r, w ^ c == '"', go );
}

_Bool
is_space( char c ){
return c == ' ' || c == '\t';
}

<snip>

Tested on godbolt.
gcc -O2 turns it into iteration starting from v.4.4
clang -O2 turns it into iteration starting from v.4.0
Latest icc still does not turn it into iteration at least along one
code paths.
Latest MSVC implements it as written, 100% recursion.

I tested using gcc 12. AFAICS calls to 'go->f' in 'collect_word'
are not tail calls and gcc 12 compiles them as normal call.

Naturally.

The other calls are compiled to jumps. But call to 'collect_word'
in 'words_do' is not "sibicall" and dependig in calling convention
compiler may treat it narmal call. Two other calls, that is
call to 'words_do' in 'words_do' and call to 'collect_word' in
'collect_word' are clearly tail self recursion and compiler
should always optimize them to a jump.

"Should" or not, MSVC does not eliminate them.

The funny thing is that it does eliminate all four calls after I rewrote
the code in more boring style.

static
_Bool
collect_word( const char *s, const char *r, _Bool w, Gopher go ){
char c = *s;
#if 1
if (c == 0) {
go->f( go, r, s );
return w;
}
if (is_space(c) && w) {
go->f( go, r, s );
return words_do( s, go );
}
return collect_word( s+1, r, w ^ c == '"', go );
#else
return
c == 0 ? go->f( go, r, s ), w :
is_space(c) && w ? go->f( go, r, s ), words_do( s, go ) :
/***************/ collect_word( s+1, r, w ^ c == '"', go );
#endif
}

I find such a coding style pretty much impossible to grasp and
unpleasant to look at. I had to refactor it like this:

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

static_Bool collect_word(char *s, char *r, _Bool w, Gopher go ) {
char c = *s;
#if 1
if (c == 0) {
go->f(go, r, s);
return w;
}
if (is_space(c) && w) {
go->f(go, r, s);
return words_do(s, go);
}
return collect_word(s+1, r, (w ^ c) == '"', go);

#else
if (c == 0) {
go->f(go, r, s);
return w;
}
else if (is_space(c) && w) {
go->f(go, r, s);
return words_do(s, go);
}
else {
return collect_word(s+1, r, (w ^ c) = '"', go);
}

#endif
}

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

When I'd finished, I realised that those two conditional blocks do more
or less the same thing! If that's what you mean by 'boring', then I'll
all for it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

antispam@fricas.org writes:

Michael S <already5chosen@yahoo.com> wrote:

On Fri, 13 Sep 2024 09:05:04 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

Michael S <already5chosen@yahoo.com> writes:

[..iterate over words in a string..]

I couldn't resist writing some code along similar lines. The
entry point is words_do(), which returns one on success and
zero if the end of string is reached inside double quotes.


typedef struct gopher_s *Gopher;
struct gopher_s { void (*f)( Gopher, const char *, const char * ); };

static _Bool collect_word( const char *, const char *, _Bool,
Gopher ); static _Bool is_space( char );


_Bool
words_do( const char *s, Gopher go ){
char c = *s;

return
is_space(c) ? words_do( s+1, go )
: c ? collect_word( s, s, 1, go )
: /***************/ 1;
}

_Bool
collect_word( const char *s, const char *r, _Bool w, Gopher go ){
char c = *s;

return
c == 0 ? go->f( go, r, s ), w
: is_space(c) && w ? go->f( go, r, s ), words_do( s, go )
: /***************/ collect_word( s+1, r, w ^ c == '"', go );
}

_Bool
is_space( char c ){
return c == ' ' || c == '\t';
}

<snip>

Tested on godbolt.
gcc -O2 turns it into iteration starting from v.4.4
clang -O2 turns it into iteration starting from v.4.0
Latest icc still does not turn it into iteration at least along one
code paths.
Latest MSVC implements it as written, 100% recursion.

I tested using gcc 12. AFAICS calls to 'go->f' in 'collect_word'
are not tail calls and gcc 12 compiles them as normal call.

Right, they are not tail calls, simply ordinary calls (indirect
calls, but still ordinary calls).

The other calls are compiled to jumps. But call to 'collect_word'
in 'words_do' is not "sibicall" and dependig in calling convention
compiler may treat it narmal call. Two other calls, that is
call to 'words_do' in 'words_do' and call to 'collect_word' in
'collect_word' are clearly tail self recursion and compiler
should always optimize them to a jump.

Yes, a different set of calling conventions could result in the
call to collect_word from words_do being a normal call. It
should be possible to correct that by adding two dummy parameters
to words_do(), and wrapping the result in one outer function so
that there is at most one extra call besides the call from outide.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 17 Sep 2024 22:34:33 -0000 (UTC)
antispam@fricas.org wrote:

Michael S <already5chosen@yahoo.com> wrote:

On Fri, 13 Sep 2024 09:05:04 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

Michael S <already5chosen@yahoo.com> writes:

[..iterate over words in a string..]

I couldn't resist writing some code along similar lines. The
entry point is words_do(), which returns one on success and
zero if the end of string is reached inside double quotes.


typedef struct gopher_s *Gopher;
struct gopher_s { void (*f)( Gopher, const char *, const char * );
};

static _Bool collect_word( const char *, const char *, _Bool,
Gopher ); static _Bool is_space( char );


_Bool
words_do( const char *s, Gopher go ){
char c = *s;

return
is_space(c) ? words_do( s+1, go )
: c ? collect_word( s, s, 1, go )
: /***************/ 1;
}

_Bool
collect_word( const char *s, const char *r, _Bool w, Gopher go ){
char c = *s;

return
c == 0 ? go->f( go, r, s ), w
: is_space(c) && w ? go->f( go, r, s ), words_do( s, go )
: /***************/ collect_word( s+1, r, w ^ c == '"', go );
}

_Bool
is_space( char c ){
return c == ' ' || c == '\t';
}

<snip>

Tested on godbolt.
gcc -O2 turns it into iteration starting from v.4.4
clang -O2 turns it into iteration starting from v.4.0
Latest icc still does not turn it into iteration at least along one
code paths.
Latest MSVC implements it as written, 100% recursion.

I tested using gcc 12. AFAICS calls to 'go->f' in 'collect_word'
are not tail calls and gcc 12 compiles them as normal call.

Naturally.

The other calls are compiled to jumps. But call to 'collect_word'
in 'words_do' is not "sibicall" and dependig in calling convention
compiler may treat it narmal call. Two other calls, that is
call to 'words_do' in 'words_do' and call to 'collect_word' in
'collect_word' are clearly tail self recursion and compiler
should always optimize them to a jump.

"Should" or not, MSVC does not eliminate them.

The funny thing is that it does eliminate all four calls after I rewrote
the code in more boring style.

_Bool
words_do( const char *s, Gopher go ){
char c = *s;
#if 1
if (is_space(c))
return words_do( s+1, go );
if (c)
return collect_word( s, s, 1, go );
return 1;
#else
return
is_space(c) ? words_do( s+1, go ) :
c ? collect_word( s, s, 1, go ):
/***************/ 1;
#endif
}

static
_Bool
collect_word( const char *s, const char *r, _Bool w, Gopher go ){
char c = *s;
#if 1
if (c == 0) {
go->f( go, r, s );
return w;
}
if (is_space(c) && w) {
go->f( go, r, s );
return words_do( s, go );
}
return collect_word( s+1, r, w ^ c == '"', go );
#else
return
c == 0 ? go->f( go, r, s ), w :
is_space(c) && w ? go->f( go, r, s ), words_do( s, go ) :
/***************/ collect_word( s+1, r, w ^ c == '"', go );
#endif
}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S <already5chosen@yahoo.com> writes:

On Tue, 17 Sep 2024 22:34:33 -0000 (UTC)
antispam@fricas.org wrote:

Michael S <already5chosen@yahoo.com> wrote:

On Fri, 13 Sep 2024 09:05:04 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

Michael S <already5chosen@yahoo.com> writes:

[..iterate over words in a string..]

I couldn't resist writing some code along similar lines. The
entry point is words_do(), which returns one on success and
zero if the end of string is reached inside double quotes.


typedef struct gopher_s *Gopher;
struct gopher_s { void (*f)( Gopher, const char *, const char * );
};

static _Bool collect_word( const char *, const char *, _Bool,
Gopher ); static _Bool is_space( char );


_Bool
words_do( const char *s, Gopher go ){
char c = *s;

return
is_space(c) ? words_do( s+1, go )
: c ? collect_word( s, s, 1, go )
: /***************/ 1;
}

_Bool
collect_word( const char *s, const char *r, _Bool w, Gopher go ){
char c = *s;

return
c == 0 ? go->f( go, r, s ), w
: is_space(c) && w ? go->f( go, r, s ), words_do( s, go )
: /***************/ collect_word( s+1, r, w ^ c == '"', go );
}

_Bool
is_space( char c ){
return c == ' ' || c == '\t';
}

<snip>

Tested on godbolt.
gcc -O2 turns it into iteration starting from v.4.4
clang -O2 turns it into iteration starting from v.4.0
Latest icc still does not turn it into iteration at least along one
code paths.
Latest MSVC implements it as written, 100% recursion.

I tested using gcc 12. AFAICS calls to 'go->f' in 'collect_word'
are not tail calls and gcc 12 compiles them as normal call.

Naturally.

The other calls are compiled to jumps. But call to 'collect_word'
in 'words_do' is not "sibicall" and dependig in calling convention
compiler may treat it narmal call. Two other calls, that is
call to 'words_do' in 'words_do' and call to 'collect_word' in
'collect_word' are clearly tail self recursion and compiler
should always optimize them to a jump.

"Should" or not, MSVC does not eliminate them.

The funny thing is that it does eliminate all four calls after I rewrote
the code in more boring style.

_Bool
words_do( const char *s, Gopher go ){
char c = *s;
#if 1
if (is_space(c))
return words_do( s+1, go );
if (c)
return collect_word( s, s, 1, go );
return 1;
#else
return
is_space(c) ? words_do( s+1, go ) :
c ? collect_word( s, s, 1, go ):
/***************/ 1;
#endif
}

static
_Bool
collect_word( const char *s, const char *r, _Bool w, Gopher go ){
char c = *s;
#if 1
if (c == 0) {
go->f( go, r, s );
return w;
}
if (is_space(c) && w) {
go->f( go, r, s );
return words_do( s, go );
}
return collect_word( s+1, r, w ^ c == '"', go );
#else
return
c == 0 ? go->f( go, r, s ), w :
is_space(c) && w ? go->f( go, r, s ), words_do( s, go ) :
/***************/ collect_word( s+1, r, w ^ c == '"', go );
#endif
}

That's amusing. :)

Do you know if icc will do tail call elimination for
the boring version of the code?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 18 Sep 2024 02:46:11 +0300, Michael S wrote:

"Should" or not, MSVC does not eliminate them.

Another reason to stay away from MSVC?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 17 Sep 2024 18:31:10 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

That's amusing. :)

Do you know if icc will do tail call elimination for
the boring version of the code?

Output of 'icc -O2' does recursive inlining to quite significant depth,
so it is rather hard to follow.
But it seems that the answer is "No".

Anyway, by now icc is mostly of historical interest.
They ceased independent compiler development 2-3 years ago and turned
into yet another LLVM/clang distributor.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 18 Sep 2024 02:20:18 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Wed, 18 Sep 2024 02:46:11 +0300, Michael S wrote:

"Should" or not, MSVC does not eliminate them.

Another reason to stay away from MSVC?

No, it isn't.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 18 Sep 2024 01:07:17 +0100
Bart <bc@freeuk.com> wrote:

On 18/09/2024 00:46, Michael S wrote:

On Tue, 17 Sep 2024 22:34:33 -0000 (UTC)
antispam@fricas.org wrote:

Michael S <already5chosen@yahoo.com> wrote:

On Fri, 13 Sep 2024 09:05:04 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

Michael S <already5chosen@yahoo.com> writes:

[..iterate over words in a string..]

I couldn't resist writing some code along similar lines. The
entry point is words_do(), which returns one on success and
zero if the end of string is reached inside double quotes.


typedef struct gopher_s *Gopher;
struct gopher_s { void (*f)( Gopher, const char *, const char *
); };

static _Bool collect_word( const char *, const char *, _Bool,
Gopher ); static _Bool is_space( char );


_Bool
words_do( const char *s, Gopher go ){
char c = *s;

return
is_space(c) ? words_do( s+1, go )
: c ? collect_word( s, s, 1, go )
: /***************/ 1;
}

_Bool
collect_word( const char *s, const char *r, _Bool w, Gopher go ){
char c = *s;

return
c == 0 ? go->f( go, r, s ), w
: is_space(c) && w ? go->f( go, r, s ), words_do( s, go )
: /***************/ collect_word( s+1, r, w ^ c == '"', go );
}

_Bool
is_space( char c ){
return c == ' ' || c == '\t';
}

<snip>

Tested on godbolt.
gcc -O2 turns it into iteration starting from v.4.4
clang -O2 turns it into iteration starting from v.4.0
Latest icc still does not turn it into iteration at least along
one code paths.
Latest MSVC implements it as written, 100% recursion.

I tested using gcc 12. AFAICS calls to 'go->f' in 'collect_word'
are not tail calls and gcc 12 compiles them as normal call.

Naturally.

The other calls are compiled to jumps. But call to 'collect_word'
in 'words_do' is not "sibicall" and dependig in calling convention
compiler may treat it narmal call. Two other calls, that is
call to 'words_do' in 'words_do' and call to 'collect_word' in
'collect_word' are clearly tail self recursion and compiler
should always optimize them to a jump.

"Should" or not, MSVC does not eliminate them.

The funny thing is that it does eliminate all four calls after I
rewrote the code in more boring style.

static
_Bool
collect_word( const char *s, const char *r, _Bool w, Gopher go ){
char c = *s;
#if 1
if (c == 0) {
go->f( go, r, s );
return w;
}
if (is_space(c) && w) {
go->f( go, r, s );
return words_do( s, go );
}
return collect_word( s+1, r, w ^ c == '"', go );
#else
return
c == 0 ? go->f( go, r, s ), w :
is_space(c) && w ? go->f( go, r, s ), words_do( s, go ) :
/***************/ collect_word( s+1, r, w ^ c == '"', go );
#endif
}

I find such a coding style pretty much impossible to grasp and
unpleasant to look at. I had to refactor it like this:

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

static_Bool collect_word(char *s, char *r, _Bool w, Gopher go ) {
char c = *s;
#if 1
if (c == 0) {
go->f(go, r, s);
return w;
}
if (is_space(c) && w) {
go->f(go, r, s);
return words_do(s, go);
}
return collect_word(s+1, r, (w ^ c) == '"', go);

That's not how it was written in original. Should be:
return collect_word(s+1, r, w ^ c == '"', go);
Not the same thing at all. https://en.cppreference.com/w/c/language/operator_precedence

#else
if (c == 0) {
go->f(go, r, s);
return w;
}
else if (is_space(c) && w) {
go->f(go, r, s);
return words_do(s, go);
}
else {
return collect_word(s+1, r, (w ^ c) = '"', go);

The same here.

}

#endif
}

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

When I'd finished, I realised that those two conditional blocks do
more or less the same thing! If that's what you mean by 'boring',
then I'll all for it.

Since I am not accustomed to the functional programming style, for me
even a boring variant is way too entertaining.
I prefer mundane (untested, could be buggy):

static
const char* collect_word(const char *s) {
_Bool w = 0;
char c;
while ((c = *s) != 0) {
if (!w && is_space(c))
break;
if (c == '"')
w = !w;
++s;
}
return s;
}

void words_do(const char *s, Gopher go ){
char c;
while ((c = *s) != 0) {
if (is_space(c)) {
++s;
} else {
const char *r = s;
s = collect_word(s);
go->f(go, r, s);
}
}
}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/09/2024 09:43, Michael S wrote:

On Wed, 18 Sep 2024 01:07:17 +0100
Bart <bc@freeuk.com> wrote:

I find such a coding style pretty much impossible to grasp and
unpleasant to look at. I had to refactor it like this:

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

static_Bool collect_word(char *s, char *r, _Bool w, Gopher go ) {
char c = *s;
#if 1
if (c == 0) {
go->f(go, r, s);
return w;
}
if (is_space(c) && w) {
go->f(go, r, s);
return words_do(s, go);
}
return collect_word(s+1, r, (w ^ c) == '"', go);

That's not how it was written in original. Should be:
return collect_word(s+1, r, w ^ c == '"', go);
Not the same thing at all.

So, what you are saying is that it means 'w ^ (c == '"')'? Because there
could be some ambiguity, I put in the brackets. I had to to guess the precedence and chose the one that seemed more plausible, but I guessed
wrong.

Mine version then should be:

return collect_word(s+1, r, w ^ (c == '"'), go);

The same here.

I'm surprised there weren't more typos, but that's not what my post was
about which was presentation and layout.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/09/2024 11:49, Bart wrote:

On 18/09/2024 09:43, Michael S wrote:

On Wed, 18 Sep 2024 01:07:17 +0100
Bart <bc@freeuk.com> wrote:

          return collect_word(s+1, r, (w ^ c) == '"', go);

That's not how it was written in original. Should be:
          return collect_word(s+1, r, w ^ c == '"', go);
Not the same thing at all.

So, what you are saying is that it means 'w ^ (c == '"')'? Because there could be some ambiguity, I put in the brackets. I had to to guess the precedence and chose the one that seemed more plausible, but I guessed
wrong.

There is no ambiguity in the C language - the equality operator has
higher precedence than the bitwise operators and logical operators.

However, I fully agree with you that code is clearer if parenthesis are
added. It makes the code easier to read, easier to write, and
eliminates the risk of programmers (either those writing the code or
those reading it) getting it wrong.

Mine version then should be:

      return collect_word(s+1, r, w ^ (c == '"'), go);

Put spaces around the "+" operator, and it would be perfect :-)

The same here.

I'm surprised there weren't more typos, but that's not what my post was
about which was presentation and layout.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S <already5chosen@yahoo.com> writes:

On Tue, 17 Sep 2024 18:31:10 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

That's amusing. :)

Do you know if icc will do tail call elimination for
the boring version of the code?

Output of 'icc -O2' does recursive inlining to quite significant depth,
so it is rather hard to follow.
But it seems that the answer is "No".

Anyway, by now icc is mostly of historical interest.
They ceased independent compiler development 2-3 years ago and turned
into yet another LLVM/clang distributor.

Thank you, that is good to know.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S <already5chosen@yahoo.com> writes:

[...]

Since I am not accustomed to the functional programming style, for
me even a boring variant [not shown] is way too entertaining. I
prefer mundane (untested, could be buggy):

static
const char* collect_word(const char *s) {
_Bool w = 0;
char c;
while ((c = *s) != 0) {
if (!w && is_space(c))
break;
if (c == '"')
w = !w;
++s;
}
return s;
}

void words_do(const char *s, Gopher go ){
char c;
while ((c = *s) != 0) {
if (is_space(c)) {
++s;
} else {
const char *r = s;
s = collect_word(s);
go->f(go, r, s);
}
}
}

If writing in an imperative-rather-than-functional style, I would
likely gravitate toward something like this:


static const char *process_word( const char *, Gopher );

void
words_do( const char *s, Gopher go ){
char c;

while( c = *s++ ){
if( ! is_space(c) ) s = process_word( s-1, go );
}
}

const char *
process_word( const char *r, Gopher go ){
const char *s = r;
_Bool q = 0;

do q ^= *s++ == '"'; while( *s && (q || !is_space(*s)) );

return go->f( go, r, s ), s;
}


which seems to result in slightly better generated code than my
functional version, in a few spot checks using gcc or clang
under various -O settings (-Os, -O2, -O3).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)