memcpy/memmove

[Christopher Benson-Manica]

(if this is a FAQ or in K&R2, I didn't find it)

What parameters (if any) may be 0 or NULL? IOW, which of the following
statements are guaranteed to produce well-defined behavior?

char src[10];
char dst[10];

memcpy( dst, src, 1 );
memcpy( NULL, src, 1 );
memcpy( dst, src, 0 );
memcpy( NULL, src, 0 );
memcpy( dst, NULL, 1 );
memcpy( NULL, NULL, 1 );
memcpy( dst, NULL, 0 );
memcpy( NULL, NULL, 0 );

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Thomas Matthews]

Christopher Benson-Manica wrote:

(if this is a FAQ or in K&R2, I didn't find it)

What parameters (if any) may be 0 or NULL? IOW, which of the following
statements are guaranteed to produce well-defined behavior?

char src[10];
char dst[10];

memcpy( dst, src, 1 );
memcpy( NULL, src, 1 );
memcpy( dst, src, 0 );
memcpy( NULL, src, 0 );
memcpy( dst, NULL, 1 );
memcpy( NULL, NULL, 1 );
memcpy( dst, NULL, 0 );
memcpy( NULL, NULL, 0 );

According to my research (I suggest you search the newsgroups),
any argument can be NULL. However, if the destination or
source are NULL or the quantity is null, nothing happens.
--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

[Simon Biber]

"Christopher Benson-Manica" <at***@nospam.cyberspace.org> wrote:

What parameters (if any) may be 0 or NULL? IOW, which of the
following statements are guaranteed to produce well-defined
behavior?

char src[10];
char dst[10];

memcpy( dst, src, 1 );
Defined behaviour: One byte is copied from src to dest.
memcpy( dst, src, 0 );
Defined behaviour: no characters are copied.
memcpy( NULL, src, 1 );
memcpy( NULL, src, 0 );
memcpy( dst, NULL, 1 );
memcpy( NULL, NULL, 1 );
memcpy( dst, NULL, 0 );
memcpy( NULL, NULL, 0 );

All six have undefined behaviour: both pointers must be valid
pointers even if the number of characters to copy is zero.

C99 7.21.1#2 "Where an argument declared as size_t n specifies
the length of the array for a function, n can have the value
zero on a call to that function. Unless explicitly stated
otherwise in the description of a particular function in this
subclause, pointer arguments on such a call shall still have
valid values, as described in 7.1.4. On such a call, a
function that locates a character finds no occurrence, a
function that compares two character sequences returns zero,
and a function that copies characters copies zero characters."

--
Simon.

[Christopher Benson-Manica]

Simon Biber <ne**@ralminnospam.cc> spoke thus:

All six have undefined behaviour: both pointers must be valid
pointers even if the number of characters to copy is zero. C99 7.21.1#2 (trimmed)

Thank you. Now, if only K&R2, my other C book, or my friendly man page had
said as much...

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Irrwahn Grausewitz]

Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:

Simon Biber <ne**@ralminnospam.cc> spoke thus:

All six have undefined behaviour: both pointers must be valid
pointers even if the number of characters to copy is zero.

C99 7.21.1#2 (trimmed)

Thank you. Now, if only K&R2, my other C book, or my friendly man page had
said as much...

That's where a copy of the Standard comes in handy. If you don't
want to buy (for whatever reasons) a copy of the C99 Standard, there
is still a public draft available at:

http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/

HTH
Regards
--
Irrwahn
(ir*******@freenet.de)

[Irrwahn Grausewitz]

Thomas Matthews <Th**********************@sbcglobal.net> wrote:

Christopher Benson-Manica wrote:

(if this is a FAQ or in K&R2, I didn't find it)

What parameters (if any) may be 0 or NULL? IOW, which of the following
statements are guaranteed to produce well-defined behavior?

char src[10];
char dst[10];

memcpy( dst, src, 1 );
memcpy( NULL, src, 1 );
memcpy( dst, src, 0 );
memcpy( NULL, src, 0 );
memcpy( dst, NULL, 1 );
memcpy( NULL, NULL, 1 );
memcpy( dst, NULL, 0 );
memcpy( NULL, NULL, 0 );

According to my research (I suggest you search the newsgroups),
any argument can be NULL.

Not so. I suggest you search the Standard. ;-)

Regards
--
Irrwahn
(ir*******@freenet.de)

[Dan Pop]

In <ms********************************@4ax.com> Irrwahn Grausewitz <ir*******@freenet.de> writes:

Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:

Simon Biber <ne**@ralminnospam.cc> spoke thus:

> All six have undefined behaviour: both pointers must be valid
> pointers even if the number of characters to copy is zero.

> C99 7.21.1#2 (trimmed)

Thank you. Now, if only K&R2, my other C book, or my friendly man page had
said as much...

That's where a copy of the Standard comes in handy.

Not so. It is enough to engage your brain. The only non-obvious cases
are those where the byte count is 0: because no byte gets copied, it is
not obvious if null pointers are allowed. OTOH, these are purely
artificial cases, with no relevance in practice. Even C90 didn't
cover them, it was its TC1 that addressed the issue.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Irrwahn Grausewitz]

Da*****@cern.ch (Dan Pop) wrote:

In <ms********************************@4ax.com> Irrwahn Grausewitz <ir*******@freenet.de> writes:

Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:

Simon Biber <ne**@ralminnospam.cc> spoke thus:

> All six have undefined behaviour: both pointers must be valid
> pointers even if the number of characters to copy is zero.

> C99 7.21.1#2 (trimmed)

Thank you. Now, if only K&R2, my other C book, or my friendly man page had
said as much...
That's where a copy of the Standard comes in handy.

Not so. It is enough to engage your brain. The only non-obvious cases
are those where the byte count is 0: because no byte gets copied, it is
not obvious if null pointers are allowed.

And how should one know about this facts from only engaging one's
brain? We're not all Dan Pops, y'know... ;-)
OTOH, these are purely
artificial cases, with no relevance in practice.
Sorry, I have to disagree. The memcpy function et al. might well have
been designed to accept NULL arguments (resulting in a no-op), for the
very same reason that free(NULL); is well-defined.
Even C90 didn't
cover them, it was its TC1 that addressed the issue.

And there was a reason for it, I suspect.

Regards
--
Irrwahn
(ir*******@freenet.de)

[Alex]

Irrwahn Grausewitz <ir*******@freenet.de> wrote:

Da*****@cern.ch (Dan Pop) wrote:

<snip>

Not so. It is enough to engage your brain. The only non-obvious cases
are those where the byte count is 0: because no byte gets copied, it is
not obvious if null pointers are allowed. And how should one know about this facts from only engaging one's
brain? We're not all Dan Pops, y'know... ;-) OTOH, these are purely
artificial cases, with no relevance in practice.

Sorry, I have to disagree. The memcpy function et al. might well have
been designed to accept NULL arguments (resulting in a no-op), for the
very same reason that free(NULL); is well-defined.

free(NULL) is an exception. It is really nothing more than a pragmatic
hack.

What possible behavior can you expect from copying 1 or more bytes
from or to NULL?

Dan is right, the only vagueness is in the case of the count being 0,
hence making it seem plausible that copying 0 bytes from NULL or to
NULL is allowed. Even then, can you think of a case where this would
be desirable?

Alex

[Irrwahn Grausewitz]

Alex <al*******@hotmail.com> wrote:

Irrwahn Grausewitz <ir*******@freenet.de> wrote:

Da*****@cern.ch (Dan Pop) wrote:

<snip>

Not so. It is enough to engage your brain. The only non-obvious cases
are those where the byte count is 0: because no byte gets copied, it is
not obvious if null pointers are allowed.

And how should one know about this facts from only engaging one's
brain? We're not all Dan Pops, y'know... ;-)

OTOH, these are purely
artificial cases, with no relevance in practice.

Sorry, I have to disagree. The memcpy function et al. might well have
been designed to accept NULL arguments (resulting in a no-op), for the
very same reason that free(NULL); is well-defined.

free(NULL) is an exception. It is really nothing more than a pragmatic
hack.

What possible behavior can you expect from copying 1 or more bytes
from or to NULL?

As stated above: a no-op, like free(NULL), the rationale behind it
being to reduce the need for special-case coding.
Dan is right, the only vagueness is in the case of the count being 0,
hence making it seem plausible that copying 0 bytes from NULL or to
NULL is allowed. Even then, can you think of a case where this would
be desirable?

I'm not even sure I could come up with a good example where copying
0 bytes is very useful. But still: the standard committee /could/
have defined the behaviour for the first or second parameter of memcpy
set to NULL just as it did for the third parameter set to 0. Without
having read the corresponding section in the standard nobody can tell
what is defined and what not, just "by engaging one's brain" as Dan
said, which was the point I tried to make.

Regards
--
Irrwahn
(ir*******@freenet.de)

[Simon Biber]

"Irrwahn Grausewitz" <ir*******@freenet.de> wrote:

As stated above: a no-op, like free(NULL), the rationale behind it
being to reduce the need for special-case coding.

It just moves the special case coding from the user code into the
library function.

Some library functions, like free, are quite complicated and slow
to execute, so an added test for NULL won't make much difference.
However, some library functions might suffer significantly in
speed or complexity if they had to be resilient to invalid input.

--
Simon.

[Christian Bau]

In article <bo*************@ID-190529.news.uni-berlin.de>,
Alex <al*******@hotmail.com> wrote:

Irrwahn Grausewitz <ir*******@freenet.de> wrote:

Da*****@cern.ch (Dan Pop) wrote:

<snip>

Not so. It is enough to engage your brain. The only non-obvious cases
are those where the byte count is 0: because no byte gets copied, it is
not obvious if null pointers are allowed.

And how should one know about this facts from only engaging one's
brain? We're not all Dan Pops, y'know... ;-)

OTOH, these are purely
artificial cases, with no relevance in practice.

Sorry, I have to disagree. The memcpy function et al. might well have
been designed to accept NULL arguments (resulting in a no-op), for the
very same reason that free(NULL); is well-defined.

free(NULL) is an exception. It is really nothing more than a pragmatic
hack.

What possible behavior can you expect from copying 1 or more bytes
from or to NULL?

Lets say I design a brand new language named "D", which has a standard
library and standard library functions that have the same names and
arguments as those in C. The definition of the semantics of these
functions is done in the way that _I_ prefer and which _I_ think is
useful.

How would you know without careful reading of the "D" standard what the
behavior of memcpy (NULL, src, 1) is? In C, it is likely to cause a
crash. I can imagine a lot more useful behaviors.
Dan is right, the only vagueness is in the case of the count being 0,
hence making it seem plausible that copying 0 bytes from NULL or to
NULL is allowed. Even then, can you think of a case where this would
be desirable?

Alex

[Irrwahn Grausewitz]

"Simon Biber" <ne**@ralminNOSPAM.cc> wrote:

"Irrwahn Grausewitz" <ir*******@freenet.de> wrote:

As stated above: a no-op, like free(NULL), the rationale behind it
being to reduce the need for special-case coding.
It just moves the special case coding from the user code into the
library function.

Obviously.
Some library functions, like free, are quite complicated and slow
to execute, so an added test for NULL won't make much difference.
However, some library functions might suffer significantly in
speed or complexity if they had to be resilient to invalid input.

True, but nevertheless, they /could/ be designed that way. And still,
reasoning cannot always replace a look in the standard or a good
library reference (unless you are Dan Pop, of course ;-)), especially
when you are a novice. Which was the only point I wanted to make,
anyway.

Regards
--
Irrwahn
(ir*******@freenet.de)

[Christopher Benson-Manica]

Irrwahn Grausewitz <ir*******@freenet.de> spoke thus:

True, but nevertheless, they /could/ be designed that way. And still,
reasoning cannot always replace a look in the standard or a good
library reference (unless you are Dan Pop, of course ;-)), especially
when you are a novice. Which was the only point I wanted to make,
anyway.

Which I do appreciate :) I didn't necessarily *expect* any but the first two
cases to be 100% legal, but since no reference I had access to specified what
to expect, I had to ask...

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Dan Pop]

In <ch*********************************@slb-newsm1.svr.pol.co.uk> Christian Bau <ch***********@cbau.freeserve.co.uk> writes:

Lets say I design a brand new language named "D", which has a standard
library and standard library functions that have the same names and
arguments as those in C. The definition of the semantics of these
functions is done in the way that _I_ prefer and which _I_ think is
useful.

How would you know without careful reading of the "D" standard what the
behavior of memcpy (NULL, src, 1) is?
The good question is why would you care about the exact behaviour of
memcpy(NULL, src, 1)? Does such a call make any sense?
In C, it is likely to cause a
crash. I can imagine a lot more useful behaviors.

I cannot. If you do this, there is something broken in the logic of your
program. Not letting it continue its execution is a big favour to both
the developer and the user. Too bad C does not *enforce* this behaviour.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Christian Bau]

In article <bp***********@sunnews.cern.ch>, Da*****@cern.ch (Dan Pop)
wrote:

In <ch*********************************@slb-newsm1.svr.pol.co.uk> Christian
Bau <ch***********@cbau.freeserve.co.uk> writes:

Lets say I design a brand new language named "D", which has a standard
library and standard library functions that have the same names and
arguments as those in C. The definition of the semantics of these
functions is done in the way that _I_ prefer and which _I_ think is
useful.

How would you know without careful reading of the "D" standard what the
behavior of memcpy (NULL, src, 1) is?

The good question is why would you care about the exact behaviour of
memcpy(NULL, src, 1)? Does such a call make any sense?

It would be good to know what happens when the programmer writes a
function call that doesn't make sense.

In C, it is likely to cause a
crash. I can imagine a lot more useful behaviors.

I cannot. If you do this, there is something broken in the logic of your
program. Not letting it continue its execution is a big favour to both
the developer and the user. Too bad C does not *enforce* this behaviour.

Here is a more useful behavior than crashing: An alert pops up on the
screen, saying "this program tried to do something nasty. The code is in
file xxx, line yyy. Press Continue to continue the program without doing
the action. Press Quit to exit the program. ".

Consider Java-like behavior: An exception is thrown, which gives the
programmer a chance to handle the situation. Much more useful than
crashing.

[Dan Pop]

In <ch*********************************@slb-newsm1.svr.pol.co.uk> Christian Bau <ch***********@cbau.freeserve.co.uk> writes:

In article <bp***********@sunnews.cern.ch>, Da*****@cern.ch (Dan Pop)
wrote:

In <ch*********************************@slb-newsm1.svr.pol.co.uk> Christian
Bau <ch***********@cbau.freeserve.co.uk> writes:

>Lets say I design a brand new language named "D", which has a standard
>library and standard library functions that have the same names and
>arguments as those in C. The definition of the semantics of these
>functions is done in the way that _I_ prefer and which _I_ think is
>useful.
>
>How would you know without careful reading of the "D" standard what the
>behavior of memcpy (NULL, src, 1) is?
The good question is why would you care about the exact behaviour of
memcpy(NULL, src, 1)? Does such a call make any sense?

It would be good to know what happens when the programmer writes a
function call that doesn't make sense.

What for? The C standard doesn't say what happens and this has never
been a problem for me, in practice.

>In C, it is likely to cause a
>crash. I can imagine a lot more useful behaviors.

I cannot. If you do this, there is something broken in the logic of your
program. Not letting it continue its execution is a big favour to both
the developer and the user. Too bad C does not *enforce* this behaviour.

Here is a more useful behavior than crashing: An alert pops up on the
screen, saying "this program tried to do something nasty. The code is in
file xxx, line yyy. Press Continue to continue the program without doing
the action. Press Quit to exit the program. ".

How is this helpful in any way to the *user*? Does he have to toss a
coin to decide whether to press Continue or Quit?

How is it helpful to the programmer, without having access to the
program state, so that he can trace the origin of the problem?

Crashing the program, the Unix way, is by far more helpful: not only can
you trivially get the file and line information, you have also access to
the program state at the moment the nasty thing happened.
Consider Java-like behavior: An exception is thrown, which gives the
programmer a chance to handle the situation. Much more useful than
crashing.

Crashing has always given me not only a chance, but the best opportunity
to investigate the problem and quickly discover its origin.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Alan Balmer]

On Thu, 13 Nov 2003 23:00:55 +0000, Christian Bau
<ch***********@cbau.freeserve.co.uk> wrote:

Here is a more useful behavior than crashing: An alert pops up on the
screen, saying "this program tried to do something nasty. The code is in
file xxx, line yyy. Press Continue to continue the program without doing
the action. Press Quit to exit the program. ".

Assuming there is a screen, assuming the implementation supports
"pop-up" alerts, assuming the program always runs attended, assuming
there's an input capability, assuming ...

No. If the parameters can potentially be NULL, check them before the
call.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Christian Bau]

In article <en********************************@4ax.com>,
Alan Balmer <al******@att.net> wrote:

On Thu, 13 Nov 2003 23:00:55 +0000, Christian Bau
<ch***********@cbau.freeserve.co.uk> wrote:

Here is a more useful behavior than crashing: An alert pops up on the
screen, saying "this program tried to do something nasty. The code is in
file xxx, line yyy. Press Continue to continue the program without doing
the action. Press Quit to exit the program. ".
Assuming there is a screen, assuming the implementation supports
"pop-up" alerts, assuming the program always runs attended, assuming
there's an input capability, assuming ...

Plenty of implementations where all these are available (running
attended is no requirement).
No. If the parameters can potentially be NULL, check them before the
call.

You mean people should just write bug-free code? Yes, that's a very
simple solution to all problems. No buffer overruns anymore, just write
bug-free code.

[Alan Balmer]

On Mon, 17 Nov 2003 22:33:13 +0000, Christian Bau
<ch***********@cbau.freeserve.co.uk> wrote:

In article <en********************************@4ax.com>,
Alan Balmer <al******@att.net> wrote:

On Thu, 13 Nov 2003 23:00:55 +0000, Christian Bau
<ch***********@cbau.freeserve.co.uk> wrote:

>Here is a more useful behavior than crashing: An alert pops up on the
>screen, saying "this program tried to do something nasty. The code is in
>file xxx, line yyy. Press Continue to continue the program without doing
>the action. Press Quit to exit the program. ".
Assuming there is a screen, assuming the implementation supports
"pop-up" alerts, assuming the program always runs attended, assuming
there's an input capability, assuming ...

Plenty of implementations where all these are available (running
attended is no requirement).

Unfortunately for your suggestion, standard C is also expected to work
on the implementations where one or more of these features are not
available.

If the program is unattended, who's going to push the "Continue" and
"Quit" buttons?

No. If the parameters can potentially be NULL, check them before the
call.

You mean people should just write bug-free code? Yes, that's a very
simple solution to all problems. No buffer overruns anymore, just write
bug-free code.

That's at least as realistic a goal as providing a language and
implementation which will detect all possible programmer errors.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Christian Bau]

In article <ko********************************@4ax.com>,
Alan Balmer <al******@att.net> wrote:

Unfortunately for your suggestion, standard C is also expected to work
on the implementations where one or more of these features are not
available.

You see, you would have to go way back to the start of the thread to
make any sense of this. The question at the start of the thread was what
properties of (for example) memcpy could be deduced by thinking about it
and what properties you could only know by looking at the C Standard.

I suggested a hypothetical language named D that happened to have a
function in the D Standard Library named "memcpy" for which _I_ had
written the definition. In that hypothetical language memcpy (NULL, src,
1) would have _defined behavior_ as described above. So your comment is
completely out of place and missing the context of the thread, due to
extensive snipping.

So the fact that memcpy (NULL, src, 1) produces undefined behavior in C
is not for some inherent reason, or for some deeply founded necessity,
it is because the people responsibly for the C Standard decided that it
would be so.

[Irrwahn Grausewitz]

Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:

I suggested a hypothetical language named D that happened to have a
function in the D Standard Library named "memcpy" for which _I_ had
written the definition. In that hypothetical language memcpy (NULL, src,
1) would have _defined behavior_ as described above.

<OT>

Sidenote: There is a non-hypothetical language named D currently
under development; for more information take a look at:

http://www.digitalmars.com/d/index.html

I don't know about the semantics of memcpy, or if such a function even
exists in D, though.

;-D

</OT>

Regards
--
Irrwahn
(ir*******@freenet.de)

[Alan Balmer]

On Tue, 18 Nov 2003 08:52:30 +0000, Christian Bau
<ch***********@cbau.freeserve.co.uk> wrote:

In article <ko********************************@4ax.com>,
Alan Balmer <al******@att.net> wrote:

Unfortunately for your suggestion, standard C is also expected to work
on the implementations where one or more of these features are not
available.
You see, you would have to go way back to the start of the thread to
make any sense of this. The question at the start of the thread was what
properties of (for example) memcpy could be deduced by thinking about it
and what properties you could only know by looking at the C Standard.

Um, no - to make sense of your remarks, I need to go back to the
middle of the thread, where you introduced the "D" language (without
any reference to Walter Bright, btw), which you apparently envisioned
as some kind of limited platform, gui-centric language, although those
characteristics weren't mentioned at the time, only later when you
discussed the error handling. That's what was out of context, having
nothing to do with the behavior of C or the reasons for that behavior.
So the fact that memcpy (NULL, src, 1) produces undefined behavior in C
is not for some inherent reason, or for some deeply founded necessity,
it is because the people responsibly for the C Standard decided that it
would be so.

More likely because they decided that defining the behavior would have
little point, and would most likely break existing compilers, if not
code.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Richard Bos]

Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:

In article <en********************************@4ax.com>,
Alan Balmer <al******@att.net> wrote:

No. If the parameters can potentially be NULL, check them before the
call.

You mean people should just write bug-free code? Yes, that's a very
simple solution to all problems. No buffer overruns anymore, just write
bug-free code.

Well, actually, in this case it _is_ pretty simple. Bugs can be very
elusive, but buffer overruns are among the easiest to find. If everybody
just checked their buffers before smashing all over memory, we wouldn't
have half the computer problems we have now. <stern look in the
direction of Redmond, WA>

Richard

[Christian Bau]

In article <gb********************************@4ax.com>,
Alan Balmer <al******@att.net> wrote:

So the fact that memcpy (NULL, src, 1) produces undefined behavior in C
is not for some inherent reason, or for some deeply founded necessity,
it is because the people responsibly for the C Standard decided that it
would be so.

More likely because they decided that defining the behavior would have
little point, and would most likely break existing compilers, if not
code.

The first one is highly debatable, the second one is irrelevant to the
discussion.

If for example strcpy (dst, src) had defined behavior whenever the dst
argument is an actual array of char, and src a pointer to a string with
strlen (src) >= sizeof (dst), then the world would be a much better
place.

[Lorenzo J. Lucchini]

Alan Balmer <al******@att.net> wrote in message news:<gb********************************@4ax.com>. ..

On Tue, 18 Nov 2003 08:52:30 +0000, Christian Bau
<ch***********@cbau.freeserve.co.uk> wrote:

[snip]

So the fact that memcpy (NULL, src, 1) produces undefined behavior in C
is not for some inherent reason, or for some deeply founded necessity,
it is because the people responsibly for the C Standard decided that it
would be so.

More likely because they decided that defining the behavior would have
little point, and would most likely break existing compilers, if not
code.

You said it. They *decided*. Definition 1b of 'decide' in m-w.com
goes:
"to select as a course of action"
This seems to imply that whenever a decision is made, another curse of
action (different from the one that was decided) could have been
selected.

So the C standard committee *decided* that memcpy() should behave that
way *instead of* behaving differently, and you can't know before
looking at the documents they produced.

After all, if you could accurately infer everything about the C
language from a couple of basic principles (like "function calls that
make no sense are undefined" and "it makes no logical sense to copy
to/from nothing"), then why didn't the committee just publish a short
document comparable to the Rationale instead of going into great
length specifying almost every subtlety in the Standard?
by LjL
lj****@tiscali.it

[CBFalconer]

Christian Bau wrote:

.... snip ...
If for example strcpy (dst, src) had defined behavior whenever
the dst argument is an actual array of char, and src a pointer
to a string with strlen (src) >= sizeof (dst), then the world
would be a much better place.

Why do you want to limit strcpy to strings shorter than the size
of a pointer? In other words, those semantics are unimplementable
with the existing definition of a C string.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Dan Pop]

In <1f**************************@posting.google.com > lj****@tiscalinet.it (Lorenzo J. Lucchini) writes:

Alan Balmer <al******@att.net> wrote in message news:<gb********************************@4ax.com>. ..

On Tue, 18 Nov 2003 08:52:30 +0000, Christian Bau
<ch***********@cbau.freeserve.co.uk> wrote:

> [snip]
>
>So the fact that memcpy (NULL, src, 1) produces undefined behavior in C
>is not for some inherent reason, or for some deeply founded necessity,
>it is because the people responsibly for the C Standard decided that it
>would be so.

More likely because they decided that defining the behavior would have
little point, and would most likely break existing compilers, if not
code.

You said it. They *decided*. Definition 1b of 'decide' in m-w.com
goes:
"to select as a course of action"
This seems to imply that whenever a decision is made, another curse of
action (different from the one that was decided) could have been
selected.

So the C standard committee *decided* that memcpy() should behave that
way *instead of* behaving differently, and you can't know before
looking at the documents they produced.

The *good* question is why would you care about what they decided for a
memcpy call that doesn't make any sense in the first place?

If something doesn't make sense, it is safer to avoid using it, even if
you know what the standard says about its behaviour. As a concrete
example, consider free(NULL), which doesn't make any sense a priori, but
whose behaviour is well defined by the standard. People taking advantage
of the standard specification had the surprise to see their programs
crash on certain platforms, even when compiled with gcc in standard
conforming mode. Those platforms had old libraries, that just let
free(NULL) do what it intuitively should do: crash the program. This
could have been trivially avoided by not caring about what the standard
says about this nonsensical library function call.

When passing NULL to a library function performs a useful operation (e.g.
fflush), you don't need to read the standard in order to discover it:
any good C book will document the behaviour.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Alan Balmer]

On Wed, 19 Nov 2003 07:58:03 +0000, Christian Bau
<ch***********@cbau.freeserve.co.uk> wrote:

In article <gb********************************@4ax.com>,
Alan Balmer <al******@att.net> wrote:

>So the fact that memcpy (NULL, src, 1) produces undefined behavior in C
>is not for some inherent reason, or for some deeply founded necessity,
>it is because the people responsibly for the C Standard decided that it
>would be so.

More likely because they decided that defining the behavior would have
little point, and would most likely break existing compilers, if not
code.

The first one is highly debatable, the second one is irrelevant to the
discussion.

If for example strcpy (dst, src) had defined behavior whenever the dst
argument is an actual array of char, and src a pointer to a string with
strlen (src) >= sizeof (dst), then the world would be a much better
place.

So, the people on the standards committee were motivated by a desire
to prevent the world from becoming a better place? Somehow I doubt
that.

Methinks you're using the wrong language. There are others which do
what you want.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Alan Balmer]

On 19 Nov 2003 03:31:36 -0800, lj****@tiscalinet.it (Lorenzo J.
Lucchini) wrote:

Alan Balmer <al******@att.net> wrote in message news:<gb********************************@4ax.com>. ..

On Tue, 18 Nov 2003 08:52:30 +0000, Christian Bau
<ch***********@cbau.freeserve.co.uk> wrote:

> [snip]
>
>So the fact that memcpy (NULL, src, 1) produces undefined behavior in C
>is not for some inherent reason, or for some deeply founded necessity,
>it is because the people responsibly for the C Standard decided that it
>would be so.
More likely because they decided that defining the behavior would have
little point, and would most likely break existing compilers, if not
code.

You said it. They *decided*. Definition 1b of 'decide' in m-w.com
goes:
"to select as a course of action"

However, deciding *whether* to define something is different than
deciding *which way* to define something. You need to read the rest of
the sentence as well.
This seems to imply that whenever a decision is made, another curse of
action (different from the one that was decided) could have been
selected.
Sure - they could have decided that a precise definition was needed.
They would then have to debate what that definition would be.
So the C standard committee *decided* that memcpy() should behave that
way *instead of* behaving differently, and you can't know before
looking at the documents they produced.
No, they decided to leave the behavior undefined. That's the reason
for this discussion.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Lorenzo J. Lucchini]

Da*****@cern.ch (Dan Pop) wrote in message news:<bp**********@sunnews.cern.ch>...

In <1f**************************@posting.google.com > lj****@tiscalinet.it (Lorenzo J. Lucchini) writes:

Alan Balmer <al******@att.net> wrote in message news:<gb********************************@4ax.com>. ..

On Tue, 18 Nov 2003 08:52:30 +0000, Christian Bau
<ch***********@cbau.freeserve.co.uk> wrote:

[snip]

More likely because they decided that defining the behavior would have
little point, and would most likely break existing compilers, if not
code.
You said it. They *decided*. Definition 1b of 'decide' in m-w.com
goes:
"to select as a course of action"
This seems to imply that whenever a decision is made, another curse of
action (different from the one that was decided) could have been
selected.

So the C standard committee *decided* that memcpy() should behave that
way *instead of* behaving differently, and you can't know before
looking at the documents they produced.

The *good* question is why would you care about what they decided for a
memcpy call that doesn't make any sense in the first place?

If something doesn't make sense, it is safer to avoid using it, even if
you know what the standard says about its behaviour.

I agree with you here.

But the original question went like this:
< [snip]
< What parameters (if any) may be 0 or NULL? IOW, which of the
following
< statements are guaranteed to produce well-defined behavior?
< [snip]
The OP didn't ask whether it would be sensible or not to use memcpy()
with such and such parameters, he only asked whether a call with those
parameters would behave in a guaranteed way.

That's why I don't agree with what you said in
<bo**********@sunnews.cern.ch>, that
< >[snip]
< >That's where a copy of the Standard comes in handy.
<
< Not so. It is enough to engage your brain. The only non-obvious
cases
< are those where the byte count is 0:
< [snip]

While you specified that the relevant cases are "non-obvious" (which,
in the context of the C standard, seems to imply that "you should read
the standard to know the truth about them"), you also said that "it is
enough to engage your brain" ["instead of using a copy of the
Standard", or that's at least how I interpret this sentence].
Looks like you're either contradicting yourself or answering the wrong
question, unless I'm wrong in my interpretation.
[snip]

by LjL
lj****@tiscali.it

[Lorenzo J. Lucchini]

Alan Balmer <al******@att.net> wrote in message news:<3t********************************@4ax.com>. ..

On 19 Nov 2003 03:31:36 -0800, lj****@tiscalinet.it (Lorenzo J.
Lucchini) wrote:

Alan Balmer <al******@att.net> wrote in message news:<gb********************************@4ax.com>. ..

On Tue, 18 Nov 2003 08:52:30 +0000, Christian Bau
<ch***********@cbau.freeserve.co.uk> wrote:

> [snip]
>
>So the fact that memcpy (NULL, src, 1) produces undefined behavior in C
>is not for some inherent reason, or for some deeply founded necessity,
>it is because the people responsibly for the C Standard decided that it
>would be so.

More likely because they decided that defining the behavior would have
little point, and would most likely break existing compilers, if not
code.

You said it. They *decided*. Definition 1b of 'decide' in m-w.com
goes:
"to select as a course of action"

However, deciding *whether* to define something is different than
deciding *which way* to define something. You need to read the rest of
the sentence as well.

Sure. But deciding *whether* to define something or leave it undefined
is still selecting a course of action.
So it is not the same as deciding *which way* to define something, but
it *is* the same as deciding *which way* to go about the definition.

This seems to imply that whenever a decision is made, another curse of
action (different from the one that was decided) could have been
selected.

Sure - they could have decided that a precise definition was needed.
They would then have to debate what that definition would be.

Correct, that decision would have required a subsequent decision,
while the decision of leaving the definition undecided did not.

So the C standard committee *decided* that memcpy() should behave that
way *instead of* behaving differently, and you can't know before
looking at the documents they produced.

No, they decided to leave the behavior undefined. That's the reason
for this discussion.

Depends which discussion - the OP asked whether some specific calls of
memcpy() had a defined behavior or not; later, some claimed that to
know the answer one has to read the ANSI standard, while others
claimed (or at least their statements were interpreted by more people
than myself alone as claiming) that common sense is enough.

With these parts of the thread in mind, let me assure you that I did
not disagree with your statement that "[they did not define the
behavior] [...] because they decided that defining the behavior would
have little point [...]".
However, I disagree with the implication (one that was not explicitly
stated by you, but from which this sub-thread originated) that it is
obvious that the actual decision of the Committee was to leave the
behavior undefined, only because the behavior would have little point.
I insist that one should read the Standard to know; it can't be
dismissed as obvious.

by LjL
lj****@tiscali.it

[Alan Balmer]

On 19 Nov 2003 11:09:19 -0800, lj****@tiscalinet.it (Lorenzo J.
Lucchini) wrote:

Depends which discussion - the OP asked whether some specific calls of
memcpy() had a defined behavior or not; later, some claimed that to
know the answer one has to read the ANSI standard, while others
claimed (or at least their statements were interpreted by more people
than myself alone as claiming) that common sense is enough.

As far as I'm concerned, the question is moot. One needs to read the
standard to know what the defined behavior of memcpy() is. One then
naturally knows what behavior is not defined, as well :-)

Reading the standard would be considerably quicker than asking here,
as well. But not as much fun :-)

--
Al Balmer
Balmer Consulting
re************************@att.net

[Christopher Benson-Manica]

Alan Balmer <al******@att.net> spoke thus:

Reading the standard would be considerably quicker than asking here,
as well. But not as much fun :-)

Certainly not, this has been a quite entertaining discussion... glad
I asked ;)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Christian Bau]

In article <3F***************@yahoo.com>,
CBFalconer <cb********@yahoo.com> wrote:

Christian Bau wrote:

CBFalconer <cb********@yahoo.com> wrote:

Christian Bau wrote:
>
... snip ...
>
> If for example strcpy (dst, src) had defined behavior whenever
> the dst argument is an actual array of char, and src a pointer
> to a string with strlen (src) >= sizeof (dst), then the world
> would be a much better place.

Why do you want to limit strcpy to strings shorter than the size
of a pointer? In other words, those semantics are unimplementable
with the existing definition of a C string.

I wrote "dst is an actual array of char", like in

char dst [100];

with sizeof (dst) == 100.

It doesn't matter. When you pass it to strcpy the thing passed is
a pointer, and sizeof (dst) will automatically be the sizeof a
pointer. The point is that strcpy does not receive sufficient
information to allow it to have that defined behaviour.

Before it is passed to strcpy all the information is there.

[Dan Pop]

In <ch*********************************@slb-newsm1.svr.pol.co.uk> Christian Bau <ch***********@cbau.freeserve.co.uk> writes:

In article <3F***************@yahoo.com>,
CBFalconer <cb********@yahoo.com> wrote:

Christian Bau wrote:

> CBFalconer <cb********@yahoo.com> wrote:
> > Christian Bau wrote:
> > >
> > ... snip ...
> > >
> > > If for example strcpy (dst, src) had defined behavior whenever
> > > the dst argument is an actual array of char, and src a pointer
> > > to a string with strlen (src) >= sizeof (dst), then the world
> > > would be a much better place.
> >
> > Why do you want to limit strcpy to strings shorter than the size
> > of a pointer? In other words, those semantics are unimplementable
> > with the existing definition of a C string.
>
> I wrote "dst is an actual array of char", like in
>
> char dst [100];
>
> with sizeof (dst) == 100.

It doesn't matter. When you pass it to strcpy the thing passed is
a pointer, and sizeof (dst) will automatically be the sizeof a
pointer. The point is that strcpy does not receive sufficient
information to allow it to have that defined behaviour.

Before it is passed to strcpy all the information is there.

Wrong! If the array definition is not in scope, the array is still an
array of 100 char, but the information is not available to the compiler.

What you want really requires a language enforcing array bound checking.
C is not this kind of language and was certainly not designed for people
needing this kind of checking. The problem is not the language, it is
the people who're not fit for using it, but use it, anyway.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de