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

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

Return value for strcat and similar functions

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

Contents

  Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-06 10:02 +0200
    Re: Return value for strcat and similar functions Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2015-05-06 10:34 +0200
    Re: Return value for strcat and similar functions Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-05-06 16:51 +0200
    Re: Return value for strcat and similar functions Keith Thompson <kst-u@mib.org> - 2015-05-06 08:58 -0700
      Re: Return value for strcat and similar functions Richard Heathfield <rjh@cpax.org.uk> - 2015-05-06 17:07 +0100
        Re: Return value for strcat and similar functions Morris Dovey <mrdovey@iedu.com> - 2015-05-06 12:01 -0500
      Re: Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-07 10:19 +0200
        Re: Return value for strcat and similar functions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-07 13:21 +0000
          Re: Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-07 16:24 +0200
            Re: Return value for strcat and similar functions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-07 18:02 +0000
        Re: Return value for strcat and similar functions Morris Dovey <mrdovey@iedu.com> - 2015-05-07 10:17 -0500
          Re: Return value for strcat and similar functions Morris Dovey <mrdovey@iedu.com> - 2015-05-07 10:56 -0500
            Re: Return value for strcat and similar functions asetofsymbols@gmail.com - 2015-05-07 11:00 -0700
              Re: Return value for strcat and similar functions Morris Dovey <mrdovey@iedu.com> - 2015-05-07 14:28 -0500
                Re: Return value for strcat and similar functions asetofsymbols@gmail.com - 2015-05-07 12:47 -0700
            Re: Return value for strcat and similar functions Nathan Wagner <nw@hydaspes.if.org> - 2015-05-08 09:31 +0000
          Re: Return value for strcat and similar functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 15:55 -0700
          Re: Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-08 11:03 +0200
            Re: Return value for strcat and similar functions Morris Dovey <mrdovey@iedu.com> - 2015-05-08 05:07 -0500
    Re: Return value for strcat and similar functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-06 18:25 -0700
      Re: Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-07 10:22 +0200
        Re: Return value for strcat and similar functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 15:39 -0700
          Re: Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-08 11:09 +0200
            Re: Return value for strcat and similar functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-10 08:44 -0700
              Re: Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-10 21:30 +0200
                Re: Return value for strcat and similar functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 20:42 -0700
                  Re: Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-12 09:52 +0200
                    Re: Return value for strcat and similar functions Bartc <bc@freeuk.com> - 2015-05-12 13:33 +0100
                    Re: Return value for strcat and similar functions Ike Naar <ike@iceland.freeshell.org> - 2015-05-14 20:15 +0000
                      Re: Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-14 23:06 +0200
                    Re: Return value for strcat and similar functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-20 11:08 -0700
                      Re: Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-21 10:55 +0200
                        Re: Return value for strcat and similar functions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-21 13:05 +0000
                          Re: Return value for strcat and similar functions David Brown <david.brown@hesbynett.no> - 2015-05-21 20:42 +0200
                        Re: Return value for strcat and similar functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 10:40 -0700
      Re: Return value for strcat and similar functions raltbos@xs4all.nl (Richard Bos) - 2015-05-08 21:56 +0000
        Re: Return value for strcat and similar functions Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-10 09:07 -0700
    Re: Return value for strcat and similar functions Bartc <bc@freeuk.com> - 2015-05-07 10:11 +0100

Page 1 of 2  [1] 2  Next page →

#61598 — Return value for strcat and similar functions

Does anyone know why the return value for strcat and similar library
functions is defined in such an unhelpful (IMHO) way?

The return value of strcat(s1, s2) is always s1, which is a value you
already have available.  Returning a pointer to the end of s1 (i.e., s1
+ strlen(s1)) would be much more efficient when building up a string
from parts.

[toc] | [next] | [standalone]

#61600

Le 06/05/2015 10:02, David Brown a écrit :
> Does anyone know why the return value for strcat and similar library
> functions is defined in such an unhelpful (IMHO) way?

To allow thing such as printf("foo=%s", strcat(foo, bar)) ?

My feeling is that there is no rationale behind, and this was an early historical choice. The [BSD] strlcat() function has a probably much better return value choice in this regard, IMHO.

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

#61611

This thing is called 'standardization before thinking'.
It's very popular and common. Random examples:
The return value of fgets.
Storing dates on 6 digits.
Defining NULL as integer zero.

Ambiguous standards are worse, though;
for example after fifty years,
you still don't know what BackSpace key will (or should) generate:
^? or ^H

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

#61614

David Brown <david.brown@hesbynett.no> writes:
> Does anyone know why the return value for strcat and similar library
> functions is defined in such an unhelpful (IMHO) way?
>
> The return value of strcat(s1, s2) is always s1, which is a value you
> already have available.  Returning a pointer to the end of s1 (i.e., s1
> + strlen(s1)) would be much more efficient when building up a string
> from parts.

Speculation: The early design of C did not go out of its way to allow
for the possibility of buffer overflows.  If you assume that your target
array is always going to be big enough, it's reasonable to write:

    char s[BIG_ENOUGH];
    strcat(strcat(strcpy(s, this), that), the_other_thing);

Personally, even if I were willing to assume the target array is big
enough, I'd probably still break up the calls:

    strcpy(s, this);
    strcat(s, that);
    strcat(s, the_other_thing);

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#61616

On 06/05/15 16:58, Keith Thompson wrote:

<snip>

> Speculation: The early design of C did not go out of its way to allow
> for the possibility of buffer overflows.  If you assume that your target
> array is always going to be big enough, it's reasonable to write:
>
>      char s[BIG_ENOUGH];
>      strcat(strcat(strcpy(s, this), that), the_other_thing);
>
> Personally, even if I were willing to assume the target array is big
> enough, I'd probably still break up the calls:
>
>      strcpy(s, this);
>      strcat(s, that);
>      strcat(s, the_other_thing);

And I'd probably use sprintf(s, "%s%s%s", this,  that, the_other_thing) 
instead. Not because it's quicker (which it might or might not be, since 
strcat has to find the end of the string each time, but sprintf has to 
read and interpret the format string), but because to my eyes it's a 
tiny little bit clearer.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#61623

On 5/6/15 11:07 AM, Richard Heathfield wrote:
> On 06/05/15 16:58, Keith Thompson wrote:
>
> <snip>
>
>> Speculation: The early design of C did not go out of its way to allow
>> for the possibility of buffer overflows.  If you assume that your target
>> array is always going to be big enough, it's reasonable to write:
>>
>>      char s[BIG_ENOUGH];
>>      strcat(strcat(strcpy(s, this), that), the_other_thing);
>>
>> Personally, even if I were willing to assume the target array is big
>> enough, I'd probably still break up the calls:
>>
>>      strcpy(s, this);
>>      strcat(s, that);
>>      strcat(s, the_other_thing);
>
> And I'd probably use sprintf(s, "%s%s%s", this,  that, the_other_thing)
> instead. Not because it's quicker (which it might or might not be, since
> strcat has to find the end of the string each time, but sprintf has to
> read and interpret the format string), but because to my eyes it's a
> tiny little bit clearer.

Another option is to write a variadic function that takes a 
NULL-terminated list of string pointers, and returns a pointer to a 
dynamically-allocated exact-size buffer containing the concatenation:

    rtss(this,that,the_other_thing,NULL);

It's convenient, clear, smaller, and faster than sprintf() - but 
requires remembering to free() the buffer.

A note in the prolog reminds me that I got help from Chris Torek and 
posted the code here sometime around August 29, 1999.

-- 
Morris Dovey
http://www.iedu.com/Solar

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

#61672

On 06/05/15 17:58, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> Does anyone know why the return value for strcat and similar library
>> functions is defined in such an unhelpful (IMHO) way?
>>
>> The return value of strcat(s1, s2) is always s1, which is a value you
>> already have available.  Returning a pointer to the end of s1 (i.e., s1
>> + strlen(s1)) would be much more efficient when building up a string
>> from parts.
> 
> Speculation: The early design of C did not go out of its way to allow
> for the possibility of buffer overflows.  If you assume that your target
> array is always going to be big enough, it's reasonable to write:
> 
>     char s[BIG_ENOUGH];
>     strcat(strcat(strcpy(s, this), that), the_other_thing);
> 
> Personally, even if I were willing to assume the target array is big
> enough, I'd probably still break up the calls:
> 
>     strcpy(s, this);
>     strcat(s, that);
>     strcat(s, the_other_thing);
> 

That's how I would write it.  But if strcat and strcpy returned a
pointer to the end of the string, you could write:

char s[BIG_ENOUGH];
char* t = s;
t = strcpy(t, this);
t = strcat(t, that);
t = strcat(t, the_other_thing);

That just seems so much more sensible to me - you are putting "that"
onto the end of the string, rather than running through the whole string
several times.  Even though it run-time efficiency is not always a
priority in my code, it is usually important enough that glaring
inefficiencies always irritate me.

(Of course, since these are standard functions and the compiler knows
exactly what they do, it could optimise the series of strcat operations
to eliminate the extra search.)

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

#61682

David Brown <david.brown@hesbynett.no> wrote:
> On 06/05/15 17:58, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> Does anyone know why the return value for strcat and similar 
>>> library functions is defined in such an unhelpful (IMHO) way?

(snip) 
>> Speculation: The early design of C did not go out of its way to allow
>> for the possibility of buffer overflows.  If you assume that your target
>> array is always going to be big enough, it's reasonable to write:
 
(snip) 
> That's how I would write it.  But if strcat and strcpy returned a
> pointer to the end of the string, you could write:
 
> char s[BIG_ENOUGH];
> char* t = s;
> t = strcpy(t, this);
> t = strcat(t, that);
> t = strcat(t, the_other_thing);
 
> That just seems so much more sensible to me - you are putting "that"
> onto the end of the string, rather than running through the whole string
> several times.  Even though it run-time efficiency is not always a
> priority in my code, it is usually important enough that glaring
> inefficiencies always irritate me.

C originated on small machines. Seems to me that they didn't think
about how it would scale to really large machines. Pretty much no-one
at the time thought about what you would do with gigabytes of RAM,
or even gigabytes of disk. 

A big disk at the time was 100MB, but they might have had a 5MB disk.

-- glen

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

#61685

On 07/05/15 15:21, glen herrmannsfeldt wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 06/05/15 17:58, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> Does anyone know why the return value for strcat and similar 
>>>> library functions is defined in such an unhelpful (IMHO) way?
> 
> (snip) 
>>> Speculation: The early design of C did not go out of its way to allow
>>> for the possibility of buffer overflows.  If you assume that your target
>>> array is always going to be big enough, it's reasonable to write:
>  
> (snip) 
>> That's how I would write it.  But if strcat and strcpy returned a
>> pointer to the end of the string, you could write:
>  
>> char s[BIG_ENOUGH];
>> char* t = s;
>> t = strcpy(t, this);
>> t = strcat(t, that);
>> t = strcat(t, the_other_thing);
>  
>> That just seems so much more sensible to me - you are putting "that"
>> onto the end of the string, rather than running through the whole string
>> several times.  Even though it run-time efficiency is not always a
>> priority in my code, it is usually important enough that glaring
>> inefficiencies always irritate me.
> 
> C originated on small machines. Seems to me that they didn't think
> about how it would scale to really large machines. Pretty much no-one
> at the time thought about what you would do with gigabytes of RAM,
> or even gigabytes of disk. 
> 
> A big disk at the time was 100MB, but they might have had a 5MB disk.
> 

I work mostly with small machines, with fewer resources than the
earliest C targets.  Re-scanning strings unnecessarily to find their
ends is a waste of resources no matter what size of system you have, and
it would not have been difficult to avoid when strcat, etc., were first
specified.

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

#61703

David Brown <david.brown@hesbynett.no> wrote:

(snip, regarding strcat, then I wrote)

>> C originated on small machines. Seems to me that they didn't think
>> about how it would scale to really large machines. Pretty much no-one
>> at the time thought about what you would do with gigabytes of RAM,
>> or even gigabytes of disk. 
 
>> A big disk at the time was 100MB, but they might have had a 5MB disk.
 
> I work mostly with small machines, with fewer resources than the
> earliest C targets.  Re-scanning strings unnecessarily to find their
> ends is a waste of resources no matter what size of system you have, and
> it would not have been difficult to avoid when strcat, etc., were first
> specified.

Yes. But note that a strcat() loop is O(N**2) in time, and the 
reasonable size for N increases with memory size.  

I once ran into this with real data. Someone had written a program
to read in DNA sequence data, with strcat() in a loop. Sometime later,
we noticed that part was unusually slow. It was reading in megabytes
of data 60 bytes per line. On a PDP-11, you might read in kilobytes
that way, but not megabytes.

I changed the loop to remember where the previous read ended, and
strcpy() the new data in. Not much harder, but O(N).

-- glen

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

#61686

On 5/7/15 3:19 AM, David Brown wrote:

> That's how I would write it.  But if strcat and strcpy returned a
> pointer to the end of the string, you could write:
>
> char s[BIG_ENOUGH];
> char* t = s;
> t = strcpy(t, this);
> t = strcat(t, that);
> t = strcat(t, the_other_thing);
>
> That just seems so much more sensible to me - you are putting "that"
> onto the end of the string, rather than running through the whole string
> several times.  Even though it run-time efficiency is not always a
> priority in my code, it is usually important enough that glaring
> inefficiencies always irritate me.
>
> (Of course, since these are standard functions and the compiler knows
> exactly what they do, it could optimise the series of strcat operations
> to eliminate the extra search.)

Is it worth pointing out that it’s easier to implement the desired
behavior from scratch than to complain about the lack of it? :-P

char *cate(char *d,char *s)
{  if (!s) *(s = d) = '\0';
    while (*d++ = *s++);
    return --d;
}

-- 
Morris Dovey
http://www.iedu.com/Solar

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

#61689

On 5/7/15 10:17 AM, Morris Dovey wrote:
> Is it worth pointing out that it’s easier to implement the desired
> behavior from scratch than to complain about the lack of it? :-P
>
> char *cate(char *d,char *s)
> {  if (!s) *(s = d) = '\0';
>     while (*d++ = *s++);
>     return --d;
> }

On second thought, I think I prefer

char *cate(char *d,char *s)
{  if (!s) *d++ = '\0';
    else while (*d++ = *s++);
    return --d;
}

-- 
Morris Dovey
http://www.iedu.com/Solar/
http://www.facebook.com/MorrisDovey

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

#61701

Morris wrote:"
char *cate(char *d,char *s) 
{  if (!s) *d++ = '\0'; 
    else while (*d++ = *s++); 

    return --d; 
}"

char*  cate(char *d,char *s) 
{   if(d==0) return 0;
    else if(s==0) *d++ = '\0'; 
    else    while(*d++ = *s++); 
    return --d; 
}

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

#61714

On 5/7/15 1:00 PM, asetofsymbols@gmail.com wrote:
> char*  cate(char *d,char *s)
> {   if(d==0) return 0;
>      else if(s==0) *d++ = '\0';
>      else    while(*d++ = *s++);
>      return --d;
> }

I thought about that, then decided that while s==NULL could conceivably 
be valid, d==NULL would always indicate an error. Silently returning a 
NULL pointer would mask the error, and my preference is to fail early.

When I got done tinkering, this is what I settled on:

char *cate(char *d,char *s)
{  if (s) while (*d++ = *s++);
    else *d++ = '\0';
    return --d;
}

Whatever, I like that the one function can fill the roles of both 
strcpy() and strcat() and eliminate the pointer initialization in 
David's sample scenario:

char s[BIG_ENOUGH], *t;
t = cate(s,this);
t = cate(t,that);
t = cate(t,the_other_thing);

-- 
Morris Dovey
http://www.iedu.com/Solar

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

#61719

Return 0 as pointer means "Return
error"... No library function
has to seg fault, the seg fault
I say it is better out

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

#61794

On 2015-05-07, Morris Dovey <mrdovey@iedu.com> wrote:
> On 5/7/15 10:17 AM, Morris Dovey wrote:
>> Is it worth pointing out that it???s easier to implement the desired
>> behavior from scratch than to complain about the lack of it? :-P

[snip]

Probably, since I was about to post the same thing.  The only downside
of course is that you don't get the benefit of any assembly optimized
implementation.

-- 
nw

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

#61731

Morris Dovey <mrdovey@iedu.com> writes:

> On 5/7/15 3:19 AM, David Brown wrote:
>
>> That's how I would write it.  But if strcat and strcpy returned a
>> pointer to the end of the string, you could write:
>>
>> char s[BIG_ENOUGH];
>> char* t = s;
>> t = strcpy(t, this);
>> t = strcat(t, that);
>> t = strcat(t, the_other_thing);
>>
>> That just seems so much more sensible to me - you are putting "that"
>> onto the end of the string, rather than running through the whole string
>> several times.  Even though it run-time efficiency is not always a
>> priority in my code, it is usually important enough that glaring
>> inefficiencies always irritate me.
>>
>> (Of course, since these are standard functions and the compiler knows
>> exactly what they do, it could optimise the series of strcat operations
>> to eliminate the extra search.)
>
> Is it worth pointing out that it's easier to implement the desired
> behavior from scratch than to complain about the lack of it? :-P

+1

> char *cate(char *d,char *s)
> {  if (!s) *(s = d) = '\0';
>    while (*d++ = *s++);
>    return --d;
> }

    char *
    add_more( char *d, char *s ){
        return  (*d = *s)  ?  add_more( d+1, s+1 )  :  d;
    }

(I'm not wild about the name add_more, maybe someone has a better
suggestion.)

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

#61756

On 07/05/15 17:17, Morris Dovey wrote:
> On 5/7/15 3:19 AM, David Brown wrote:
> 
>> That's how I would write it.  But if strcat and strcpy returned a
>> pointer to the end of the string, you could write:
>>
>> char s[BIG_ENOUGH];
>> char* t = s;
>> t = strcpy(t, this);
>> t = strcat(t, that);
>> t = strcat(t, the_other_thing);
>>
>> That just seems so much more sensible to me - you are putting "that"
>> onto the end of the string, rather than running through the whole string
>> several times.  Even though it run-time efficiency is not always a
>> priority in my code, it is usually important enough that glaring
>> inefficiencies always irritate me.
>>
>> (Of course, since these are standard functions and the compiler knows
>> exactly what they do, it could optimise the series of strcat operations
>> to eliminate the extra search.)
> 
> Is it worth pointing out that it’s easier to implement the desired
> behavior from scratch than to complain about the lack of it? :-P
> 

Yes, in the case of strcat the functionality is particularly easy to
duplicate (often it is not even worth making it a separate function).  I
am not complaining as such - I am more curious to know if there is any
good reason why strcat was specified the way it is, when it could so
easily have been more efficient.

> char *cate(char *d,char *s)
> {  if (!s) *(s = d) = '\0';
>    while (*d++ = *s++);
>    return --d;
> }
> 

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

#61758

On 5/8/15 4:03 AM, David Brown wrote:
> Yes, in the case of strcat the functionality is particularly easy to
> duplicate (often it is not even worth making it a separate function).
> I am not complaining as such - I am more curious to know if there is
> any good reason why strcat was specified the way it is, when it could
> so easily have been more efficient.

I can't do much more than speculate that there might have been a lot of
'get it working, then can polish it up later' going on, along with a
certain amount of pressure for a working version of unix ASAP. I suspect
a lot of that 'polishing' never actually got done and a lot of good
ideas (multiple entry points, for example) never saw the light of day.
The original syntax has always struck me as 'cobbled' and lacking
elegance - and I'm inclined to think polish wasn't of much concern.

Of course, once there was a working compiler and operating system, then
there was likely considerable managerial resistance to change on the 'if
it ain't broke, don't fix it!' principal.

-- 
Morris Dovey
http://www.iedu.com/Solar

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

#61654

David Brown <david.brown@hesbynett.no> writes:

> Does anyone know why the return value for strcat and similar library
> functions is defined in such an unhelpful (IMHO) way?
>
> The return value of strcat(s1, s2) is always s1, which is a value you
> already have available.  Returning a pointer to the end of s1 (i.e., s1
> + strlen(s1)) would be much more efficient when building up a string
> from parts.

You're assuming that the value of the first argument is readily
available otherwise, which isn't always true - it could be the
result of a function call, for example.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web