Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #162473 > unrolled thread

Freeing a dynamically allocated array of structs within a struct in C

Back to article view | Back to comp.lang.c

Contents

  Freeing a dynamically allocated array of structs within a struct in C Bithov Vinu Student <vinub@calday.co.uk> - 2021-08-29 08:34 -0700
    Re: Freeing a dynamically allocated array of structs within a struct in C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-08-29 15:43 +0000
      Re: Freeing a dynamically allocated array of structs within a struct in C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-08-29 16:12 +0000
        Re: Freeing a dynamically allocated array of structs within a struct in C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-09-06 05:46 -0700
    Re: Freeing a dynamically allocated array of structs within a struct in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-08-29 17:17 +0100
    Re: Freeing a dynamically allocated array of structs within a struct in C Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-29 20:01 +0200
      Re: Freeing a dynamically allocated array of structs within a struct in C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-08-29 18:21 +0000
        Re: Freeing a dynamically allocated array of structs within a struct in C Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-29 20:34 +0200
      Re: Freeing a dynamically allocated array of structs within a struct in C Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-30 09:01 +0200
        Re: Freeing a dynamically allocated array of structs within a struct in C Robert Latest <boblatest@yahoo.com> - 2021-08-31 05:44 +0000
        Re: Freeing a dynamically allocated array of structs within a struct in C Kaz Kylheku <563-365-8930@kylheku.com> - 2021-08-31 07:50 +0000
          Re: Freeing a dynamically allocated array of structs within a struct in C Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-31 10:59 +0200
      Re: Freeing a dynamically allocated array of structs within a struct in C Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-30 09:45 +0200
        Re: Freeing a dynamically allocated array of structs within a struct in C Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-30 10:15 +0200
    Re: Freeing a dynamically allocated array of structs within a struct in C Kaz Kylheku <563-365-8930@kylheku.com> - 2021-08-29 18:14 +0000
    Re: Freeing a dynamically allocated array of structs within a struct in C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-08-29 18:18 +0000
    Re: Freeing a dynamically allocated array of structs within a struct in C Barry Schwarz <schwarzb@delq.com> - 2021-08-29 11:44 -0700
      Re: Freeing a dynamically allocated array of structs within a struct in C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-08-29 19:04 +0000
        Re: Freeing a dynamically allocated array of structs within a struct in C Barry Schwarz <schwarzb@delq.com> - 2021-08-29 14:15 -0700
          Re: Freeing a dynamically allocated array of structs within a struct in C scott@slp53.sl.home (Scott Lurndal) - 2021-08-29 21:19 +0000
            Re: Freeing a dynamically allocated array of structs within a struct in C Barry Schwarz <schwarzb@delq.com> - 2021-08-29 18:14 -0700
          Re: Freeing a dynamically allocated array of structs within a struct in C Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-30 18:27 +0200
        Re: Freeing a dynamically allocated array of structs within a struct in C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-08-30 16:17 +0000
          Re: Freeing a dynamically allocated array of structs within a struct in C James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-30 14:14 -0400
            Re: Freeing a dynamically allocated array of structs within a struct in C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-30 11:39 -0700
              Re: Freeing a dynamically allocated array of structs within a struct in C James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-08-31 10:08 -0400
              Re: Freeing a dynamically allocated array of structs within a struct in C Kaz Kylheku <563-365-8930@kylheku.com> - 2021-09-01 04:40 +0000
                Re: Freeing a dynamically allocated array of structs within a struct in C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-01 00:57 -0700
            Re: Freeing a dynamically allocated array of structs within a struct in C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-08-30 19:16 +0000
              Re: Freeing a dynamically allocated array of structs within a struct in C Manfred <noname@add.invalid> - 2021-08-30 21:49 +0200
            Re: Freeing a dynamically allocated array of structs within a struct in C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-08-30 12:49 -0700
            Re: Freeing a dynamically allocated array of structs within a struct in C scott@slp53.sl.home (Scott Lurndal) - 2021-08-30 22:31 +0000
              Re: Freeing a dynamically allocated array of structs within a struct in C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-09-30 07:04 -0700
      Re: Freeing a dynamically allocated array of structs within a struct in C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-08-29 15:38 -0700
        Re: Freeing a dynamically allocated array of structs within a struct in C Manfred <noname@add.invalid> - 2021-08-30 14:21 +0200
        Re: Freeing a dynamically allocated array of structs within a struct in C Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-30 18:29 +0200
          Re: Freeing a dynamically allocated array of structs within a struct in C Bart <bc@freeuk.com> - 2021-08-30 18:30 +0100
            Re: Freeing a dynamically allocated array of structs within a struct in C Bonita Montero <Bonita.Montero@gmail.com> - 2021-08-31 04:22 +0200

Page 2 of 2 — ← Prev page 1 [2]

#162487

On Sun, 29 Aug 2021 21:19:24 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:

>Barry Schwarz <schwarzb@delq.com> writes:
>>On Sun, 29 Aug 2021 19:04:18 -0000 (UTC), Lew Pitcher
>><lew.pitcher@digitalfreehold.ca> wrote:
>>
>>>FWIW
>>>
>>>On Sun, 29 Aug 2021 11:44:40 -0700, Barry Schwarz wrote:
>>>
>>>> strdup is non-standard but common extension. 
>>>
>>>strdup() is defined in the Open Group (POSIX) Base Specifications Issue 6,
>>>circa 2004. The Open Group's Base Specifications define the minimum standards
>>>for the Unix operating system, including standardized extensions to the C
>>>library.
>>>
>>>[snip]
>>>> strsep appears to be a function you wrote. 
>>>
>>>strsep() comes from the 4.4 BSD Unix standard C library extensions.
>>>
>>>[snip]
>>
>>And if this were comp.unix.programmer then what you say would be
>>relevant but the functions are not standard in C.
>
>And if this were comp.lang.std.c your point would be relevent.

No, comp.lang.std.c is for discussions about the standard.  The is the
place where we discuss how to use the language itself.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#162495

Am 29.08.2021 um 23:15 schrieb Barry Schwarz:
> On Sun, 29 Aug 2021 19:04:18 -0000 (UTC), Lew Pitcher
> <lew.pitcher@digitalfreehold.ca> wrote:
> 
>> FWIW
>>
>> On Sun, 29 Aug 2021 11:44:40 -0700, Barry Schwarz wrote:
>>
>>> strdup is non-standard but common extension.
>>
>> strdup() is defined in the Open Group (POSIX) Base Specifications Issue 6,
>> circa 2004. The Open Group's Base Specifications define the minimum standards
>> for the Unix operating system, including standardized extensions to the C
>> library.
>>
>> [snip]
>>> strsep appears to be a function you wrote.
>>
>> strsep() comes from the 4.4 BSD Unix standard C library extensions.
>>
>> [snip]
> 
> And if this were comp.unix.programmer then what you say would be
> relevant but the functions are not standard in C.

Idiot! You could simply google for it and accept that people use it.

[toc] | [prev] | [next] | [standalone]

#162494

On Sun, 29 Aug 2021 19:04:18 +0000, Lew Pitcher wrote:

> FWIW
> 
> On Sun, 29 Aug 2021 11:44:40 -0700, Barry Schwarz wrote:
> 
>> strdup is non-standard but common extension. 
> 
> strdup() is defined in the Open Group (POSIX) Base Specifications Issue 6,
> circa 2004. The Open Group's Base Specifications define the minimum standards
> for the Unix operating system, including standardized extensions to the C
> library.


If the complaint is that strdup() is not a C standard function, then I submit
that a competent  C programmer would find it trivial to create a function that
duplicates the POSIX strdup() function as documented at 
  https://pubs.opengroup.org/onlinepubs/009696899/functions/strdup.html

I believe that, outside of the function name itself, this C99-compliant code ...
  #include <stdlib.h>
  #include <string.h>

  char *dupstr(const char *string)
  {
    char *temp;

    if ((temp = malloc(strlen(string)+1))) strcpy(temp,string);
    return temp;
  }
satisfies the POSIX requirement.

> [snip]
>> strsep appears to be a function you wrote. 
> 
> strsep() comes from the 4.4 BSD Unix standard C library extensions.
> 
> [snip]

As for strsep(), my personal opinion is that the OP's program would be
better served if the OP had used the C standard function strtok().

-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#162498

On 8/30/21 12:17 PM, Lew Pitcher wrote:
> On Sun, 29 Aug 2021 19:04:18 +0000, Lew Pitcher wrote:
> 
>> FWIW
>>
>> On Sun, 29 Aug 2021 11:44:40 -0700, Barry Schwarz wrote:
...
>>> strsep appears to be a function you wrote. 
>>
>> strsep() comes from the 4.4 BSD Unix standard C library extensions.
>>
>> [snip]
> 
> As for strsep(), my personal opinion is that the OP's program would be
> better served if the OP had used the C standard function strtok().

I was never a strong fan of strtok(), but I lost all desire to use it
after debugging a problem that occurred because one function used
strtok() in a loop to parse one string, and inside that loop called a
subroutine from a third-party library. When that subroutine was changed
to use strtok() to parse a different string, the program failed
catastrophically. If it takes you more than a few seconds to figure out
why, that illustrates part of the problem.

When I want to do what strtok() does, but without such problems, I
normally write C code to do it explicitly rather than calling as
subroutine, it usually takes only a few lines of code. Therefore, I've
no experience with strsep(). For people who can count on POSIX support,
can you give any reason to avoid it? However, to suggest strtok() as a
replacement seems masochistic. Would you care to expand on that comment?

[toc] | [prev] | [next] | [standalone]

#162499

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
>                              For people who can count on POSIX support,
> can you give any reason to avoid it?
[...]

It's not defined by POSIX.  It's from 4.4BSD, and supported by glibc
(and also by newlib and musl) -- but not by Windows.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#162516

On 8/30/21 2:39 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> [...]
>>                              For people who can count on POSIX support,
>> can you give any reason to avoid it?
> [...]
> 
> It's not defined by POSIX.  It's from 4.4BSD, and supported by glibc
> (and also by newlib and musl) -- but not by Windows.

Sorry - change that to "For people who only need to port their code to
systems where it's supported".

[toc] | [prev] | [next] | [standalone]

#162525

On 2021-08-30, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> [...]
>>                              For people who can count on POSIX support,
>> can you give any reason to avoid it?
> [...]
>
> It's not defined by POSIX.  It's from 4.4BSD, and supported by glibc
> (and also by newlib and musl) -- but not by Windows.

Unless your name is BartC, you must not say things such as: that a C library
function for string manipulation is or is not supported by Windows.

:)

You note that strsep is in Newlib. And that means it is in Cygwin.
So, that is on Windows.

  $ ./txr
  This is the TXR Lisp interactive listener of TXR 270.
  Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
  1> (uname)
  #S(utsname sysname "CYGWIN_NT-10.0-19042" nodename "BLACKBOX" release "3.1.7-340.x86_64"
             version "2020-08-22 17:48 UTC" machine "x86_64" domainname nil)
  2> (dlsym cptr-null "strsep")
  #<cptr dlsym: 180153480>

The Cygwin DLL makes a decent run-time library for Windows executables,
with lots of POSIX support as well as BSD functions like this, yet with access
to Windows API's too.

With the Cygnal fork of the cygwin1.dll, you can deploy Cygwin-compiled
executables such that they exhibit more native behaviors. (See signature).

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

[toc] | [prev] | [next] | [standalone]

#162530

Kaz Kylheku <563-365-8930@kylheku.com> writes:
> On 2021-08-30, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> [...]
>>>                              For people who can count on POSIX support,
>>> can you give any reason to avoid it?
>> [...]
>>
>> It's not defined by POSIX.  It's from 4.4BSD, and supported by glibc
>> (and also by newlib and musl) -- but not by Windows.
>
> Unless your name is BartC, you must not say things such as: that a C library
> function for string manipulation is or is not supported by Windows.
>
> :)
>
> You note that strsep is in Newlib. And that means it is in Cygwin.
> So, that is on Windows.

Right, it's not supported by Microsoft's library.  Sloppy of me.

>   $ ./txr
>   This is the TXR Lisp interactive listener of TXR 270.
>   Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
>   1> (uname)
>   #S(utsname sysname "CYGWIN_NT-10.0-19042" nodename "BLACKBOX" release "3.1.7-340.x86_64"
>              version "2020-08-22 17:48 UTC" machine "x86_64" domainname nil)
>   2> (dlsym cptr-null "strsep")
>   #<cptr dlsym: 180153480>
>
> The Cygwin DLL makes a decent run-time library for Windows executables,
> with lots of POSIX support as well as BSD functions like this, yet with access
> to Windows API's too.
>
> With the Cygnal fork of the cygwin1.dll, you can deploy Cygwin-compiled
> executables such that they exhibit more native behaviors. (See signature).

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#162500

On Mon, 30 Aug 2021 14:14:03 -0400, James Kuyper wrote:

> On 8/30/21 12:17 PM, Lew Pitcher wrote:
>> On Sun, 29 Aug 2021 19:04:18 +0000, Lew Pitcher wrote:
>> 
>>> FWIW
>>>
>>> On Sun, 29 Aug 2021 11:44:40 -0700, Barry Schwarz wrote:
> ...
>>>> strsep appears to be a function you wrote. 
>>>
>>> strsep() comes from the 4.4 BSD Unix standard C library extensions.
>>>
>>> [snip]
>> 
>> As for strsep(), my personal opinion is that the OP's program would be
>> better served if the OP had used the C standard function strtok().
> 
> I was never a strong fan of strtok(),
[snip]
> However, to suggest strtok() as a replacement seems masochistic.
> Would you care to expand on that comment?

From the original post, it appears that the OP is just learning C.
Certainly, the posted code contains no sophistication that you might
expect from an experienced C programmer. It lacks, for instance, the
simple error handling logic you would expect around malloc()'ed pointers,
and string-handling functions.

The code uses strsep() to break apart a simple string into two elements,
using fixed delimiters. While the strsep() function is well-defined by
POSIX, it is not defined as part of the C standard function library.
Pedants here have already noted that strsep() isn't part of C, and perhaps
should not be discussed here.

However, the C standard function library /does/ contain a function similar
to strsep(); one that performs essentially the same task, but with the
full support and topicality of the standard C language and library: strtok()

strtok(), for all it's flaws, would work /just as well/ in the OP's student
code, and would have made that part of the code less contentious to the
pedants in this forum.

In a prior post, I addressed the other, shall we say, "deviation" that the
OP's code had from standard C: the use of the POSIX strdup() function. The
OP can satisfy the pedants here by using a single, standard C compliant,
if() statement augmented by calls to two standard C functions.

All this to say that, while /I/ consider neither strdup() nor strsep() to be
off-topic here, I suggest strtok() as an alternative to strsep() to give
the OP some breathing-room from the pedants here that /do/ consider them
off-topic.

-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#162502

On 8/30/2021 9:16 PM, Lew Pitcher wrote:
> On Mon, 30 Aug 2021 14:14:03 -0400, James Kuyper wrote:
> 
>> On 8/30/21 12:17 PM, Lew Pitcher wrote:
>>> On Sun, 29 Aug 2021 19:04:18 +0000, Lew Pitcher wrote:
>>>
>>>> FWIW
>>>>
>>>> On Sun, 29 Aug 2021 11:44:40 -0700, Barry Schwarz wrote:
>> ...
>>>>> strsep appears to be a function you wrote.
>>>>
>>>> strsep() comes from the 4.4 BSD Unix standard C library extensions.
>>>>
>>>> [snip]
>>>
>>> As for strsep(), my personal opinion is that the OP's program would be
>>> better served if the OP had used the C standard function strtok().
>>
>> I was never a strong fan of strtok(),
> [snip]
>> However, to suggest strtok() as a replacement seems masochistic.
>> Would you care to expand on that comment?
> 
>  From the original post, it appears that the OP is just learning C.
> Certainly, the posted code contains no sophistication that you might
> expect from an experienced C programmer. It lacks, for instance, the
> simple error handling logic you would expect around malloc()'ed pointers,
> and string-handling functions.
> 
> The code uses strsep() to break apart a simple string into two elements,
> using fixed delimiters. While the strsep() function is well-defined by
> POSIX, it is not defined as part of the C standard function library.
> Pedants here have already noted that strsep() isn't part of C, and perhaps
> should not be discussed here.
> 
> However, the C standard function library /does/ contain a function similar
> to strsep(); one that performs essentially the same task, but with the
> full support and topicality of the standard C language and library: strtok()
> 
> strtok(), for all it's flaws, would work /just as well/ in the OP's student
> code, and would have made that part of the code less contentious to the
> pedants in this forum.

Since we are discussing alternatives to strsep, strtok, it might be 
worth mentioning:

strtok_r: does the right thing, but it's POSIX, not ISO C - included in 
glibc.

strtok_s: does also the right thing, arguably more clumsy, it is ISO C, 
_but_ as part of the controversial (and optional) Annex K - not included 
in glibc.

Note the /finesse/ in the postfixes...

> 
> In a prior post, I addressed the other, shall we say, "deviation" that the
> OP's code had from standard C: the use of the POSIX strdup() function. The
> OP can satisfy the pedants here by using a single, standard C compliant,
> if() statement augmented by calls to two standard C functions.
> 
> All this to say that, while /I/ consider neither strdup() nor strsep() to be
> off-topic here, I suggest strtok() as an alternative to strsep() to give
> the OP some breathing-room from the pedants here that /do/ consider them
> off-topic.
> 

Taking a deep breath...

[toc] | [prev] | [next] | [standalone]

#162501

On 8/30/2021 11:14 AM, James Kuyper wrote:
> On 8/30/21 12:17 PM, Lew Pitcher wrote:
>> On Sun, 29 Aug 2021 19:04:18 +0000, Lew Pitcher wrote:
>>
>>> FWIW
>>>
>>> On Sun, 29 Aug 2021 11:44:40 -0700, Barry Schwarz wrote:
> ...
>>>> strsep appears to be a function you wrote.
>>>
>>> strsep() comes from the 4.4 BSD Unix standard C library extensions.
>>>
>>> [snip]
>>
>> As for strsep(), my personal opinion is that the OP's program would be
>> better served if the OP had used the C standard function strtok().
> 
> I was never a strong fan of strtok(), but I lost all desire to use it
> after debugging a problem that occurred because one function used
> strtok() in a loop to parse one string, and inside that loop called a
> subroutine from a third-party library. When that subroutine was changed
> to use strtok() to parse a different string, the program failed
> catastrophically. If it takes you more than a few seconds to figure out
> why, that illustrates part of the problem.
> 
> When I want to do what strtok() does, but without such problems, I
> normally write C code to do it explicitly rather than calling as
> subroutine, it usually takes only a few lines of code. Therefore, I've
> no experience with strsep(). For people who can count on POSIX support,
> can you give any reason to avoid it? However, to suggest strtok() as a
> replacement seems masochistic. Would you care to expand on that comment?
> 

Implementing strtok without a static buffer might help. strtok_r?

https://linux.die.net/man/3/strtok_r

[toc] | [prev] | [next] | [standalone]

#162503

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>On 8/30/21 12:17 PM, Lew Pitcher wrote:

>When I want to do what strtok() does, but without such problems, I
>normally write C code to do it explicitly rather than calling as
>subroutine, it usually takes only a few lines of code. 

This.  One can generally parse most strings with a single pass
over the array of bytes (assuming LANG=C) just using C statements
without calling any of the str* functions.  Generally much more
efficient, particularly if strlen() is called one or more times
on segments of the string.

>Therefore, I've
>no experience with strsep(). For people who can count on POSIX support,
>can you give any reason to avoid it? However, to suggest strtok() as a
>replacement seems masochistic. Would you care to expand on that comment?

There's always strtok_r if using anything other than MSVC.

https://pubs.opengroup.org/onlinepubs/9699919799/functions/strtok_r.html

    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;
    }

[toc] | [prev] | [next] | [standalone]

#162879

scott@slp53.sl.home (Scott Lurndal) writes:

>     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;
>     }

int
parse_arguments_failed( char *command, char *line ){
    char *p = line;
    const int most = MAX_ARGCOUNT;
    argcount = 0;

    if(  ! cep->ce_splitargs  ){
        arglist[ argcount++ ] = command;
        arglist[ argcount++ ] = line;
        return  0;
    }

    while(   p = skip_over_spaces( p ),   *p  &&  argcount < most   ){
        if(  *p == '"'  )  p = skip_to_quote(  arglist[ argcount++ ] = p+1  );
        else               p = skip_to_space(  arglist[ argcount++ ] = p    );

        p =   *p  ? *p=0, p+1  : p;
    }

    if(  *p == 0  )  return  0;

    fprintf( stderr, "Error:  More than %d arguments unsupported\n", most );
    return  1;
}


The three helper functions skip_over_spaces(), skip_to_quote(),
and skip_to_space() are all very simple and can be written in
one or two lines each.

[toc] | [prev] | [next] | [standalone]

#162486

Barry Schwarz <schwarzb@delq.com> writes:
> On Sun, 29 Aug 2021 08:34:56 -0700 (PDT), Bithov Vinu Student
> <vinub@calday.co.uk> wrote:
[...]
>>deck_entry* parse_deck_entry(char* to_parse) {
>>	char* string_to_parse = strdup(to_parse);
>
> strdup is non-standard but common extension.  Most implementations use
> malloc to allocate memory, copy the data pointed to by to_parse into
> this allocated memory, and return the address of the allocated memory.
> Does yours do this also?

strdup is standardized by POSIX.  Yes, as far as the C standard is
concerned it's an extension, but it's unlikely that an implementation
would provide a function by that name that *doesn't* allocate memory
"as if by using malloc()".

It's also proposed for including in the next edition of the
C standard.  See the N2596 draft.

>>	char* a = strsep(&string_to_parse, ": ");
>
> strsep appears to be a function you wrote.  Was the standard strtok
> function not adequate for your needs?

It's unlikely that the OP wrote strsep.  It's not defined by C or
POSIX, but it was introduced in BSD and is provided by glibc (and
probably other library implementations).

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#162493

On 8/30/2021 12:38 AM, Keith Thompson wrote:
> Barry Schwarz <schwarzb@delq.com> writes:
>> On Sun, 29 Aug 2021 08:34:56 -0700 (PDT), Bithov Vinu Student
>> <vinub@calday.co.uk> wrote:
> [...]
>>> deck_entry* parse_deck_entry(char* to_parse) {
>>> 	char* string_to_parse = strdup(to_parse);
>>
>> strdup is non-standard but common extension.  Most implementations use
>> malloc to allocate memory, copy the data pointed to by to_parse into
>> this allocated memory, and return the address of the allocated memory.
>> Does yours do this also?
> 
> strdup is standardized by POSIX.  Yes, as far as the C standard is
> concerned it's an extension, but it's unlikely that an implementation
> would provide a function by that name that *doesn't* allocate memory
> "as if by using malloc()".

And, in any case, "man strdup" would clarify this point. Documentation 
is written for a purpose.

> 
> It's also proposed for including in the next edition of the
> C standard.  See the N2596 draft.
> 
>>> 	char* a = strsep(&string_to_parse, ": ");
>>
>> strsep appears to be a function you wrote.  Was the standard strtok
>> function not adequate for your needs?
> 
> It's unlikely that the OP wrote strsep.  It's not defined by C or
> POSIX, but it was introduced in BSD and is provided by glibc (and
> probably other library implementations).
> 
> [...]
> 

[toc] | [prev] | [next] | [standalone]

#162496

And that's all because C has no proper string-handling ... ;-)

[toc] | [prev] | [next] | [standalone]

#162497

On 30/08/2021 17:29, Bonita Montero wrote:
> And that's all because C has no proper string-handling ... ;-)

That wasn't the issue in the original code. (Actually the OP's code 
looked simpler than your C++ code.)

You can make an argument that it needs manual memory management, but an 
easy fix is to just comment out all free() calls. This will work for 
many programs; it might work here.

Another is to bolt-on a garbage collector.

Switching languages (which in the case of C++ makes everything else 100 
times more difficult in return for having string objects) would be a 
last resort.

If it has to be done, then you might as well try for a language which 
really does make life easier, rather than harder, overall.

[toc] | [prev] | [next] | [standalone]

#162504

Am 30.08.2021 um 19:30 schrieb Bart:
> On 30/08/2021 17:29, Bonita Montero wrote:
>> And that's all because C has no proper string-handling ... ;-)
> 
> That wasn't the issue in the original code. (Actually the OP's code 
> looked simpler than your C++ code.)

No, if you include full error handling if allocations fail as well
full resource-handling, i.e. deallocations, the code looks much ^ 3
worse.


> 
> You can make an argument that it needs manual memory management, but an 
> easy fix is to just comment out all free() calls. This will work for 
> many programs; it might work here.
> 
> Another is to bolt-on a garbage collector.
> 
> Switching languages (which in the case of C++ makes everything else 100 
> times more difficult in return for having string objects) would be a 
> last resort.
> 
> If it has to be done, then you might as well try for a language which 
> really does make life easier, rather than harder, overall.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web