memcpy/memmove

[Christian Bau]

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]

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

 

[Alan Balmer]

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.

 

[Richard Bos]

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]

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.[/QUOTE]

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]

[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
(e-mail address removed)

 

[CBFalconer]

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

 

[Dan Pop]

[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

 

[Alan Balmer]

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.[/QUOTE]

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.

 

[Alan Balmer]

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

 

[Lorenzo J. Lucchini]

On Tue, 18 Nov 2003 08:52:30 +0000, Christian Bau

[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
<[email protected]>, 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
(e-mail address removed)

 

[Lorenzo J. Lucchini]

On Tue, 18 Nov 2003 08:52:30 +0000, Christian Bau

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

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.

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
(e-mail address removed)

 

[Alan Balmer]

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

 

[Christopher Benson-Manica]

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

 

[Christian Bau]

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.

 

[Christian Bau]

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

I can't think of any logical reason to draw that conclusion.

Somehow I doubt that.

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

It seems you have still no idea what this discussion is about.

 

[Christian Bau]

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

Wrong.

 

[CBFalconer]

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.

 

[Christian Bau]

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]

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