Re: Command line globber/tokenizer library for C?

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.