Does memory copied with memcpy() match bit for bit?

[Spiros Bousbouras]

In a different post ([1]) I suggested the possibility of using
memcpy() to copy regions of memory (to be) used by other
processes. It would be useful for this sort of thing to know
that the regions will match bit for bit but I don't think that
the standard guarantees that. For example 6.2.6.2. p3 says

It is unspecified whether these cases actually
generate a negative zero or a normal zero, and
whether a negative zero becomes a normal zero when
stored in an object.

The part that worries me is what comes after the comma.
Unitialised memory might contain a negative zero which might
become normal zero and I imagine the difference might be
important for some other programme. So what are your views?


[1] Link is http://tinyurl.com/9t9mmd but you have to click on
my name, or at least that's how it works for me.

 

[vippstar]

In a different post ([1]) I suggested the possibility of using
memcpy() to copy regions of memory (to be) used by other
processes.  It would be useful for this sort of thing to know
that the regions will match bit for bit but I don't think that
the standard guarantees that. For example 6.2.6.2. p3 says

    It is unspecified whether these cases actually
    generate a negative zero or a normal zero, and
    whether a negative zero becomes a normal zero when
    stored in an object.

The part that worries me is what comes after the comma.
Unitialised memory might contain a negative zero which might
become normal zero and I imagine the difference might be
important for some other programme. So what are your views?

[1] Link ishttp://tinyurl.com/9t9mmdbut you have to click on
my name, or at least that's how it works for me.

You haven't quoted 6.2.6.2 p3 fully:
<quote>
If the implementation supports negative zeros, they shall be generated
only by:
-- the &, |, ^, ~, <<, and >> operators with arguments that produce
such a value;
-- the +, -, *, /, and % operators where one argument is a negative
zero and the result is
zero;
-- compound assignment operators based on the above cases.
It is unspecified whether these cases actually generate a negative
zero or a normal zero,
and whether a negative zero becomes a normal zero when stored in an
object.
</quote>

To answer your question, yes they match bit by bit. The standard
allows you to peek at an objects representation with unsigned char *.
I hope I'm clear enough, if not, here's pseudocode:
T obj; ((unsigned char *)&obj)[0 ... sizeof obj - 1]
See 6.2.6 Representation of types

 

[James Kuyper]

In a different post ([1]) I suggested the possibility of using
memcpy() to copy regions of memory (to be) used by other
processes. It would be useful for this sort of thing to know
that the regions will match bit for bit but I don't think that
the standard guarantees that. For example 6.2.6.2. p3 says

It is unspecified whether these cases actually
generate a negative zero or a normal zero, and
whether a negative zero becomes a normal zero when
stored in an object.

The part that worries me is what comes after the comma.
Unitialised memory might contain a negative zero which might
become normal zero and I imagine the difference might be

The behavior of memcpy() is described in 7.21. 7.21.1p3 says

"For all functions in this subclause, each character shall be
interpreted as if it had the type unsigned char (and therefore every
possible object representation is valid and has a different value)."

As a result, signed zeros are not relevant, and no such conversion is
allowed.

 

[Keith Thompson]

In a different post ([1]) I suggested the possibility of using
memcpy() to copy regions of memory (to be) used by other
processes. It would be useful for this sort of thing to know
that the regions will match bit for bit but I don't think that
the standard guarantees that. For example 6.2.6.2. p3 says
It is unspecified whether these cases actually
generate a negative zero or a normal zero, and
whether a negative zero becomes a normal zero when
stored in an object.
The part that worries me is what comes after the comma.
Unitialised memory might contain a negative zero which might
become normal zero and I imagine the difference might be

The behavior of memcpy() is described in 7.21. 7.21.1p3 says

"For all functions in this subclause, each character shall be
interpreted as if it had the type unsigned char (and therefore every
possible object representation is valid and has a different value)."

As a result, signed zeros are not relevant, and no such conversion is
allowed.

That paragraph doesn't exist in the original C99 standard; it was
added by TC2. (Which, as I understand it, is just as official as the
original standard.)

 

[thomas.mertes]

In a different post ([1]) I suggested the possibility of using
memcpy() to copy regions of memory ...

The function memcpy() was designed to copy memory
such that the memory copied matches bit for bit.
If it would not work that way many programs would
have trouble.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.