c equivilant to "copy"

Greetings,
I've been trying to find an equivant c funtion to the c++ copy function.

Description:

copy(char *cstring, size_t count, size_t offset);

Copies "count" characters from a C-style string starting at offset.


Let's say I have the string "Hello There" and I needed only the "llo" part
from hello. How would I accomplish this? Using the c++ I could use the
copy function.

Any help would be appreciated,
Thanks!

re: c equivilant to "copy"

Shagy wrote:
[color=blue]
>Greetings,
>I've been trying to find an equivant c funtion to the c++ copy function.
>
>Description:
>
> copy(char *cstring, size_t count, size_t offset);
>
> Copies "count" characters from a C-style string starting at offset.
>
>
>Let's say I have the string "Hello There" and I needed only the "llo" part
>from hello. How would I accomplish this? Using the c++ I could use the
>copy function.
>
>Any help would be appreciated,
>Thanks!
>
>
>
>[/color]
Probably what you are asking ...

strncpy(dest, cstring + offset, count);
dest[count] = '\0';

assuming dest in large enough to hold 'count + 1' character.

Krishanu

re: c equivilant to "copy"

Krishanu Debnath wrote:[color=blue]
>
> Shagy wrote:
>[color=green]
> >Greetings,
> >I've been trying to find an equivant c funtion to
> >the c++ copy function.
> >
> >Description:
> >
> > copy(char *cstring, size_t count, size_t offset);
> >
> > Copies "count" characters from a C-style string starting at offset.
> >
> >
> >Let's say I have the string "Hello There"
> >and I needed only the "llo" part from hello.
> > How would I accomplish this?
> >Using the c++ I could use the copy function.[/color][/color]
[color=blue]
> Probably what you are asking ...
>
> strncpy(dest, cstring + offset, count);
> dest[count] = '\0';
>
> assuming dest in large enough to hold 'count + 1' character.[/color]

Since you are not copying an entire string,
memcpy would work just as well as strncpy.

/* BEGIN new.c */

#include <string.h>
#include <stdio.h>

int main(void)
{
char dest[sizeof "llo"];
size_t count;

count = sizeof dest - 1;
memcpy(dest, "Hello There" + 2, count);
dest[count] = '\0';
puts(dest);
return 0;
}

/* END new.c */

re: c equivilant to "copy"

Thanks!!!

Both examples work great!!!

Shagy

"Shagy" <noemail@noemail.com> wrote in message
news:cs5pjl$drp$1@nic.grnet.gr...[color=blue]
> Greetings,
> I've been trying to find an equivant c funtion to the c++ copy function.
>
> Description:
>
> copy(char *cstring, size_t count, size_t offset);
>
> Copies "count" characters from a C-style string starting at offset.
>
>
> Let's say I have the string "Hello There" and I needed only the "llo"
> part from hello. How would I accomplish this? Using the c++ I could use
> the copy function.
>
> Any help would be appreciated,
> Thanks!
>[/color]

re: c equivilant to "copy"

Shagy wrote:[color=blue]
>
> I've been trying to find an equivant c funtion to the c++ copy
> function.
>
> Description:
>
> copy(char *cstring, size_t count, size_t offset);
>
> Copies "count" characters from a C-style string starting at
> offset.
>
> Let's say I have the string "Hello There" and I needed only
> the "llo" part from hello. How would I accomplish this? Using
> the c++ I could use the copy function.[/color]

char *strncpy(char *dest, const char *src, size_t max);

is available in <strings.h>. The corresponding usage would be:

dest = strncpy(dest, src + offset, max);

and you can obviously omit the "dest =" portion. In your example:

strncpy(dest, "Hello There" + 2, 3);

However you will get better and safer results by using strlcpy (and
strlcat) as proposed by the BSD group. You can find an
implementation, justification, and description at:

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

--
"If you want to post a followup via groups.google.com, 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

re: c equivilant to "copy"

On Thu, 13 Jan 2005 16:57:47 +0000, CBFalconer wrote:
[color=blue]
> Shagy wrote:[color=green]
>>
>> I've been trying to find an equivant c funtion to the c++ copy
>> function.
>>
>> Description:
>>
>> copy(char *cstring, size_t count, size_t offset);
>>
>> Copies "count" characters from a C-style string starting at
>> offset.
>>
>> Let's say I have the string "Hello There" and I needed only
>> the "llo" part from hello. How would I accomplish this? Using
>> the c++ I could use the copy function.[/color]
>
> char *strncpy(char *dest, const char *src, size_t max);[/color]

But be aware that strncpy() is a dangerous function for the unwary, it
doesn't always null terminate the destination string. strncat() is better.
[color=blue]
> is available in <strings.h>. The corresponding usage would be:[/color]

That would be <string.h>
[color=blue]
> dest = strncpy(dest, src + offset, max);
>
> and you can obviously omit the "dest =" portion. In your example:
>
> strncpy(dest, "Hello There" + 2, 3);[/color]

dest[0] = '\0';
strncat(dest, "Hello There" + 2, 3);

is a better approach. In this case as others have mentioned memcpy() is
another possibility as in

memcpy(dest, "Hello There" + 2, 3);
dest[3] = '\0';

Also consider sprintf()

sprintf(dest, "%.3s", "Hello There" + 2);

The real benefit of sprintf() can be seen if this is just a part of
building a more complex string.

Lawrence

re: c equivilant to "copy"

Krishanu Debnath wrote:
[color=blue]
> Probably what you are asking ...
>
> strncpy(dest, cstring + offset, count);
> dest[count] = '\0';
>
> assuming dest in large enough to hold 'count + 1' character.
>
> Krishanu
>[/color]

My favorite way of doing this is:

strncpy( dest, cstring + offset, count )[count] = '\0';

It works because strncpy() returns the address of the dest argument.

--
Regards,
Stan Milam
================================================== ===========
Charter Member of The Society for Mediocre Guitar Playing on
Expensive Instruments, Ltd.
================================================== ===========

re: c equivilant to "copy"

Stan Milam <stmilam@swbell.net> writes:
[color=blue]
> My favorite way of doing this is:
>
> strncpy( dest, cstring + offset, count )[count] = '\0';
>
> It works because strncpy() returns the address of the dest argument.[/color]

cool. ;-)

Can someone give an example that strncpy() would be safer than strcpy() ?
Should we never use strcpy() ?

--
William

re: c equivilant to "copy"

On Mon, 17 Jan 2005 16:01:24 +0800, William Xuuu
<william_xuuu@163.com> wrote:
[color=blue]
> Stan Milam <stmilam@swbell.net> writes:
>[color=green]
>> My favorite way of doing this is:
>>
>> strncpy( dest, cstring + offset, count )[count] = '\0';
>>
>> It works because strncpy() returns the address of the dest argument.[/color]
>
> cool. ;-)
>
> Can someone give an example that strncpy() would be safer than strcpy() ?[/color]

#include <stdio.h>

void func(const char *str)
{
char buff[10];
strcpy(buff, str);
printf("%s\n", buff);
}

int main(int argc, char **argv)
{
if (argc > 1)
func(argv[1]);
return 0;
}

If the user runs this with parameter "1234567890", the buffer will
overflow (10 characters plus the terminating '\0'), as it will with a
longer string. In the Real World(tm) user input can't be guaranteed to
be right. If the strcpy were replaced by

strncpy(buff, str, 9)[9[ = '\0';

the program would be safe. (In practice, of course, you might want to
detect the overflow and report it as an error, and to use sizeof(buff)-1
instead of an explicit value.)
[color=blue]
> Should we never use strcpy() ?[/color]

strcpy() is completely safe to use /if/ you know that the string will
fit. Most of the time in my programs I know that the string will fit
because I have done checks elsewhere, or because I have just allocated
memory to the size of the string:

char *strDup(const char *str)
{
char *p = malloc(strlen(str) + 1);
if (p)
return strcpy(p, str);
return NULL;
}

Note that strcat also has the problem that the buffer can overflow, and
it's messy and wasteful to use strncat to detect that (since strncat
takes the number of characters to be copied not the length of the
buffer, so you still have to do strlen(buff) to determine whether the
string will fit).

Also, strncpy() will pad out the rest of the buffer with nul ('\0')
characters. Most of the time this is wasteful, especially if using a
big buffer with a small source string many times.

Because of these faults, the functions strlcpy() and strlcat() were
introduced in OpenBSD 2.4, and many of us hope that they will be
incorporated into a future C standard revision. See

http://www.courtesan.com/todd/papers/strlcpy.html

for example (the functions are easy to write, or you can use the OpenBSD
source under their Free Software licence).

Chris C

re: c equivilant to "copy"

Chris Croughton wrote:[color=blue]
>[/color]
.... snip ...[color=blue]
>
> Because of these faults, the functions strlcpy() and strlcat() were
> introduced in OpenBSD 2.4, and many of us hope that they will be
> incorporated into a future C standard revision. See
>
> http://www.courtesan.com/todd/papers/strlcpy.html
>
> for example (the functions are easy to write, or you can use the
> OpenBSD source under their Free Software licence).[/color]

Or you can use my implementation (in portable code, which I have
put in the public domain) found at:

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

The point is that they are much safer. If your system already
provides them, use them. If not it is almost always safe to use
those reserved names (I know of no exceptions).

--
"If you want to post a followup via groups.google.com, 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

re: c equivilant to "copy"

On Mon, 17 Jan 2005 14:33:37 GMT, CBFalconer
<cbfalconer@yahoo.com> wrote:
[color=blue]
> Chris Croughton wrote:[color=green]
>>[/color]
> ... snip ...[color=green]
>>
>> Because of these faults, the functions strlcpy() and strlcat() were
>> introduced in OpenBSD 2.4, and many of us hope that they will be
>> incorporated into a future C standard revision. See
>>
>> http://www.courtesan.com/todd/papers/strlcpy.html
>>
>> for example (the functions are easy to write, or you can use the
>> OpenBSD source under their Free Software licence).[/color]
>
> Or you can use my implementation (in portable code, which I have
> put in the public domain) found at:
>
> <http://cbfalconer.home.att.net/download/strlcpy.zip>[/color]

My ones use memmove so they are safe against overlapping strings, but I
see why you didn't want to use other library functions (my code uses the
Zlib licence, which is about as free as it gets without being PD). I
notice you include the page I pointed to.
[color=blue]
> The point is that they are much safer. If your system already
> provides them, use them. If not it is almost always safe to use
> those reserved names (I know of no exceptions).[/color]

Solaris and some of the BSD variants already have them in string.h If
the prototypes are compatible (for instance no one using the restrict
keyword on the pointers) there shouldn't be a problem with including the
header file as well as string.h.

Chris C

re: c equivilant to "copy"

Stan Milam <stmilam@swbell.net> wrote:
[color=blue]
> Krishanu Debnath wrote:
>[color=green]
> > strncpy(dest, cstring + offset, count);
> > dest[count] = '\0';
> >
> > assuming dest in large enough to hold 'count + 1' character.[/color]
>
> My favorite way of doing this is:
>
> strncpy( dest, cstring + offset, count )[count] = '\0';[/color]

Well, thanks a lot for propagating the idea that we C programmers create
write-only code :-/

Richard

re: c equivilant to "copy"

On Sat, 15 Jan 2005 00:41:47 +0000, Stan Milam wrote:
[color=blue]
> Krishanu Debnath wrote:
>[color=green]
>> Probably what you are asking ...
>>
>> strncpy(dest, cstring + offset, count);
>> dest[count] = '\0';
>>
>> assuming dest in large enough to hold 'count + 1' character.
>>
>> Krishanu
>>[/color]
>
> My favorite way of doing this is:
>
> strncpy( dest, cstring + offset, count )[count] = '\0';[/color]

It is best to avoid strncpy() completely. It isn't a "true" string
function as it *always* writes out exactly the number of characters
specified by the 3rd argument. This means that the result may not be null
termnated (hence the extra write you need to do) or it may end up writing
a whole load of unnecessary null characters after the string data. If you
want to do it in one statement you can use sprintf() or

*dest = '\0', strncat( dest, cstring + offset, count );

Lawrence

re: c equivilant to "copy"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

CBFalconer wrote:

[snip][color=blue]
> However you will get better and safer results by using strlcpy (and
> strlcat) as proposed by the BSD group. You can find an
> implementation, justification, and description at:
>
> <http://cbfalconer.home.att.net/download/strlcpy.zip>
>[/color]

Until this becomes standard one must not use it in ANSI/ISO C comforming
programs, as it intrudes upon the str*() namespace.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFB7BZS+hz2VlChukwRAkV4AJ9RSs/cdfx1vwnw9t64mGo6k3HYswCfYcdk
n+A4IQXI6M/7M66UM7ggeuE=
=bL30
-----END PGP SIGNATURE-----

re: c equivilant to "copy"

bd wrote:[color=blue]
> CBFalconer wrote:
>
> [snip][color=green]
>> However you will get better and safer results by using strlcpy
>> (and strlcat) as proposed by the BSD group. You can find an
>> implementation, justification, and description at:
>>
>> <http://cbfalconer.home.att.net/download/strlcpy.zip>[/color]
>
> Until this becomes standard one must not use it in ANSI/ISO C
> comforming programs, as it intrudes upon the str*() namespace.[/color]

If it creates a difficulty, rename the functions. You have the
complete source. In practice there will be no problem unless the
existing system already implements them.

--
"If you want to post a followup via groups.google.com, 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

re: c equivilant to "copy"

Chris Croughton <chris@keristor.net> writes:

[...]
[color=blue]
> Because of these faults, the functions strlcpy() and strlcat() were
> introduced in OpenBSD 2.4, and many of us hope that they will be
> incorporated into a future C standard revision. See
>
> http://www.courtesan.com/todd/papers/strlcpy.html
>
> for example (the functions are easy to write, or you can use the OpenBSD
> source under their Free Software licence).[/color]

That helps a lot, thanks!

--
William

re: c equivilant to "copy"

Wouldn't a function like this give you safety and NUL-termination?

char *mystrncpy(char *dest, const char *src, size_t size)
{
*dest = '\0';
return strncat(dest, src, size-1);
}

re: c equivilant to "copy"

jake1138 wrote:[color=blue]
>
> Wouldn't a function like this give you safety and NUL-termination?
>
> char *mystrncpy(char *dest, const char *src, size_t size)
> {
> *dest = '\0';
> return strncat(dest, src, size-1);
> }[/color]

no. Think about it.

--
"If you want to post a followup via groups.google.com, 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

re: c equivilant to "copy"

CBFalconer <cbfalconer@yahoo.com> wrote:
[color=blue]
> jake1138 wrote:[color=green]
> >
> > Wouldn't a function like this give you safety and NUL-termination?
> >
> > char *mystrncpy(char *dest, const char *src, size_t size)
> > {
> > *dest = '\0';
> > return strncat(dest, src, size-1);
> > }[/color]
>
> no. Think about it.[/color]

Ok, I've thought about it. Given

char s1[20];
char s2[]="abcdefghijklmnopqrstuvwxyz";

how is

mystrcpy(s1, s2, 20);

less safe than

strlcpy(s1, s2, 20);

and how is

strlcpy(s1, s2, 26);

safer than

strlcpy(s1, s2, 26);

Richard

re: c equivilant to "copy"

Richard Bos wrote:[color=blue]
> CBFalconer <cbfalconer@yahoo.com> wrote:[color=green]
>> jake1138 wrote:[color=darkred]
>>>
>>> Wouldn't a function like this give you safety and NUL-termination?
>>>
>>> char *mystrncpy(char *dest, const char *src, size_t size)
>>> {
>>> *dest = '\0';
>>> return strncat(dest, src, size-1);
>>> }[/color]
>>
>> no. Think about it.[/color]
>
> Ok, I've thought about it. Given
>
> char s1[20];
> char s2[]="abcdefghijklmnopqrstuvwxyz";
>
> how is
>
> mystrcpy(s1, s2, 20);
>
> less safe than
>
> strlcpy(s1, s2, 20);[/color]

mystrcpy leaves an unterminated string (no '\0') in s1, and returns
a pointer to s1, which will almost certainly lead to future
faults. strlcpy leaves a terminated string in s1, and returns 26
to indicate the size required. Since 26 >= 20 you know the output
was truncated.
[color=blue]
>
> and how is
>
> strlcpy(s1, s2, 26);
>
> safer than
>
> strlcpy(s1, s2, 26);[/color]

These are identical, and are lying to strlcpy about the space
available.

--
"If you want to post a followup via groups.google.com, 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

re: c equivilant to "copy"

CBFalconer wrote:[color=blue]
> Richard Bos wrote:[color=green]
> > CBFalconer <cbfalconer@yahoo.com> wrote:[color=darkred]
> >> jake1138 wrote:
> >>>
> >>> Wouldn't a function like this give you safety and[/color][/color][/color]
NUL-termination?[color=blue][color=green][color=darkred]
> >>>
> >>> char *mystrncpy(char *dest, const char *src, size_t size)
> >>> {
> >>> *dest = '\0';
> >>> return strncat(dest, src, size-1);
> >>> }
> >>
> >> no. Think about it.[/color]
> >
> > Ok, I've thought about it. Given
> >
> > char s1[20];
> > char s2[]="abcdefghijklmnopqrstuvwxyz";
> >
> > how is
> >
> > mystrcpy(s1, s2, 20);
> >
> > less safe than
> >
> > strlcpy(s1, s2, 20);[/color]
>
> mystrcpy leaves an unterminated string (no '\0') in s1, and returns
> a pointer to s1, which will almost certainly lead to future
> faults. strlcpy leaves a terminated string in s1, and returns 26
> to indicate the size required. Since 26 >= 20 you know the output
> was truncated.[/color]

I don't see how mystrncpy (it has an 'n' in it) will leave an
unterminated string. s1[0] is immediately set to '\0', then strncat
will write over that up to size-1 length then add a '\0' on the end.
I've tested this and it seems to work as expected. Please explain.

re: c equivilant to "copy"

Richard Bos wrote:[color=blue]
>
> CBFalconer <cbfalconer@yahoo.com> wrote:
>[color=green]
> > jake1138 wrote:[color=darkred]
> > >
> > > Wouldn't a function like this give you safety and NUL-termination?
> > >
> > > char *mystrncpy(char *dest, const char *src, size_t size)
> > > {
> > > *dest = '\0';
> > > return strncat(dest, src, size-1);
> > > }[/color]
> >
> > no. Think about it.[/color]
>
> Ok, I've thought about it. Given
>
> char s1[20];
> char s2[]="abcdefghijklmnopqrstuvwxyz";
>
> how is
>
> mystrcpy(s1, s2, 20);
>
> less safe than
>
> strlcpy(s1, s2, 20);[/color]


mystrcpy(s1, s2, 0);

isn't safe.

--
pete

re: c equivilant to "copy"

jake1138 wrote:[color=blue]
> CBFalconer wrote:[color=green]
>> Richard Bos wrote:[color=darkred]
>>> CBFalconer <cbfalconer@yahoo.com> wrote:
>>>> jake1138 wrote:
>>>>>
>>>>> Wouldn't a function like this give you safety and
>>>>> NUL-termination?
>>>>>
>>>>> char *mystrncpy(char *dest, const char *src, size_t size)
>>>>> {
>>>>> *dest = '\0';
>>>>> return strncat(dest, src, size-1);
>>>>> }
>>>>
>>>> no. Think about it.
>>>
>>> Ok, I've thought about it. Given
>>>
>>> char s1[20];
>>> char s2[]="abcdefghijklmnopqrstuvwxyz";
>>>
>>> how is
>>>
>>> mystrcpy(s1, s2, 20);
>>>
>>> less safe than
>>>
>>> strlcpy(s1, s2, 20);[/color]
>>
>> mystrcpy leaves an unterminated string (no '\0') in s1, and returns
>> a pointer to s1, which will almost certainly lead to future
>> faults. strlcpy leaves a terminated string in s1, and returns 26
>> to indicate the size required. Since 26 >= 20 you know the output
>> was truncated.[/color]
>
> I don't see how mystrncpy (it has an 'n' in it) will leave an
> unterminated string. s1[0] is immediately set to '\0', then strncat
> will write over that up to size-1 length then add a '\0' on the end.
> I've tested this and it seems to work as expected. Please explain.[/color]

Sorry, I was confusing the internal action of strncat with that of
strncpy, and I just looked it up. You were right about the
safety. You don't have the advantage of getting back the length
info that strlcpy/cat provide.

--
"If you want to post a followup via groups.google.com, 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

re: c equivilant to "copy"

In article <1106239100.695667.42820@f14g2000cwb.googlegroups. com>, "jake1138" <cooljake@gmail.com> writes:[color=blue]
> CBFalconer wrote:[color=green]
> > Richard Bos wrote:[color=darkred]
> > > CBFalconer <cbfalconer@yahoo.com> wrote:
> > >> jake1138 wrote:
> > >>>
> > >>> Wouldn't a function like this give you safety and NUL-termination?
> > >>>
> > >>> char *mystrncpy(char *dest, const char *src, size_t size)
> > >>> {
> > >>> *dest = '\0';
> > >>> return strncat(dest, src, size-1);
> > >>> }
> > >>
> > >> no. Think about it.
> > >[/color]
> > mystrcpy leaves an unterminated string (no '\0') in s1, and returns
> > a pointer to s1, which will almost certainly lead to future
> > faults. strlcpy leaves a terminated string in s1, and returns 26
> > to indicate the size required. Since 26 >= 20 you know the output
> > was truncated.[/color]
>
> I don't see how mystrncpy (it has an 'n' in it) will leave an
> unterminated string.[/color]

In the normal case it won't. Perhaps Chuck is thinking that strncat
has the same brain-dead behavior as strncpy when the copy length is
smaller than the source length; it doesn't. (It has other
infelicities.)

However, mystrncpy still has problems:

- As Chuck noted, it doesn't tell you if truncation occurred, unlike
strlcpy. This isn't a bug, but one could argue that it makes
mystrncpy inferior to strlcpy. (Some prefer returning the
destination string for "chaining" purposes.)

- If size == 0, you're in trouble.

- If I were writing "safe" versions of the string-handling functions,
you can be damn sure that I'd have them do something sensible with
null arguments.

--
Michael Wojcik michael.wojcik@microfocus.com

Pocket #9: A complete "artificial glen" with rocks, and artificial moon,
and forester's station. Excellent for achieving the effect of the
sublime without going out-of-doors. -- Joe Green

re: c equivilant to "copy"

Michael Wojcik wrote:[color=blue]
> In article <1106239100.695667.42820@f14g2000cwb.googlegroups. com>,[/color]
"jake1138" <cooljake@gmail.com> writes:[color=blue][color=green]
> > CBFalconer wrote:[color=darkred]
> > > Richard Bos wrote:
> > > > CBFalconer <cbfalconer@yahoo.com> wrote:
> > > >> jake1138 wrote:
> > > >>>
> > > >>> Wouldn't a function like this give you safety and[/color][/color][/color]
NUL-termination?[color=blue][color=green][color=darkred]
> > > >>>
> > > >>> char *mystrncpy(char *dest, const char *src, size_t size)
> > > >>> {
> > > >>> *dest = '\0';
> > > >>> return strncat(dest, src, size-1);
> > > >>> }
> > > >>
> > > >> no. Think about it.
> > > >
> > > mystrcpy leaves an unterminated string (no '\0') in s1, and[/color][/color][/color]
returns[color=blue][color=green][color=darkred]
> > > a pointer to s1, which will almost certainly lead to future
> > > faults. strlcpy leaves a terminated string in s1, and returns 26
> > > to indicate the size required. Since 26 >= 20 you know the[/color][/color][/color]
output[color=blue][color=green][color=darkred]
> > > was truncated.[/color]
> >
> > I don't see how mystrncpy (it has an 'n' in it) will leave an
> > unterminated string.[/color]
>
> In the normal case it won't. Perhaps Chuck is thinking that strncat
> has the same brain-dead behavior as strncpy when the copy length is
> smaller than the source length; it doesn't. (It has other
> infelicities.)
>
> However, mystrncpy still has problems:
>
> - As Chuck noted, it doesn't tell you if truncation occurred, unlike
> strlcpy. This isn't a bug, but one could argue that it makes
> mystrncpy inferior to strlcpy. (Some prefer returning the
> destination string for "chaining" purposes.)
>
> - If size == 0, you're in trouble.
>
> - If I were writing "safe" versions of the string-handling functions,
> you can be damn sure that I'd have them do something sensible with
> null arguments.
>
> --
> Michael Wojcik michael.wojcik@microfocus.com
>
> Pocket #9: A complete "artificial glen" with rocks, and artificial[/color]
moon,[color=blue]
> and forester's station. Excellent for achieving the effect of the
> sublime without going out-of-doors. -- Joe Green[/color]

All good points, from everyone. I didn't think about size==0, that
should be checked. Also, to make this work like strlcpy, I'd have to
use strlen, which would make it slower. Or do the copy manually with a
count, which I assume strlcpy does. I'll take a look at the
implementation of strlcpy.

re: c equivilant to "copy"

mwojcik@newsguy.com (Michael Wojcik) wrote:
[color=blue]
> - If I were writing "safe" versions of the string-handling functions,
> you can be damn sure that I'd have them do something sensible with
> null arguments.[/color]

strlcpy() silently and transparently covers up the bug of using a null
pointer as if it were a string - I wouldn't call that "something
sensible". I'd rather catch my bugs now rather than when the program has
gone into production.

Richard

re: c equivilant to "copy"

Richard Bos wrote:[color=blue]
> mwojcik@newsguy.com (Michael Wojcik) wrote:
>[color=green]
>> - If I were writing "safe" versions of the string-handling
>> functions, you can be damn sure that I'd have them do
>> something sensible with null arguments.[/color]
>
> strlcpy() silently and transparently covers up the bug of using
> a null pointer as if it were a string - I wouldn't call that
> "something sensible". I'd rather catch my bugs now rather than
> when the program has gone into production.[/color]

That is not necessarily so. It does apply to my implementation,
and is so documented therein. My source is easily augmented to
produce UB in that case.

This sort of thing is not uncommon, and leads to long
non-productive arguments. When you have the source (mine has been
put in public domain) you can adjust to suit your personal
preferance. In general it is harder to allow for suitable action
on such a parameter value, here, IIRC, it was trivially easy. My
source is at:

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

and has some minor errors in the readme, such as compile flags.

--
"If you want to post a followup via groups.google.com, 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

re: c equivilant to "copy"

In article <41f675fc.92332538@news.individual.net>, rlb@hoekstra-uitgeverij.nl (Richard Bos) writes:[color=blue]
> mwojcik@newsguy.com (Michael Wojcik) wrote:
>[color=green]
> > - If I were writing "safe" versions of the string-handling functions,
> > you can be damn sure that I'd have them do something sensible with
> > null arguments.[/color]
>
> strlcpy() silently and transparently covers up the bug of using a null
> pointer as if it were a string - I wouldn't call that "something
> sensible". I'd rather catch my bugs now rather than when the program has
> gone into production.[/color]

It's only a bug if it's a violation of the design. If by design
my program uses null character pointers and empty strings
interchangeably in some contexts, then there's nothing wrong with
the behavior of strlcpy in those contexts.

And, of course, "something sensible" could be aborting. What's not
sensible is UB. I can accept that the standard left behavior
undefined for strcpy et al, because that could be useful for
optimized implementations, but if I'm writing my own functions I
check parameters.

Frankly, it's exceedingly rare that one of the functions in any of
my current projects flags an invalid parameter - that indicates a
logic error in the caller. But it gets handled cleanly, and the
program - which is certainly doing other things, unrelated to the
error - continues running. That's far better than UB.

--
Michael Wojcik michael.wojcik@microfocus.com

Duck: No secret what's worth a hoot ought to be kept quiet.
Pogo: Secrets is usually perty doggone fascinatin'.
Duck: Egg-zackly ... it's completely illogical to keep a secret secret.
Pogo: An' unfair. -- Walt Kelly