Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Command line globber/tokenizer library for C?
Date: Tue, 17 Sep 2024 03:12:04 -0700
Organization: A noiseless patient Spider
Lines: 131
Message-ID: <86a5g6bnd7.fsf@linuxsc.com>
References: <lkbjchFebk9U1@mid.individual.net> <vbs1om$3jkch$1@raubtier-asyl.eternal-september.org> <vbsb94$1rsji$1@news.xmission.com> <vbsmlb$3o6n2$1@raubtier-asyl.eternal-september.org> <vbsu1d$3p7pp$1@dont-email.me> <vbtj88$1kpm$1@raubtier-asyl.eternal-september.org> <vbujak$733i$3@dont-email.me> <vbum9i$8h2o$1@dont-email.me> <vbur72$99cr$1@dont-email.me> <20240912181625.00006e68@yahoo.com> <vbv4ra$b0hv$2@dont-email.me> <vbv6r1$bhc9$1@raubtier-asyl.eternal-september.org> <20240912223828.00005c10@yahoo.com> <861q1nfsjz.fsf@linuxsc.com> <20240915122211.000058b1@yahoo.com> <86y13savd1.fsf@linuxsc.com> <20240916122338.00000bae@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Tue, 17 Sep 2024 12:12:05 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5475264e673852879913d2eef8867355";
	logging-data="3638128"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX184Z/FkAalSxd0ik2JNkHnswyib1tj2OcQ="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:rcGpEh5F+gOeJ1g+st9NPDHL9AI=
	sha1:w1Q3PctYlghCge0Tp7AC0RQQ/os=
Bytes: 6138

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.