Initialized arrays using new

[Frederick Gotham]

Pete Becker posted:

Jim Langston wrote:

On my system I tried this:
int* MyArray = new int[10];
std::cout << MyArray[0] << std::endl;

Just a note: The act of rvalue-ing an uninitialized integer is undefined.

(Question: Is this defined?

char f;
assert(0 == f || 0 != f);

I know it's undefined for 'int f'.)

In C it's undefined when f is an int, but well defined when f is any
flavor of char.

Signed char may trap in C (it may also contain padding).

Signed char may NOT contain padding in C++ (although I'm not certain if it
can trap or not -- you never get a clear answer.)

 

[Greg Comeau]

John posted:

This produces an initialized array to zero:

int *i = new int[100]() ;

The Standard guarantees this.

But this doesn't initialize the array. The assembly output is identical.
What's going on?

int *i = new int[100] ;

It appears that your compiler initialises all new'd memory to zero
(regardless of whether you ask it to). This is inefficient, yet doesn't
violate any constraits of the Standard.

Perhaps if you switch to Release Mode, it will remove this inefficiency.

It probably didn't actually do the zero new in the latter case
and happened to return a pointer to a block that was already zero'd.

 

[Pete Becker]

Pete Becker posted:

Jim Langston wrote:



On my system I tried this:
int* MyArray = new int[10];
std::cout << MyArray[0] << std::endl;


Just a note: The act of rvalue-ing an uninitialized integer is

undefined.

(Question: Is this defined?

char f;
assert(0 == f || 0 != f);

I know it's undefined for 'int f'.)

In C it's undefined when f is an int, but well defined when f is any
flavor of char.

Signed char may trap in C (it may also contain padding).

6.2.6.1/5:

Certain object representations need not represent a value of the
object type. If the stored value has such a representation and
is read by an lvalue expression THAT DOES NOT HAVE CHARACTER
TYPE, the behavior is undefined. If such a representation is
produced by a side effect that modifies all or any part of the
object by an lvalue expression THAT DOES NOT HAVE CHARACTER
TYPE, the behavior is undefined. Such a representation is
called a trap representation. [emphasis added]

Reading and writing a value through any character type are both well
defined, i.e. they do not trap.

 

[Phlip]

However, these are the results using BloodShed (version 4.9.9.2):

-1163005939 -1163005939 -1163005939 -1163005939 -1163005939 -1163005939 -1163005939
-1163005939 -1163005939 -1163005939 -1163005939 -1163005939 -1163005939 -1163005939
-1163005939 -1163005939 -1163005939 -1163005939 -1163005939 -1414812757
(interesting that the last element differs)

Also note that barfing out your raw memory where others can see is a
security loophole! ;-)

 

[W Marsh]

Also note that barfing out your raw memory where others can see is a
security loophole! ;-)

That's not what loophole means.

 

[tolgaceylanus]

Is this related to the C++ feature where;

int x;

int y = int();

y is guaranteed to be initialized?

Tolga Ceylan

 

[Frederick Gotham]

Pete Becker posted:

6.2.6.1/5:

Certain object representations need not represent a value of the
object type. If the stored value has such a representation and
is read by an lvalue expression THAT DOES NOT HAVE CHARACTER
TYPE, the behavior is undefined. If such a representation is
produced by a side effect that modifies all or any part of the
object by an lvalue expression THAT DOES NOT HAVE CHARACTER
TYPE, the behavior is undefined. Such a representation is
called a trap representation. [emphasis added]

Reading and writing a value through any character type are both well
defined, i.e. they do not trap.

But, in C, a signed char can still contain padding... right?

Is the above snippet from the C Standard, or the C++ Standard?

 

[Frederick Gotham]

Greg Comeau posted:

It probably didn't actually do the zero new in the latter case
and happened to return a pointer to a block that was already zero'd.

The assembly code was identical though -- so "new" must zero its memory by
default on that system... no?

 

[Frederick Gotham]

posted:

Is this related to the C++ feature where;

int x;

int y = int();

y is guaranteed to be initialized?

Yes, exactly that. Also:

class MyClass {
private:

int i;

public:

MyClass() : i() {}
};

 

[Pete Becker]

Pete Becker posted:

6.2.6.1/5:

Certain object representations need not represent a value of the
object type. If the stored value has such a representation and
is read by an lvalue expression THAT DOES NOT HAVE CHARACTER
TYPE, the behavior is undefined. If such a representation is
produced by a side effect that modifies all or any part of the
object by an lvalue expression THAT DOES NOT HAVE CHARACTER
TYPE, the behavior is undefined. Such a representation is
called a trap representation. [emphasis added]

Reading and writing a value through any character type are both well
defined, i.e. they do not trap.

But, in C, a signed char can still contain padding... right?

I don't see how, given the constraints on the relationship between
signed and unsigned variants of the same type, and the requirement that
unsigned char have no padding. There's just no room. They're the same
size, and the sign bit takes up one bit. When the sign bit is 0, the
remaining value bits mean the same thing in both signed char and
unsigned char. Since there's no padding in an unsigned char, there's
nothing left to pad with for non-negative values of type signed char.

Is the above snippet from the C Standard, or the C++ Standard?

It was a reply to your

> Signed char may trap in C (it may also contain padding).

It's from C99.

 

[Howard]

Greg Comeau posted:



The assembly code was identical though -- so "new" must zero its memory by
default on that system... no?

No, it was just an oversight on the poster's part. The assembly code was
not identical. There was code after that part which initialized the memory
in the case with the () included, just as there should have been.

-Howard

 

[Default User]

Frederick Gotham wrote:

Signed char may trap in C (it may also contain padding).

6.2.6.1/5:

Certain object representations need not represent a value of the
object type. If the stored value has such a representation and
is read by an lvalue expression THAT DOES NOT HAVE CHARACTER
TYPE, the behavior is undefined. If such a representation is
produced by a side effect that modifies all or any part of the
object by an lvalue expression THAT DOES NOT HAVE CHARACTER
TYPE, the behavior is undefined. Such a representation is
called a trap representation. [emphasis added]

Reading and writing a value through any character type are both well
defined, i.e. they do not trap.

And that's an important feature, because it allows one to cast the
pointer to an object to a char type (unsigned ususally) and examine the
byte representation of that object without worrying about a trap.



Brian

 

[Greg Comeau]

Is this related to the C++ feature where;

int x;

int y = int();

y is guaranteed to be initialized?

Related may not be the right word, but yes.

 

[Greg Comeau]

Greg Comeau posted:

The assembly code was identical though -- so "new" must zero its memory by
default on that system... no?

Then the compiler is one or more of: broken, not conformant,
not in strict mode, has an extension, or, the 0'ing code was
unobvious.

 

[Frederick Gotham]

Default User posted:

And that's an important feature, because it allows one to cast the
pointer to an object to a char type (unsigned ususally) and examine the
byte representation of that object without worrying about a trap.

Yes, I do so frequently -- but I always use the "unsigned" flavour.

In C++, neither signed char nor unsigned char may contain padding. As plain
char is congruent to one of these types, plain char may not contain padding
either.

In C, unsigned char may not contain padding, but signed char may. As plain
char is congruent to one of these types, plain char may contain padding.

When talking about C, it's best to indicate whether you're talking about
C89 or C99. C89 is the more dominant of the two.

Signed char can trap in C89.

As for signed char trapping in C++, it's hard to get a definitive answer --
just look how conclusive the responses are to this thread:

http://groups.google.ie/group/comp.std.c++/browse_frm/thread/9edfa2eed6267b
c2/47ccdf97703d87c1?lnk=st&q=&rnum=1&hl=en#47ccdf97703d87c1