469,133 Members | 1,417 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,133 developers. It's quick & easy.

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!
Nov 14 '05 #1
27 2039
Shagy wrote:
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!

Probably what you are asking ...

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

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

Krishanu

Nov 14 '05 #2
Krishanu Debnath wrote:

Shagy wrote:
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.
Probably what you are asking ...

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

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


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 */
Nov 14 '05 #3
Thanks!!!

Both examples work great!!!

Shagy

"Shagy" <no*****@noemail.com> wrote in message
news:cs**********@nic.grnet.gr...
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!

Nov 14 '05 #4
Shagy wrote:

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.


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
Nov 14 '05 #5
On Thu, 13 Jan 2005 16:57:47 +0000, CBFalconer wrote:
Shagy wrote:

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.
char *strncpy(char *dest, const char *src, size_t max);


But be aware that strncpy() is a dangerous function for the unwary, it
doesn't always null terminate the destination string. strncat() is better.
is available in <strings.h>. The corresponding usage would be:
That would be <string.h>
dest = strncpy(dest, src + offset, max);

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

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


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
Nov 14 '05 #6
Krishanu Debnath wrote:
Probably what you are asking ...

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

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

Krishanu


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.
================================================== ===========
Nov 14 '05 #7
Stan Milam <st*****@swbell.net> writes:
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.


cool. ;-)

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

--
William
Nov 14 '05 #8
On Mon, 17 Jan 2005 16:01:24 +0800, William Xuuu
<wi**********@163.com> wrote:
Stan Milam <st*****@swbell.net> writes:
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.
cool. ;-)

Can someone give an example that strncpy() would be safer than strcpy() ?


#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.)
Should we never use strcpy() ?


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
Nov 14 '05 #9
Chris Croughton wrote:
.... snip ...
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).


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
Nov 14 '05 #10
On Mon, 17 Jan 2005 14:33:37 GMT, CBFalconer
<cb********@yahoo.com> wrote:
Chris Croughton wrote:
... snip ...

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).


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>


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.
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).


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
Nov 14 '05 #11
Stan Milam <st*****@swbell.net> wrote:
Krishanu Debnath wrote:
strncpy(dest, cstring + offset, count);
dest[count] = '\0';

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


My favorite way of doing this is:

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


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

Richard
Nov 14 '05 #12
On Sat, 15 Jan 2005 00:41:47 +0000, Stan Milam wrote:
Krishanu Debnath wrote:
Probably what you are asking ...

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

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

Krishanu


My favorite way of doing this is:

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


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
Nov 14 '05 #13
bd
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

CBFalconer wrote:

[snip]
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>


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-----
Nov 14 '05 #14
bd wrote:
CBFalconer wrote:

[snip]
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>


Until this becomes standard one must not use it in ANSI/ISO C
comforming programs, as it intrudes upon the str*() namespace.


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
Nov 14 '05 #15
Chris Croughton <ch***@keristor.net> writes:

[...]
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).


That helps a lot, thanks!

--
William
Nov 14 '05 #16
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);
}

Nov 14 '05 #17
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.

--
"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
Nov 14 '05 #18
CBFalconer <cb********@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);

and how is

strlcpy(s1, s2, 26);

safer than

strlcpy(s1, s2, 26);

Richard
Nov 14 '05 #19
Richard Bos wrote:
CBFalconer <cb********@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);


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.

and how is

strlcpy(s1, s2, 26);

safer than

strlcpy(s1, s2, 26);


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
Nov 14 '05 #20

CBFalconer wrote:
Richard Bos wrote:
CBFalconer <cb********@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);


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.


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.

Nov 14 '05 #21
Richard Bos wrote:

CBFalconer <cb********@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);

mystrcpy(s1, s2, 0);

isn't safe.

--
pete
Nov 14 '05 #22
jake1138 wrote:
CBFalconer wrote:
Richard Bos wrote:
CBFalconer <cb********@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);


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.


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.


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
Nov 14 '05 #23

In article <11*********************@f14g2000cwb.googlegroups. com>, "jake1138" <co******@gmail.com> writes:
CBFalconer wrote:
Richard Bos wrote:
CBFalconer <cb********@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.

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.


I don't see how mystrncpy (it has an 'n' in it) will leave an
unterminated string.


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 mi************@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
Nov 14 '05 #24

Michael Wojcik wrote:
In article <11*********************@f14g2000cwb.googlegroups. com>, "jake1138" <co******@gmail.com> writes:
CBFalconer wrote:
Richard Bos wrote:
> CBFalconer <cb********@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.
>
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.


I don't see how mystrncpy (it has an 'n' in it) will leave an
unterminated string.


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 mi************@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


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.

Nov 14 '05 #25
mw*****@newsguy.com (Michael Wojcik) wrote:
- 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.


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
Nov 14 '05 #26
Richard Bos wrote:
mw*****@newsguy.com (Michael Wojcik) wrote:
- 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.


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.


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
Nov 14 '05 #27

In article <41***************@news.individual.net>, rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
mw*****@newsguy.com (Michael Wojcik) wrote:
- 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.


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.


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 mi************@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
Nov 14 '05 #28

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Nick Jacobson | last post: by
4 posts views Thread by Don Wash | last post: by
1 post views Thread by Russell Warren | last post: by
3 posts views Thread by Jess | last post: by
1 post views Thread by Mortomer39 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.