memset() and portability

[copx]

I want to fill char/int arrays with zeros.
Is something like this portable/save:

char myArray[30][80];

memset(myArray,0,(30*80) * sizeof(char));

copx

[Chris Dollin]

copx wrote:

I want to fill char/int arrays with zeros.
Is something like this portable/save:

char myArray[30][80];

memset(myArray,0,(30*80) * sizeof(char));

memset( myArray, 0, sizeof (myArray) );

seems, to me at least, to be more reliable, if myArray is indeed an
array and not a pointer.

For int arrays there are in-principle portability traps, unless
someone's found a proof from the Standard that treating an array
of ints as (unsigned) chars and filling it with (char) zeroes will
guarantee that it gets filled with (int) zeroes.

--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgrou...mp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambl...me_to_clc.html

[Dan Pop]

In <bf**********@murdoch.hpl.hp.com> Chris Dollin <ke**@hpl.hp.com> writes:

copx wrote:

I want to fill char/int arrays with zeros.
Is something like this portable/save:

char myArray[30][80];

memset(myArray,0,(30*80) * sizeof(char));
memset( myArray, 0, sizeof (myArray) );

seems, to me at least, to be more reliable, if myArray is indeed an
array and not a pointer.

It's also more readable, especially if you drop the unneeded parentheses,
to expose the fact that sizeof is an operator and not a function:

memset(myArray, 0, sizeof myArray);
For int arrays there are in-principle portability traps, unless
someone's found a proof from the Standard that treating an array
of ints as (unsigned) chars and filling it with (char) zeroes will
guarantee that it gets filled with (int) zeroes.

The official answer to a Defect Report guarantees that. Hopefully, TC2
will contain the relevant change to the current standard.

But, since C89 doesn't have the problem in the first place and C99 is
practically unimplemented, there is no issue worth worrying about ;-)

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

[Malcolm]

"copx" <in*****@invalid.com> wrote in message

I want to fill char/int arrays with zeros.
Is something like this portable/save:

char myArray[30][80];

memset(myArray,0,(30*80) * sizeof(char));

sizeof(char) always equals one.

memset() has a few irritating portability traps. For instance, a NULL
pointer is almost always all bits zero, but this is not guaranteed. (It is
guaranteed to always compare equal to 0). A floating point number is almost
always 0 when all bits are zero, but again this is not guaranteed.

The problem is that your code will work happily, and then suddenly break
when someone transfers it to one of these weird formats.

[Burne C]

"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote in message
news:ch*********************************@slb-newsm1.svr.pol.co.uk...

In article <bf**********@news7.svr.pol.co.uk>,
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:

"copx" <in*****@invalid.com> wrote in message

I want to fill char/int arrays with zeros.
Is something like this portable/save:

char myArray[30][80];

memset(myArray,0,(30*80) * sizeof(char));

sizeof(char) always equals one.

"char" plays two roles in C. A "char" is the basic storage unit;
everything is measured in units of "char", and therefore sizeof (char)
must be 1. On the other hand, "char" is also a type of its own. If I
need an array of integers, and I know that all values are from 0 to 127,

No, the range of char is -128 to 127, and 0 to 255 for unsigned char.

--
BC

[Christian Bau]

In article <bf**********@imsp212.netvigator.com>, "Burne C" <[e-mail]>
wrote:

"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote in message
news:ch*********************************@slb-newsm1.svr.pol.co.uk...

In article <bf**********@news7.svr.pol.co.uk>,
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:

"copx" <in*****@invalid.com> wrote in message
>
> I want to fill char/int arrays with zeros.
> Is something like this portable/save:
>
> char myArray[30][80];
>
> memset(myArray,0,(30*80) * sizeof(char));
>
sizeof(char) always equals one.

"char" plays two roles in C. A "char" is the basic storage unit;
everything is measured in units of "char", and therefore sizeof (char)
must be 1. On the other hand, "char" is also a type of its own. If I
need an array of integers, and I know that all values are from 0 to 127,

No, the range of char is -128 to 127, and 0 to 255 for unsigned char.

I hope you don't have to port any code that relies on this.

[Dan Pop]

In <bf**********@imsp212.netvigator.com> "Burne C" <[e-mail]> writes:

"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote in message
news:ch*********************************@slb-newsm1.svr.pol.co.uk...

In article <bf**********@news7.svr.pol.co.uk>,
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:

> "copx" <in*****@invalid.com> wrote in message
> >
> > I want to fill char/int arrays with zeros.
> > Is something like this portable/save:
> >
> > char myArray[30][80];
> >
> > memset(myArray,0,(30*80) * sizeof(char));
> >
> sizeof(char) always equals one.

"char" plays two roles in C. A "char" is the basic storage unit;
everything is measured in units of "char", and therefore sizeof (char)
must be 1. On the other hand, "char" is also a type of its own. If I
need an array of integers, and I know that all values are from 0 to 127,

No, the range of char is -128 to 127, and 0 to 255 for unsigned char.

An object declared as type char is large enough to store any member
of the basic execution character set. If a member of the required
source character set enumerated in $2.2.1 is stored in a char object,
its value is guaranteed to be positive.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Have you ever heard of a character set called EBCDIC?

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

[Eric Sosman]

Burne C wrote:

"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote in message
news:ch*********************************@slb-newsm1.svr.pol.co.uk...

In article <bf**********@news7.svr.pol.co.uk>,
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:

"copx" <in*****@invalid.com> wrote in message
>
> I want to fill char/int arrays with zeros.
> Is something like this portable/save:
>
> char myArray[30][80];
>
> memset(myArray,0,(30*80) * sizeof(char));
>
sizeof(char) always equals one.

"char" plays two roles in C. A "char" is the basic storage unit;
everything is measured in units of "char", and therefore sizeof (char)
must be 1. On the other hand, "char" is also a type of its own. If I
need an array of integers, and I know that all values are from 0 to 127,

No, the range of char is -128 to 127, and 0 to 255 for unsigned char.

The range of `signed char' is at least -127 through +127,
possibly wider. The range of `unsigned char' is at least 0
through 255, possibly wider (although the minimum value will
necessarily be zero). The range of plain `char' is the same
as one or the other of `signed char' or `unsigned char', at
the whim of the implementation. Thus, the range 0 through 127
is exactly the set of values that can be guaranteed to fit in
a plain `char' on every C implementation, however bizarre.
To put it another way, any attempt to store a value outside
this range in a plain `char' is non-portable.[*]
[*] Of course, constructs like `char c1 = CHAR_MIN;' and
`char c2 = -1;' are "portable" in the sense that they
work everywhere. However, the values of `c1' and `c2'
are implementation-dependent, so the constructs are
"non-portable" in that they don't give the same
results everywhere.

--
Er*********@sun.com

[Eric Sosman]

Dan Pop wrote:

In <bf**********@imsp212.netvigator.com> "Burne C" <[e-mail]> writes:

An object declared as type char is large enough to store any member
of the basic execution character set. If a member of the required
source character set enumerated in $2.2.1 is stored in a char object,
its value is guaranteed to be positive.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Have you ever heard of a character set called EBCDIC?

Haven't seen anyone else respond to this one, so I'll bite:
Yes, I've heard of (and used) EBCDIC, and I remember nothing
about it that contradicts the quoted text from the Standard.
What have I missed?

--
Er*********@sun.com

[Arthur J. O'Dwyer]

On Mon, 28 Jul 2003, Eric Sosman wrote:

Dan Pop wrote:

In <bf**********@imsp212.netvigator.com> "Burne C" <[e-mail]> writes:

An object declared as type char is large enough to store any member
of the basic execution character set. If a member of the required
source character set enumerated in $2.2.1 is stored in a char object,
its value is guaranteed to be positive.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Have you ever heard of a character set called EBCDIC?

Haven't seen anyone else respond to this one, so I'll bite:
Yes, I've heard of (and used) EBCDIC, and I remember nothing
about it that contradicts the quoted text from the Standard.
What have I missed?

If your system uses EBCDIC, then CHAR_MAX must be bigger than 128,
which means either that 'char' must be an unsigned type or must have
more than 8 bits, or both. You've snipped the part Dan was responding
to, so I don't know which of these points applies to the original
conversation.

-Arthur

[Eric Sosman]

"Arthur J. O'Dwyer" wrote:

On Mon, 28 Jul 2003, Eric Sosman wrote:

Dan Pop wrote:

In <bf**********@imsp212.netvigator.com> "Burne C" <[e-mail]> writes:

An object declared as type char is large enough to store any member
of the basic execution character set. If a member of the required
source character set enumerated in $2.2.1 is stored in a char object,
its value is guaranteed to be positive.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Have you ever heard of a character set called EBCDIC?

Haven't seen anyone else respond to this one, so I'll bite:
Yes, I've heard of (and used) EBCDIC, and I remember nothing
about it that contradicts the quoted text from the Standard.
What have I missed?

If your system uses EBCDIC, then CHAR_MAX must be bigger than 128,
which means either that 'char' must be an unsigned type or must have
more than 8 bits, or both. You've snipped the part Dan was responding
to, so I don't know which of these points applies to the original
conversation.

Aha! What I missed was who wrote what: I somehow thought
Dan was objecting to a piece of Standard quoted by "Burne C,"
but in fact Dan quoted the Standard to refute "Burne C." Sorry
for the (my) confusion.

--
Er*********@sun.com