Clearing an array

[Jack Klein]

It has been repeatedly claimed in comp.std.c that the Committee's
response to a Defect Report is authoritative, for example in
<[email protected]> or <[email protected]>.
Is this not the case?

Martin

But this is not an authoritative response, it is a _suggestion_ by one
member for a TC. It has obviously not been approved, or it would not
be merely a suggestion.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[Jack Klein]

I have an array that I initialize to zero, like:

Buffer[300] = {0x00};

How do I in my code reset this array to all zeros ones more? Without
running a whole for loop?

The portable way for any type is:

static mytype_s const z[300] = {0};
memcpy(Buffer, z, sizeof Buffer); /* <string.h> */

If the array is of type unsigned char, you can use:

memset (Buffer, 0, sizeof Buffer);

With other types, the result is undefined.

No, how many times do I need to repeat this.

It is not undefined for any type of char (signed, unsigned, or plain).

It is not undefined for any exact-width types defined in <stdint.h>.

In fact, it is not only not undefined but guaranteed to produce all 0
_values_ for any signed or unsigned integer type provided only that
the unsigned type does not have any padding bits. Even if the
corresponding signed type does have padding bits.

The reason that the standard guarantees this is left as an exercise to
the reader (or the reader can look up the three or so other posts I
have made about within the past week alone).

And any platform that has padding bits in its unsigned integer types
is actually not worth worrying about anymore. Unless somebody can
name one that is still in production AND has a C99 implementation.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[LibraryUser]

Nothing in the standard, but computer designers tend to like it
that way.

Does anyone know of a machine where it isn't true? (comp.arch added.)

The well known DeathStation 3000.

 

[Default User]

On 16 Sep 2003 01:40:30 +0200, Martin Dickopp

But this is not an authoritative response, it is a _suggestion_ by one
member for a TC. It has obviously not been approved, or it would not
be merely a suggestion.

I'm confused on this one, because they have it marked Closed, with no
indication of anything added to a TC.



Brian Rodenborn

 

[Keith Thompson]

Well since the value of an array is a pointer to its initial element,
I'd say arrays are indeed being passed by value ;-)

No, the value of an array consists of the values of its elements.

The name of an array object, in most expression contexts, is
implicitly converted to a pointer to the the array's first element;
that conversion results in a distinct value.

 

[Emmanuel Delahaye]

The well known DeathStation 3000.

You meant DS 9000 !

 

[Glen Herrmannsfeldt]

You meant DS 9000 !

So, what is the floating point representation for +0.0 on the DS9000?

How many different sizes are available?

-- glen

 

[LibraryUser]

So, what is the floating point representation for +0.0 on the DS9000?

How many different sizes are available?

That comes under the heading of trade secrets / proprietary
information / national security etc. If I told you these things
I would have to kill you. However the DS9000 can be trusted to
adhere to the C89 and C99 standards, i.e. it will never emit
nasal demons, cause explosions, etc. on correct coding and input
data.

 

[Dave Thompson]

On Mon, 15 Sep 2003 17:20:41 GMT, Joe Wright

typedef struct arr {
int arr[SA];
} arr;

arr st_arr;

int array[SA];

C makes arrays difficult. Their expression results in a pointer to its
first element, they cannot be passed by value. Shucks. But what of a
struct consisting of an array? You can do anything with the struct that
you can with the array. What I have not realized until today is, you can
assign the 'value' of a struct (the whole thing) to a local array of the
same size (carefully), as above.

*((arr *)array) = st_arr; /* assign the struct to the local array */

This works (I think) because array in this context is pointer. Casting
it to a struct pointer and dereferencing it creates perfect lvalue
target for the assignment of a struct.

I think technically this is illegal (UB) because you are accessing an
object using a type (lvalue) other than its correct (here, declared)
type or character, or one of the minor variations allowed in 6.5p7; at
least I think that the fifth exception there is intended only to allow
*sub*objects of an aggregate to be accessed by (as part of) an access
to that aggregate, as is clearly necessary, not to allow a subobject
to be accessed *as* the aggregate, but that could be clearer.

Theoretically it could fail because the struct 'st_arr' may contain
padding after the only element arr, while 'array' must not, and struct
assignment may (and usually does) copy padding. In practice I think
the chance of this is about equal to that of winning the lottery while
being hit by a meteorite.

It could also screw up aggressive type-aware optimization, leading to
use of stale cached values, although on current systems I know of
int[10] seems a rather poor candidate for caching.

So, yes it probably does work. But it's much cleaner to just define
your objects of the struct type, arr, in the first place, and assign
or pass or return them; you can still easily use the array member.

- David.Thompson1 at worldnet.att.net