Re: Command line globber/tokenizer library for C?

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.