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

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

Correct way of doing string manipulation functions

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

Contents

  Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-10 15:43 -0800
    Re: Correct way of doing string manipulation functions "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-10 19:36 -0500
      Re: Correct way of doing string manipulation functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-11 03:41 +0000
        Re: Correct way of doing string manipulation functions James Kuyper <jameskuyper@verizon.net> - 2017-01-11 07:19 -0500
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:36 -0800
    Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-10 16:41 -0800
      Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-10 16:54 -0800
        Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:38 -0800
          Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-11 18:24 -0800
      Re: Correct way of doing string manipulation functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-11 03:38 +0000
        Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-10 20:02 -0800
          Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-10 20:28 -0800
          Re: Correct way of doing string manipulation functions Ian Collins <ian-news@hotmail.com> - 2017-01-11 18:19 +1300
            Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-11 02:40 -0800
        Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-10 20:18 -0800
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:37 -0800
        Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-11 18:23 -0800
    Re: Correct way of doing string manipulation functions BartC <bc@freeuk.com> - 2017-01-11 01:12 +0000
      Re: Correct way of doing string manipulation functions BartC <bc@freeuk.com> - 2017-01-11 11:59 +0000
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:39 -0800
    Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-10 17:55 -0800
      Re: Correct way of doing string manipulation functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-10 18:21 -0800
      Re: Correct way of doing string manipulation functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-11 03:21 +0000
        Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-11 07:33 -0800
          Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-11 07:43 -0800
          Re: Correct way of doing string manipulation functions BartC <bc@freeuk.com> - 2017-01-11 15:50 +0000
            Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-11 08:07 -0800
              Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:46 -0800
                Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-12 03:04 -0800
                  Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-12 03:37 -0800
                    Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-12 05:47 -0800
                      Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-12 06:14 -0800
                        Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-12 06:34 -0800
                        Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 07:38 -0800
                          Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-12 07:59 -0800
              Re: Correct way of doing string manipulation functions Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 22:24 -0800
                Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-15 03:30 -0800
                  Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-15 03:52 -0800
                    Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-15 04:23 -0800
        Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:42 -0800
    Re: Correct way of doing string manipulation functions Keith Thompson <kst-u@mib.org> - 2017-01-10 19:19 -0800
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:40 -0800
    Re: Correct way of doing string manipulation functions Barry Schwarz <schwarzb@dqel.com> - 2017-01-10 20:31 -0800
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:45 -0800
    Re: Correct way of doing string manipulation functions Gareth Owen <gwowen@gmail.com> - 2017-01-11 17:20 +0000
      Re: Correct way of doing string manipulation functions "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-11 12:38 -0500
        Strings as first class citizens (Was: Correct way of doing string manipulation functions) gazelle@shell.xmission.com (Kenny McCormack) - 2017-01-11 17:53 +0000
          Re: Strings as first class citizens (Was: Correct way of doing string manipulation functions) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-11 12:46 -0800
            Re: Strings as first class citizens (Was: Correct way of doing string manipulation functions) fir <profesor.fir@gmail.com> - 2017-01-11 14:40 -0800
            Re: Strings as first class citizens (Was: Correct way of doing string manipulation functions) Robert Wessel <robertwessel2@yahoo.com> - 2017-01-11 18:12 -0600
        Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-11 09:56 -0800
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 14:48 -0800
    Re: Correct way of doing string manipulation functions Thiago Adams <thiago.adams@gmail.com> - 2017-01-11 12:09 -0800
      Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 15:00 -0800
    Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-11 15:11 -0800
      Re: Correct way of doing string manipulation functions "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-11 19:03 -0500
        Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 02:46 -0800
      Re: Correct way of doing string manipulation functions Barry Schwarz <schwarzb@dqel.com> - 2017-01-12 00:08 -0800
        Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 03:02 -0800
          Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 11:38 +0000
            Re: Correct way of doing string manipulation functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-12 13:51 +0000
              Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 14:41 +0000
          Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 09:32 -0800
            Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 18:15 +0000
            Re: Correct way of doing string manipulation functions Keith Thompson <kst-u@mib.org> - 2017-01-12 11:46 -0800
              Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 13:52 -0800
            Re: Correct way of doing string manipulation functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-12 16:50 -0800
              Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 00:59 +0000
                Re: Correct way of doing string manipulation functions raltbos@xs4all.nl (Richard Bos) - 2017-01-13 08:59 +0000
                  Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 13:07 +0000
                  Re: Correct way of doing string manipulation functions Keith Thompson <kst-u@mib.org> - 2017-01-13 10:11 -0800
                    Re: Correct way of doing string manipulation functions BartC <bc@freeuk.com> - 2017-01-13 18:49 +0000
                Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 08:43 -0800
                Re: Correct way of doing string manipulation functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 09:45 -0800
                  Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 18:17 +0000
                    Re: Correct way of doing string manipulation functions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-13 10:30 -0800
                      Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 18:48 +0000
                        Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 11:02 -0800
                          Re: Correct way of doing string manipulation functions Richard Heathfield <rjh@cpax.org.uk> - 2017-01-13 19:15 +0000
                            Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 12:18 -0800
                      Re: Correct way of doing string manipulation functions Keith Thompson <kst-u@mib.org> - 2017-01-13 12:14 -0800
                        Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 12:49 -0800
                          Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 13:19 -0800
                    Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 10:46 -0800
                      Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 11:55 -0800
                  Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 10:41 -0800
                    Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 10:51 -0800
                    Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 12:28 -0800
                      Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 13:07 -0800
                        Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 13:29 -0800
                          Re: Correct way of doing string manipulation functions BartC <bc@freeuk.com> - 2017-01-13 21:45 +0000
                            Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 13:59 -0800
                              Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 15:08 -0800
                            Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-13 14:13 -0800
                          Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 13:47 -0800
              Re: Correct way of doing string manipulation functions fir <profesor.fir@gmail.com> - 2017-01-13 08:02 -0800
        Re: Correct way of doing string manipulation functions supercat@casperkitty.com - 2017-01-12 07:50 -0800
        Re: Correct way of doing string manipulation functions Keith Thompson <kst-u@mib.org> - 2017-01-12 08:37 -0800
          Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-12 09:41 -0800
      Re: Correct way of doing string manipulation functions Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 17:39 -0800
        Re: Correct way of doing string manipulation functions "Fernando D. Bozzo" <fdbozzo@gmail.com> - 2017-01-13 18:02 -0800

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#101407 — Correct way of doing string manipulation functions

Hi all,

I'm starting at C but have a background on programmming in OOP.

My question is about string manipulation functions and the correct/best/good way of doing this in C.

I've made a function that returns just the filename of a given full path or url, which I use this way:


// Suppose argv[1] is "http://www.myserver.com/file.html"
char *text_out = justfname(argv[1]);
printf("justfname = [%s]\n", text_out);
free(text_out);



/**
 * Returns the filename without path
 * 
 * Examples:
 *      justfname("c:\aaa\bbb\ccc\ddd.txt")             =>  "ddd.txt"
 *      justfname("http://www.myserver.com/file.html")  =>  "file.html"
 */
char *justfname(char *text_in)
{
    int len = strlen(text_in);
    char *fname = NULL;
    char *text_out = malloc(sizeof(text_in));
    fname = strrchr(text_in, '/');
    if (fname == NULL)
    {
        fname = strrchr(text_in, '\\');
        if (fname == NULL)
        {
            fname = text_in;
        }
        else
        {
            fname++; // Advance address +1 (skip "\" char)
        }
    }
    else
    {
        fname++; // Advance address +1 (skip "/" char)
    }

    // Copy obtained data
    strncpy(text_out, fname, len);

    return text_out;
}



So my questions are:
1) Is this implementation ok/correct, or is there a better way of doing it?
2) Is usually the caller who is responsible for freeing the used pointers on the called functions?
3) When using pointers, are they normally created with malloc (heap) in habitual programming, or automatic var pointers (stack) are habitual too?

Thanks!

[toc] | [next] | [standalone]

#101410

On 01/10/2017 06:43 PM, Fernando D. Bozzo wrote:
> Hi all,
>
> I'm starting at C but have a background on programmming in OOP.
>
> My question is about string manipulation functions and the correct/best/good way of doing this in C.
>
> I've made a function that returns just the filename of a given full path or url, which I use this way:
>
>
> // Suppose argv[1] is "http://www.myserver.com/file.html"
> char *text_out = justfname(argv[1]);
> printf("justfname = [%s]\n", text_out);
> free(text_out);
>
>
>
> /**
>  * Returns the filename without path
>  *
>  * Examples:
>  *      justfname("c:\aaa\bbb\ccc\ddd.txt")             =>  "ddd.txt"
>  *      justfname("http://www.myserver.com/file.html")  =>  "file.html"
>  */
> char *justfname(char *text_in)
> {
>     int len = strlen(text_in);

strlen() returns a count that does NOT include the terminating null 
character. The C standard defines a string as including the terminating 
null character, and lots of C standard library routines require strings 
as inputs.

>     char *fname = NULL;
>     char *text_out = malloc(sizeof(text_in));

You allocated only enough space for the contents of the input string, 
without enough room to null-terminate it. That's fine if the output is 
guaranteed to be shorter than the input. However, what should 
justfname("file.html") do?

malloc() can fail. If it does, text_out will be null. If it is, the call 
to strncpy() below has undefined behavior.
What should justfname() do if it malloc() fails? If the answer doesn't 
include "send threatening messages to Donald Trump", I'd recommend 
checking for whether or not malloc() failed, and taking appropriate 
action. What constitutes "appropriate" is up to you to decide - but I 
would not recommend including "undefined behavior" in that category.

>     fname = strrchr(text_in, '/');
>     if (fname == NULL)
>     {
>         fname = strrchr(text_in, '\\');
>         if (fname == NULL)
>         {
>             fname = text_in;
>         }
>         else
>         {
>             fname++; // Advance address +1 (skip "\" char)
>         }
>     }
>     else
>     {
>         fname++; // Advance address +1 (skip "/" char)
>     }

I recommend delaying the memory allocation until this point. You can 
calculate the length of the filename part (including the terminating 
null character!) and allocate only that much space for text_out.

>     // Copy obtained data
>     strncpy(text_out, fname, len);
>
>     return text_out;
> }
>
>
>
> So my questions are:
> 1) Is this implementation ok/correct, or is there a better way of doing it?

I've identified a couple of points on which it's incorrect. Reducing the 
amount of memory allocated isn't needed for correctness, but is 
"better", in my opinion.

> 2) Is usually the caller who is responsible for freeing the used pointers on the called functions?

I've seen four common patterns:
1) The pointer that is returned points at a static array that belongs to 
the function, and may get overwritten by a subsequent call to the 
function. This is what the Unix basename() function does, which is 
otherwise equivalent to your function.
2) The caller is responsible for free()ing the dynamically allocated string.
3) The caller is responsible for setting aside memory for the function 
to write the output string to. How that memory is disposed of after use 
is entirely up to the caller, depending upon how it was allocated.
4) A garbage collector is responsible for free()ing the string. This 
cannot be done in strictly conforming C, but there are C-compatible 
garbage collectors available.

I personally prefer option 3, as it's more flexible - the memory can be 
allocated statically, automatically, or dynamically. There's a 
corresponding disadvantage - the calling function needs to decide how 
much memory to set aside, something that is more conveniently done by 
justfname() itself.

> 3) When using pointers, are they normally created with malloc (heap) in habitual programming, or automatic var pointers (stack) are habitual too?

A pointer to an automatically allocated array becomes indeterminate if 
the lifetime of that array ends, which normally occurs at the end of the 
block in which it is defined. Such pointers can be safely passed to 
subroutines called within that block, but should not be passed outside 
of that block (in particular, they should not be returned to the calling 
routine.

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

#101424

"James R. Kuyper" <jameskuyper@verizon.net> writes:

> On 01/10/2017 06:43 PM, Fernando D. Bozzo wrote:
<snip>
>> char *justfname(char *text_in)
>> {
<snip>
>>     char *text_out = malloc(sizeof(text_in));
>
> You allocated only enough space for the contents of the input string,
> without enough room to null-terminate it.

It's worse than that.  I think you misread sizeof as strlen.  Only
enough space for a pointer is allocated.

<snip>
-- 
Ben.

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

#101434

On 01/10/2017 10:41 PM, Ben Bacarisse wrote:
> "James R. Kuyper" <jameskuyper@verizon.net> writes:
> 
>> On 01/10/2017 06:43 PM, Fernando D. Bozzo wrote:
> <snip>
>>> char *justfname(char *text_in)
>>> {
> <snip>
>>>     char *text_out = malloc(sizeof(text_in));
>>
>> You allocated only enough space for the contents of the input string,
>> without enough room to null-terminate it.
> 
> It's worse than that.  I think you misread sizeof as strlen.  Only
> enough space for a pointer is allocated.

Yes, I did. Which should have caught my attention, because he'd already
stored the value of strlen(text_in) in the variable len, so there would
have been no point in calling it again.

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

#101474

Hi James:


El miércoles, 11 de enero de 2017, 1:36:24 (UTC+1), James R. Kuyper  escribió:
> On 01/10/2017 06:43 PM, Fernando D. Bozzo wrote:
> > Hi all,
> >
> > I'm starting at C but have a background on programmming in OOP.
> >
> > My question is about string manipulation functions and the correct/best/good way of doing this in C.
> >
> > I've made a function that returns just the filename of a given full path or url, which I use this way:
> >
> >
> > // Suppose argv[1] is "http://www.myserver.com/file.html"
> > char *text_out = justfname(argv[1]);
> > printf("justfname = [%s]\n", text_out);
> > free(text_out);
> >
> >
> >
> > /**
> >  * Returns the filename without path
> >  *
> >  * Examples:
> >  *      justfname("c:\aaa\bbb\ccc\ddd.txt")             =>  "ddd.txt"
> >  *      justfname("http://www.myserver.com/file.html")  =>  "file.html"
> >  */
> > char *justfname(char *text_in)
> > {
> >     int len = strlen(text_in);
> 
> strlen() returns a count that does NOT include the terminating null 
> character. The C standard defines a string as including the terminating 
> null character, and lots of C standard library routines require strings 
> as inputs.

Yes! I did forget about the terminating null char. Fixed now.


> 
> >     char *fname = NULL;
> >     char *text_out = malloc(sizeof(text_in));
> 
> You allocated only enough space for the contents of the input string, 
> without enough room to null-terminate it. That's fine if the output is 
> guaranteed to be shorter than the input.

Another C-newbie error. I did think that sizeof() could get the "real" size of the string, which strlen() does not, but doing some tests with fprint did make clear that this only get the size of the pointer, nothing else.


> However, what should justfname("file.html") do?

Should return the same as the input, because it's a file name without path


> 
> malloc() can fail. If it does, text_out will be null. If it is, the call 
> to strncpy() below has undefined behavior.
> What should justfname() do if it malloc() fails? If the answer doesn't 
> include "send threatening messages to Donald Trump", I'd recommend 
> checking for whether or not malloc() failed, and taking appropriate 
> action. What constitutes "appropriate" is up to you to decide - but I 
> would not recommend including "undefined behavior" in that category.

You are right. I did forgot --once again-- that the function malloc() returns null if can't reserve the solicited memory :-(


> 
> >     fname = strrchr(text_in, '/');
> >     if (fname == NULL)
> >     {
> >         fname = strrchr(text_in, '\\');
> >         if (fname == NULL)
> >         {
> >             fname = text_in;
> >         }
> >         else
> >         {
> >             fname++; // Advance address +1 (skip "\" char)
> >         }
> >     }
> >     else
> >     {
> >         fname++; // Advance address +1 (skip "/" char)
> >     }
> 
> I recommend delaying the memory allocation until this point. You can 
> calculate the length of the filename part (including the terminating 
> null character!) and allocate only that much space for text_out.

Thanks! I will do that.


> 
> >     // Copy obtained data
> >     strncpy(text_out, fname, len);
> >
> >     return text_out;
> > }
> >
> >
> >
> > So my questions are:
> > 1) Is this implementation ok/correct, or is there a better way of doing it?
> 
> I've identified a couple of points on which it's incorrect. Reducing the 
> amount of memory allocated isn't needed for correctness, but is 
> "better", in my opinion.
> 
> > 2) Is usually the caller who is responsible for freeing the used pointers on the called functions?
> 
> I've seen four common patterns:
> 1) The pointer that is returned points at a static array that belongs to 
> the function, and may get overwritten by a subsequent call to the 
> function. This is what the Unix basename() function does, which is 
> otherwise equivalent to your function.
> 2) The caller is responsible for free()ing the dynamically allocated string.
> 3) The caller is responsible for setting aside memory for the function 
> to write the output string to. How that memory is disposed of after use 
> is entirely up to the caller, depending upon how it was allocated.
> 4) A garbage collector is responsible for free()ing the string. This 
> cannot be done in strictly conforming C, but there are C-compatible 
> garbage collectors available.
> 
> I personally prefer option 3, as it's more flexible - the memory can be 
> allocated statically, automatically, or dynamically. There's a 
> corresponding disadvantage - the calling function needs to decide how 
> much memory to set aside, something that is more conveniently done by 
> justfname() itself.
> 
> > 3) When using pointers, are they normally created with malloc (heap) in habitual programming, or automatic var pointers (stack) are habitual too?
> 
> A pointer to an automatically allocated array becomes indeterminate if 
> the lifetime of that array ends, which normally occurs at the end of the 
> block in which it is defined. Such pointers can be safely passed to 
> subroutines called within that block, but should not be passed outside 
> of that block (in particular, they should not be returned to the calling 
> routine.

Thanks for the tips!

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

#101411

Here is a working implementation:

    https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/commands/functions/j.cpp

Best regards,
Rick C. Hodgin

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

#101412

On Tuesday, January 10, 2017 at 7:41:42 PM UTC-5, Rick C. Hodgin wrote:
> Here is a working implementation:
> 
>     https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/commands/functions/j.cpp

Here also are some videos I made for VFP developers coming to C.  It's
in English:

    http://www.visual-freepro.org/videos/2013_08_22__introduction_to_c_from_foxpro_dev_perspective.ogv
    http://www.visual-freepro.org/videos/2013_08_24__intro2c_from_vfp_semicolon_comments_equal_flow.ogv
    http://www.visual-freepro.org/videos/2013_08_24__intro2c_from_vfp_hexadecimal_numbers.ogv

If you'd like to help me with Visual FreePro, Jr., I will teach you all
the C you'd ever like to learn.  And you can come here and validate the
things I teach you, and get correction where I lead you away from the C
Standard.

Best regards,
Rick C. Hodgin

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

#101477

Thanks for the offer Rick, but right now I'm in the middle of a Mooc course in C, so no time for now, but I will take it into account! :)


El miércoles, 11 de enero de 2017, 1:54:17 (UTC+1), Rick C. Hodgin  escribió:
> On Tuesday, January 10, 2017 at 7:41:42 PM UTC-5, Rick C. Hodgin wrote:
> > Here is a working implementation:
> > 
> >     https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/commands/functions/j.cpp
> 
> Here also are some videos I made for VFP developers coming to C.  It's
> in English:
> 
>     http://www.visual-freepro.org/videos/2013_08_22__introduction_to_c_from_foxpro_dev_perspective.ogv
>     http://www.visual-freepro.org/videos/2013_08_24__intro2c_from_vfp_semicolon_comments_equal_flow.ogv
>     http://www.visual-freepro.org/videos/2013_08_24__intro2c_from_vfp_hexadecimal_numbers.ogv
> 
> If you'd like to help me with Visual FreePro, Jr., I will teach you all
> the C you'd ever like to learn.  And you can come here and validate the
> things I teach you, and get correction where I lead you away from the C
> Standard.
> 
> Best regards,
> Rick C. Hodgin

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

#101496

On Wednesday, January 11, 2017 at 5:39:02 PM UTC-5, Fernando D. Bozzo wrote:
> Thanks for the offer Rick, but right now I'm in the middle of a Mooc
> course in C, so no time for now, but I will take it into account! :)

When you complete the course, look me up.  You have the VFP expertise
I need for my VFrP and VJr projects.  And soon you'll have the C
expertise as well.

> El miércoles, 11 de enero de 2017, 1:54:17 (UTC+1), Rick C. Hodgin  escribió:
> > On Tuesday, January 10, 2017 at 7:41:42 PM UTC-5, Rick C. Hodgin wrote:
> > > Here is a working implementation:
> > > 
> > >     https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/commands/functions/j.cpp
> > 
> > Here also are some videos I made for VFP developers coming to C.  It's
> > in English:
> > 
> >     http://www.visual-freepro.org/videos/2013_08_22__introduction_to_c_from_foxpro_dev_perspective.ogv
> >     http://www.visual-freepro.org/videos/2013_08_24__intro2c_from_vfp_semicolon_comments_equal_flow.ogv
> >     http://www.visual-freepro.org/videos/2013_08_24__intro2c_from_vfp_hexadecimal_numbers.ogv
> > 
> > If you'd like to help me with Visual FreePro, Jr., I will teach you all
> > the C you'd ever like to learn.  And you can come here and validate the
> > things I teach you, and get correction where I lead you away from the C
> > Standard.

Best regards,
Rick C. Hodgin

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

#101423

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> Here is a working implementation:
>
>     https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/commands/functions/j.cpp

Does it return the correct results for "\\abc" and "c:abc"?  I don't
know enough about Windows paths to be sure, but I'd expect "abc" in both
cases.  (BTW you've copied a comment from another function so it makes
no sense in this one.)

-- 
Ben.

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

#101425

On Tuesday, January 10, 2017 at 10:38:28 PM UTC-5, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > Here is a working implementation:
> >
> >     https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/commands/functions/j.cpp
> 
> Does it return the correct results for "\\abc" and "c:abc"?  I don't
> know enough about Windows paths to be sure, but I'd expect "abc" in both
> cases.  (BTW you've copied a comment from another function so it makes
> no sense in this one.)

It may not return correct results for all cases it was designed for
(standard Windows non-UNC file paths, like "c:\path\to\myfile.txt").

You can test it here in Windows:

    Downoad vjr_0.58.zip:
    http://www.visual-freepro.org/vjr/indexmain.html

    Launch:
    vjr_32bit__msvc.bat

    At the command prompt, type:
    k = "c:\path\to\myfile.txt"
    ? justfdrive(k)
    ? justfext(k)
    ? justfname(k)
    ? justfpath(k)
    ? justfstem(k)

Other functions to test are here:

    Supported Functions
    http://www.visual-freepro.org/wiki/index.php/VXB

It has not undergone extensive testing.  It's undergone preliminary
testing mostly by myself and two other developers.

Best regards,
Rick C. Hodgin

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

#101427

On Tuesday, January 10, 2017 at 11:03:04 PM UTC-5, Rick C. Hodgin wrote:
> It may not return correct results for all cases it was designed for
> (standard Windows non-UNC file paths, like "c:\path\to\myfile.txt").
> 
> You can test it here in Windows:
> 
>     Downoad vjr_0.58.zip:
>     http://www.visual-freepro.org/vjr/indexmain.html
> 
>     Launch:
>     vjr_32bit__msvc.bat
> 
>     At the command prompt, type:
>     k = "c:\path\to\myfile.txt"
>     ? justfdrive(k)
>     ? justfext(k)
>     ? justfname(k)
>     ? justfpath(k)
>     ? justfstem(k)
> 
> Other functions to test are here:
> 
>     Supported Functions
>     http://www.visual-freepro.org/wiki/index.php/VXB
> 
> It has not undergone extensive testing.  It's undergone preliminary
> testing mostly by myself and two other developers.

Corrected names:

    At the command prompt, type:
    k = "c:\path\to\myfile.txt"
    ? justdrive(k)
    ? justext(k)
    ? justfname(k)
    ? justpath(k)
    ? juststem(k)

Best regards,
Rick C. Hodgin

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

#101431

On 01/11/17 05:02 PM, Rick C. Hodgin wrote:
> On Tuesday, January 10, 2017 at 10:38:28 PM UTC-5, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>
>>> Here is a working implementation:
>>>
>>>      https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/commands/functions/j.cpp
>>
>> Does it return the correct results for "\\abc" and "c:abc"?  I don't
>> know enough about Windows paths to be sure, but I'd expect "abc" in both
>> cases.  (BTW you've copied a comment from another function so it makes
>> no sense in this one.)
>
> It may not return correct results for all cases it was designed for
> (standard Windows non-UNC file paths, like "c:\path\to\myfile.txt").

If you had unit tests, you would know for sure!

-- 
Ian

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

#101432

Ian Collins wrote:
> Rick C. Hodgin wrote:
> > It may not return correct results for all cases it was designed for
> > (standard Windows non-UNC file paths, like "c:\path\to\myfile.txt").
>
> If you had unit tests, you would know for sure!

Come on board and help write them.

Best regards,
Rick C. Hodgin

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

#101426

On Tuesday, January 10, 2017 at 10:38:28 PM UTC-5, Ben Bacarisse wrote:
> (BTW you've copied a comment from another function so it makes
> no sense in this one.)

This is why I would like for you to come on board and work on the
project.  You once looked at some of my code and found a half dozen
things that were questionable or broken in it.

Your skills are immense, and they're desirable for my project.  I've
actually had thoughts before when writing code that I wish I had you
(yes, literally you) to help guide me into more proper methods of
writing code.  As it is, I'm winging it. :-)

Best regards,
Rick C. Hodgin

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

#101475

Hi Rick! Nice to see you :)

I did take a look at your code, but you are using C++, not C, which have many differences.
In this case, it confuses me that all your just* functions are void! so they not return a string (or I don't see how they do the same as VFP)



El miércoles, 11 de enero de 2017, 1:41:42 (UTC+1), Rick C. Hodgin  escribió:
> Here is a working implementation:
> 
>     https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/commands/functions/j.cpp
> 
> Best regards,
> Rick C. Hodgin

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

#101495

On Wednesday, January 11, 2017 at 5:37:48 PM UTC-5, Fernando D. Bozzo wrote:
> Hi Rick! Nice to see you :)
> 
> I did take a look at your code, but you are using C++, not C, which
> have many differences.

I use a C++ compiler, but I program nearly 100% in C.  I use the
C++ compiler because it handles some syntax a little more easily,
and increases the requirements of type checking.

> In this case, it confuses me that all your just* functions are void!
> so they not return a string

I pass in a structure (like a table record or object), and then
I populate items in that structure which represent the input and
output parameters.

VFP allows up to 26 input parameters, and 1 return parameter.  I
have extended Visual FreePro and Visual FreePro, Jr. to allow up
to 26 input parameters, and 10 return parameters.

It becomes complex and cluttered to send that many parameters
around.  So, by using the struct features of C, I am able to only
send one parameter and then update the data items within.

> (or I don't see how they do the same as VFP)

By using the structure, the data can be passed in to called
functions, return back out, release non-by-reference parameters,
shuffle the return parameters into the input positions for the
next nested function call, and so on.

> El miércoles, 11 de enero de 2017, 1:41:42 (UTC+1), Rick C. Hodgin  escribió:
> > Here is a working implementation:
> >     https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/commands/functions/j.cpp

Best regards,
Rick C. Hodgin

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

#101415

On 10/01/2017 23:43, Fernando D. Bozzo wrote:
> Hi all,
>
> I'm starting at C but have a background on programmming in OOP.
>
> My question is about string manipulation functions and the correct/best/good way of doing this in C.
>
> I've made a function that returns just the filename of a given full path or url, which I use this way:
>
>
> // Suppose argv[1] is "http://www.myserver.com/file.html"
> char *text_out = justfname(argv[1]);
> printf("justfname = [%s]\n", text_out);
> free(text_out);
>
>
>
> /**
>  * Returns the filename without path
>  *
>  * Examples:
>  *      justfname("c:\aaa\bbb\ccc\ddd.txt")             =>  "ddd.txt"
>  *      justfname("http://www.myserver.com/file.html")  =>  "file.html"
>  */
> char *justfname(char *text_in)
> {
>     int len = strlen(text_in);
>     char *fname = NULL;
>     char *text_out = malloc(sizeof(text_in));
>     fname = strrchr(text_in, '/');
>     if (fname == NULL)
>     {
>         fname = strrchr(text_in, '\\');
>         if (fname == NULL)
>         {
>             fname = text_in;
>         }
>         else
>         {
>             fname++; // Advance address +1 (skip "\" char)
>         }
>     }
>     else
>     {
>         fname++; // Advance address +1 (skip "/" char)
>     }
>
>     // Copy obtained data
>     strncpy(text_out, fname, len);
>
>     return text_out;
> }
>
>
>
> So my questions are:
> 1) Is this implementation ok/correct, or is there a better way of doing it?

Some examples may not give the proper filename:

  justfname("C:file.ext");         // drive/no path, includes drive
  justfname("C:/path\\file.ext");  // uses both / and \
  justfname("ab");                 // returns ab? (random letter added)

Actually a lot of examples return garbage at the end; probably you 
forgot to add a zero terminator to the string.

(The way I'd do this is start at the end and work left, looking for the 
first /, \ or :)

-- 
Bartc

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

#101433

On 11/01/2017 01:12, BartC wrote:

> (The way I'd do this is start at the end and work left, looking for the
> first /, \ or :)

That last bit seems to have come out as a smiley. It should read:

   ... looking for the first /, \ or :


-- 
Bartc

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

#101478

Hi Bart:

Yes, I did not tested for some special cases, but I refactored my code and I think it's ok now.

Thanks for the tips, I'm looking at them


El miércoles, 11 de enero de 2017, 2:12:40 (UTC+1), Bart  escribió:
> On 10/01/2017 23:43, Fernando D. Bozzo wrote:
> > Hi all,
> >
> > I'm starting at C but have a background on programmming in OOP.
> >
> > My question is about string manipulation functions and the correct/best/good way of doing this in C.
> >
> > I've made a function that returns just the filename of a given full path or url, which I use this way:
> >
> >
> > // Suppose argv[1] is "http://www.myserver.com/file.html"
> > char *text_out = justfname(argv[1]);
> > printf("justfname = [%s]\n", text_out);
> > free(text_out);
> >
> >
> >
> > /**
> >  * Returns the filename without path
> >  *
> >  * Examples:
> >  *      justfname("c:\aaa\bbb\ccc\ddd.txt")             =>  "ddd.txt"
> >  *      justfname("http://www.myserver.com/file.html")  =>  "file.html"
> >  */
> > char *justfname(char *text_in)
> > {
> >     int len = strlen(text_in);
> >     char *fname = NULL;
> >     char *text_out = malloc(sizeof(text_in));
> >     fname = strrchr(text_in, '/');
> >     if (fname == NULL)
> >     {
> >         fname = strrchr(text_in, '\\');
> >         if (fname == NULL)
> >         {
> >             fname = text_in;
> >         }
> >         else
> >         {
> >             fname++; // Advance address +1 (skip "\" char)
> >         }
> >     }
> >     else
> >     {
> >         fname++; // Advance address +1 (skip "/" char)
> >     }
> >
> >     // Copy obtained data
> >     strncpy(text_out, fname, len);
> >
> >     return text_out;
> > }
> >
> >
> >
> > So my questions are:
> > 1) Is this implementation ok/correct, or is there a better way of doing it?
> 
> Some examples may not give the proper filename:
> 
>   justfname("C:file.ext");         // drive/no path, includes drive
>   justfname("C:/path\\file.ext");  // uses both / and \
>   justfname("ab");                 // returns ab? (random letter added)
> 
> Actually a lot of examples return garbage at the end; probably you 
> forgot to add a zero terminator to the string.
> 
> (The way I'd do this is start at the end and work left, looking for the 
> first /, \ or :)
> 
> -- 
> Bartc

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

Page 1 of 6  [1] 2 3 4 5 6  Next page →

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

csiph-web