problem with strcat function

[ramubdvt@gmail.com]

hi,
i have written this strcat but sometime it is giving problem, while
handeling some strings containing
binary and if string containing zero ,
funtion which takes string 1 and its length string2 and its length as
arguments

please tell the correction ,

here iam using
typedef char SINT8;
typedef unsigned char UINT8;
typedef short SINT16;
typedef unsigned short UINT16;
typedef int SINT32;
typedef unsigned int UINT32;
typedef long long UINT64;

UINT8 *
Stringcat (UINT8 *str1
, UINT32 str1len
, UINT8 *str2
, UINT32 str2len )
{
UINT8 *str3, *temp;
temp = str3 = (char *) calloc (( str1len + str2len) + 1) ,1 );
while ( ( *str3++ = *str1++) );
str3--;
while ( ( *str3++ = *str2++ ) );
return temp;
}


regards
ramaswamy BM
banglore

[Vladimir S. Oka]

Re: problem with strcat function


ramubdvt@gmail. com wrote:[color=blue]
> hi,
> i have written this strcat[/color]

What's wrong with the standard one? If you need a third string to
contain the result, it should be easy enough to use `strcat()` and some
additional code.
[color=blue]
> but sometime it is giving problem, while
> handeling some strings containing
> binary and if string containing zero ,[/color]

I don't really understand what you mean by "binary", but you should
know that C strings are arrays of `char` terminated by the `char` with
the value of zero.
[color=blue]
> funtion which takes string 1 and its length string2 and its length as
> arguments
>
> please tell the correction ,
>
> here iam using
> typedef char SINT8;
> typedef unsigned char UINT8;
> typedef short SINT16;
> typedef unsigned short UINT16;
> typedef int SINT32;
> typedef unsigned int UINT32;
> typedef long long UINT64;[/color]

These are highly misleading. What happens (to someone reading the code)
when your underlying architecture changes, together with the sizes
implied above?
[color=blue]
> UINT8 *
> Stringcat (UINT8 *str1
> , UINT32 str1len
> , UINT8 *str2
> , UINT32 str2len )
> {
> UINT8 *str3, *temp;
> temp = str3 = (char *) calloc (( str1len + str2len) + 1) ,1 );[/color]

No need for a cast here. It may mask omission to include <stdlib.h>.
[color=blue]
> while ( ( *str3++ = *str1++) );[/color]

Herein lies your "zero" problem. You copy until you encounter zero.
What was then the point of passing string lengths in the first place?
[color=blue]
> str3--;
> while ( ( *str3++ = *str2++ ) );[/color]

Same here...

You probably want simple loops from start to the end of the string,
using the lengths that you get passed.
[color=blue]
> return temp;
> }[/color]

I'd still recommend wrapping standard `strcat()` in some extra code.

--
BR, Vladimir

[Vladimir S. Oka]

Re: problem with strcat function


Vladimir S. Oka wrote:[color=blue]
> ramubdvt@gmail. com wrote:[color=green]
> > hi,
> > i have written this strcat[/color]
>
> What's wrong with the standard one? If you need a third string to
> contain the result, it should be easy enough to use `strcat()` and some
> additional code.
>[color=green]
> > but sometime it is giving problem, while
> > handeling some strings containing
> > binary and if string containing zero ,[/color]
>
> I don't really understand what you mean by "binary", but you should
> know that C strings are arrays of `char` terminated by the `char` with
> the value of zero.
>[color=green]
> > funtion which takes string 1 and its length string2 and its length as
> > arguments
> >
> > please tell the correction ,
> >
> > here iam using
> > typedef char SINT8;
> > typedef unsigned char UINT8;
> > typedef short SINT16;
> > typedef unsigned short UINT16;
> > typedef int SINT32;
> > typedef unsigned int UINT32;
> > typedef long long UINT64;[/color]
>
> These are highly misleading. What happens (to someone reading the code)
> when your underlying architecture changes, together with the sizes
> implied above?
>[color=green]
> > UINT8 *
> > Stringcat (UINT8 *str1
> > , UINT32 str1len
> > , UINT8 *str2
> > , UINT32 str2len )
> > {
> > UINT8 *str3, *temp;
> > temp = str3 = (char *) calloc (( str1len + str2len) + 1) ,1 );[/color]
>
> No need for a cast here. It may mask omission to include <stdlib.h>.[/color]

You should also check for success. `calloc()`, just like `malloc()`
returns NULL if allocation did not succeed.
[color=blue][color=green]
> > while ( ( *str3++ = *str1++) );[/color]
>
> Herein lies your "zero" problem. You copy until you encounter zero.
> What was then the point of passing string lengths in the first place?
>[color=green]
> > str3--;
> > while ( ( *str3++ = *str2++ ) );[/color]
>
> Same here...
>
> You probably want simple loops from start to the end of the string,
> using the lengths that you get passed.
>[color=green]
> > return temp;
> > }[/color]
>
> I'd still recommend wrapping standard `strcat()` in some extra code.
>
> --
> BR, Vladimir[/color]

[Keith Thompson]

Re: problem with strcat function

ramubdvt@gmail. com writes:[color=blue]
> i have written this strcat but sometime it is giving problem, while
> handeling some strings containing
> binary and if string containing zero ,
> funtion which takes string 1 and its length string2 and its length as
> arguments
>
> please tell the correction ,
>
> here iam using
> typedef char SINT8;
> typedef unsigned char UINT8;
> typedef short SINT16;
> typedef unsigned short UINT16;
> typedef int SINT32;
> typedef unsigned int UINT32;
> typedef long long UINT64;[/color]

These typedefs are potentially misleading. The sizes of the
predefined types can and do vary across implementations . Plain char
can be either signed or unsigned; if you want a signed type use
"signed char".

It's fortunate that you don't use UINT64, since you've defined it as a
*signed* type.

Knowing the exact sizes of the types you're using is usually not as
useful as you might think. More often, you should select types based
on what they're to be used for rather than on how big they are.
[color=blue]
> UINT8 *
> Stringcat (UINT8 *str1
> , UINT32 str1len
> , UINT8 *str2
> , UINT32 str2len )
> {
> UINT8 *str3, *temp;
> temp = str3 = (char *) calloc (( str1len + str2len) + 1) ,1 );
> while ( ( *str3++ = *str1++) );
> str3--;
> while ( ( *str3++ = *str2++ ) );
> return temp;
> }[/color]

A string is an array of char. Just use type char rahter than UINT8.

Use size_t (defined in <stddef.h>) for sizes and lengths. This
eliminates the need for any of your typedefs.

Your function does something quite different from strcat() (strcat()
doesn't allocated any memory). That's not a bad thing, but the name
is a bit misleading.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[santosh]

Re: problem with strcat function

ramubdvt@gmail. com wrote:[color=blue]
> hi,
> i have written this strcat but sometime it is giving problem, while
> handeling some strings containing
> binary and if string containing zero ,
> funtion which takes string 1 and its length string2 and its length as
> arguments
>
> please tell the correction ,
>
> here iam using
> typedef char SINT8;
> typedef unsigned char UINT8;
> typedef short SINT16;
> typedef unsigned short UINT16;
> typedef int SINT32;
> typedef unsigned int UINT32;
> typedef long long UINT64;[/color]

Why don't you use the portable and standard definitions in stdint.h?
[color=blue]
>
> UINT8 *
> Stringcat (UINT8 *str1
> , UINT32 str1len
> , UINT8 *str2
> , UINT32 str2len )
> {
> UINT8 *str3, *temp;
> temp = str3 = (char *) calloc (( str1len + str2len) + 1) ,1 );[/color]

You're not checking for calloc() failure. Even otherwise, malloc()
would be sufficient.
[color=blue]
> while ( ( *str3++ = *str1++) );
> str3--;
> while ( ( *str3++ = *str2++ ) );
> return temp;
> }[/color]

Code like this will crash. If you really want to concactenate strings
the standard strcat() or strncat() would probably be sufficient.

[CBFalconer]

Re: problem with strcat function

santosh wrote:[color=blue]
> ramubdvt@gmail. com wrote:[color=green]
>>[/color][/color]
.... snip ...[color=blue][color=green]
>>
>> while ( (*str3++ = *str1++) );
>> str3--;
>> while ( (*str3++ = *str2++) );[/color]
>
> Code like this will crash. If you really want to concactenate
> strings the standard strcat() or strncat() would probably be
> sufficient.[/color]

I see no reason it should crash, assuming str3 has sufficient
room. But if you want safe overall operation, use strlcat and
strncpy (non-standard). They are available, written in pure
standard C, at:

<http://cbfalconer.home .att.net/download/strlcat.zip>

--
"The power of the Executive to cast a man into prison without
formulating any charge known to the law, and particularly to
deny him the judgement of his peers, is in the highest degree
odious and is the foundation of all totalitarian government
whether Nazi or Communist." -- W. Churchill, Nov 21, 1943

[Barry Schwarz]

Re: problem with strcat function

On 23 Mar 2006 01:00:47 -0800, ramubdvt@gmail. com wrote:
[color=blue]
>hi,
>i have written this strcat but sometime it is giving problem, while
>handeling some strings containing
>binary and if string containing zero ,[/color]

And it should. If you intend to handle "binary strings", you should
be using the length parameter instead of checking for a character with
value 0.
[color=blue]
>funtion which takes string 1 and its length string2 and its length as
>arguments
>
>please tell the correction ,
>
>here iam using
>typedef char SINT8;
>typedef unsigned char UINT8;
>typedef short SINT16;
>typedef unsigned short UINT16;
>typedef int SINT32;
>typedef unsigned int UINT32;
>typedef long long UINT64;
>
>UINT8 *
>Stringcat (UINT8 *str1
> , UINT32 str1len
> , UINT8 *str2
> , UINT32 str2len )
>{
> UINT8 *str3, *temp;
> temp = str3 = (char *) calloc (( str1len + str2len) + 1) ,1 );[/color]

Did you not get a syntax error here? temp and str3 are both unsigned
char*. Thanks to the useless and incorrect cast, the right side of
the expression evaluates to a char*. The two types are incompatible;
there is no implicit conversion from one to the other.
[color=blue]
> while ( ( *str3++ = *str1++) );
> str3--;[/color]

You can replace these two statements with
for (; str1len > 0; str1len--)
*str3++ = *str1++;
[color=blue]
> while ( ( *str3++ = *str2++ ) );[/color]

Similar but use >=.
[color=blue]
> return temp;
>}
>
>
>regards
>ramaswamy BM
>banglore[/color]


Remove del for email

[MrG{DRGN}]

Re: problem with strcat function


"CBFalconer " <cbfalconer@yah oo.com> wrote in message
news:4422F2CA.1 1598744@yahoo.c om...
snip[color=blue]
>
> <http://cbfalconer.home .att.net/download/strlcat.zip>
>[/color]

That seems to be a bad. I tried it twice to no avail. It seems to bring up
at&t's 404 page.


--
MrG{DRGN}

[Keith Thompson]

Re: problem with strcat function

"MrG{DRGN}" <Iamnot@here.co m> writes:[color=blue]
> "CBFalconer " <cbfalconer@yah oo.com> wrote in message
> news:4422F2CA.1 1598744@yahoo.c om...
> snip[color=green]
>>
>> <http://cbfalconer.home .att.net/download/strlcat.zip>
>>[/color]
>
> That seems to be a bad. I tried it twice to no avail. It seems to bring up
> at&t's 404 page.[/color]

Try <http://cbfalconer.home .att.net/download/strlcpy.zip>; it includes
both strlcpy and strlcat.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[jaysome]

Re: problem with strcat function

CBFalconer wrote:[color=blue]
> santosh wrote:
>[color=green]
>>ramubdvt@gmai l.com wrote:
>>[/color]
> ... snip ...
>[color=green][color=darkred]
>>> while ( (*str3++ = *str1++) );
>>> str3--;
>>> while ( (*str3++ = *str2++) );[/color]
>>
>>Code like this will crash. If you really want to concactenate
>>strings the standard strcat() or strncat() would probably be
>>sufficient.[/color]
>
>
> I see no reason it should crash, assuming str3 has sufficient
> room. But if you want safe overall operation, use strlcat and
> strncpy (non-standard). They are available, written in pure
> standard C, at:
>
> <http://cbfalconer.home .att.net/download/strlcat.zip>[/color]

Aren't function names that begin with "str" followed by another lower
case letter reserved for the implementation? If so, I think the function
names "strlcpy" and "strlcat" are in violation of this rule.

You could name them "str_lcpy" and "str_lcat" to get around this, but
that would invoke undefined behavior, in C89 at least (see Section 6.1.2
of the ANSI/ISO 9899-1990 standard; and for those with a copy of the
best book Herbert Schildt ever wrote, see pages 20 and 200, bullet 7).

--
jay

[CBFalconer]

Re: problem with strcat function

MrG{DRGN} wrote:[color=blue]
> "CBFalconer " <cbfalconer@yah oo.com> wrote in message
>
> snip[color=green]
>>
>> <http://cbfalconer.home .att.net/download/strlcat.zip>
>>[/color]
>
> That seems to be a bad. I tried it twice to no avail. It seems to
> bring up at&t's 404 page.[/color]

Sorry. That should be:

<http://cbfalconer.home .att.net/download/strlcpy.zip>

A tip in general - when something like that happens, remove the
last identifier in the URL and see what happens. In this case you
would have gotten an index to the download directory.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell. org/google/>
Also see <http://www.safalra.com/special/googlegroupsrep ly/>

[CBFalconer]

Re: problem with strcat function

jaysome wrote:[color=blue]
> CBFalconer wrote:[color=green]
>> santosh wrote:[color=darkred]
>>> ramubdvt@gmail. com wrote:
>>>[/color]
>> ... snip ...
>>[color=darkred]
>>>> while ( (*str3++ = *str1++) );
>>>> str3--;
>>>> while ( (*str3++ = *str2++) );
>>>
>>> Code like this will crash. If you really want to concactenate
>>> strings the standard strcat() or strncat() would probably be
>>> sufficient.[/color]
>>
>> I see no reason it should crash, assuming str3 has sufficient
>> room. But if you want safe overall operation, use strlcat and
>> strncpy (non-standard). They are available, written in pure
>> standard C, at:
>>
>> <http://cbfalconer.home .att.net/download/strlcat.zip>[/color][/color]

This should end in "strlcpy.zi p" -----------^^^^^^^^^^^[color=blue]
>
> Aren't function names that begin with "str" followed by another
> lower case letter reserved for the implementation? If so, I think
> the function names "strlcpy" and "strlcat" are in violation of
> this rule.
>
> You could name them "str_lcpy" and "str_lcat" to get around this,
> but that would invoke undefined behavior, in C89 at least (see
> Section 6.1.2 of the ANSI/ISO 9899-1990 standard; and for those
> with a copy of the best book Herbert Schildt ever wrote, see
> pages 20 and 200, bullet 7).[/color]

You are absolutely right. However this came from the freeBSD
organization, I just produced an implementation. In practice the
names will probably not conflict. The documentation mentions this
IIRC. You are, of course, free to change the names.

Various people out there are attempting to have these included in
the next standard. They are much more useful, and safe, than the
existing routines.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell. org/google/>
Also see <http://www.safalra.com/special/googlegroupsrep ly/>

[Jordan Abel]

Re: problem with strcat function

On 2006-03-24, jaysome <jaysome@spamco p.com> wrote:[color=blue]
> CBFalconer wrote:[color=green]
>> santosh wrote:
>>[color=darkred]
>>>ramubdvt@gma il.com wrote:
>>>[/color]
>> ... snip ...
>>[color=darkred]
>>>> while ( (*str3++ = *str1++) );
>>>> str3--;
>>>> while ( (*str3++ = *str2++) );
>>>
>>>Code like this will crash. If you really want to concactenate
>>>strings the standard strcat() or strncat() would probably be
>>>sufficient .[/color]
>>
>>
>> I see no reason it should crash, assuming str3 has sufficient
>> room. But if you want safe overall operation, use strlcat and
>> strncpy (non-standard). They are available, written in pure
>> standard C, at:
>>
>> <http://cbfalconer.home .att.net/download/strlcat.zip>[/color]
>
> Aren't function names that begin with "str" followed by another lower
> case letter reserved for the implementation? If so, I think the function
> names "strlcpy" and "strlcat" are in violation of this rule.
>
> You could name them "str_lcpy" and "str_lcat" to get around this, but
> that would invoke undefined behavior, in C89 at least (see Section
> 6.1.2 of the ANSI/ISO 9899-1990 standard)[/color]

How about an ANSI section number, for those of us stuck with the draft?

[jaysome]

Re: problem with strcat function

CBFalconer wrote:
[color=blue]
> jaysome wrote:
>[color=green]
>>CBFalconer wrote:
>>[color=darkred]
>>>santosh wrote:
>>>
>>>>ramubdvt@gm ail.com wrote:
>>>>
>>>
>>>... snip ...
>>>
>>>
>>>>> while ( (*str3++ = *str1++) );
>>>>> str3--;
>>>>> while ( (*str3++ = *str2++) );
>>>>
>>>>Code like this will crash. If you really want to concactenate
>>>>strings the standard strcat() or strncat() would probably be
>>>>sufficien t.
>>>
>>>I see no reason it should crash, assuming str3 has sufficient
>>>room. But if you want safe overall operation, use strlcat and
>>>strncpy (non-standard). They are available, written in pure
>>>standard C, at:
>>>
>>> <http://cbfalconer.home .att.net/download/strlcat.zip>[/color][/color]
>
>
> This should end in "strlcpy.zi p" -----------^^^^^^^^^^^
>[color=green]
>>Aren't function names that begin with "str" followed by another
>>lower case letter reserved for the implementation? If so, I think
>>the function names "strlcpy" and "strlcat" are in violation of
>>this rule.
>>
>>You could name them "str_lcpy" and "str_lcat" to get around this,
>>but that would invoke undefined behavior, in C89 at least (see
>>Section 6.1.2 of the ANSI/ISO 9899-1990 standard; and for those
>>with a copy of the best book Herbert Schildt ever wrote, see
>>pages 20 and 200, bullet 7).[/color]
>
>
> You are absolutely right. However this came from the freeBSD
> organization, I just produced an implementation. In practice the
> names will probably not conflict. The documentation mentions this
> IIRC. You are, of course, free to change the names.[/color]

I'd go so far as to say that the names will *never* conflict. Even in
the time frame between when the C89 standard was drafted and when it was
approved, there was no good reason to restrict identifier name
unambiguity to just six characters. If there was such a reason, I'd love
to hear the rationale.
[color=blue]
> Various people out there are attempting to have these included in
> the next standard. They are much more useful, and safe, than the
> existing routines.[/color]

I agree. I've started to use your code in some of my projects and have
seen first-hand how it makes things so much easier.

Thanks
--
jay

[Keith Thompson]

Re: problem with strcat function

jaysome <jaysome@spamco p.com> writes:[color=blue]
> CBFalconer wrote:[color=green]
>> santosh wrote:
>>[color=darkred]
>>>ramubdvt@gma il.com wrote:
>>>[/color]
>> ... snip ...
>>[color=darkred]
>>>> while ( (*str3++ = *str1++) );
>>>> str3--;
>>>> while ( (*str3++ = *str2++) );
>>>
>>>Code like this will crash. If you really want to concactenate
>>>strings the standard strcat() or strncat() would probably be
>>>sufficient .[/color]
>> I see no reason it should crash, assuming str3 has sufficient
>> room. But if you want safe overall operation, use strlcat and
>> strncpy (non-standard). They are available, written in pure
>> standard C, at:
>> <http://cbfalconer.home .att.net/download/strlcat.zip>[/color][/color]

(Correction: <http://cbfalconer.home .att.net/download/strlcpy.zip>.)
[color=blue]
> Aren't function names that begin with "str" followed by another lower
> case letter reserved for the implementation? If so, I think the
> function names "strlcpy" and "strlcat" are in violation of this rule.[/color]

Yes, as acknowledged on the index page:

My implementation of the BSD standard routines strlcpy and
strlcat. NOTE: the names are illegal in standard C, and should
have a prefix added for general use. You don't need to do this if
you are very sure your system doesn't implement them.

But in BSD, I believe the functions (or equivalent functions with the
same names) are part of the implementation. (I'm actually not sure
what that implies about the identifiers being reserved.)
[color=blue]
> You could name them "str_lcpy" and "str_lcat" to get around this, but
> that would invoke undefined behavior, in C89 at least (see Section
> 6.1.2 of the ANSI/ISO 9899-1990 standard; and for those with a copy of
> the best book Herbert Schildt ever wrote, see pages 20 and 200, bullet
> 7).[/color]

Referring to the permission to limit external identifiers to 6
significant characters. C99 expanded the limit to 31 characters.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.