Assigning values to char arrays

[emyl]

Hi all,

here's an elementary question. Assume I have declared two variables,

char *a, **b;

I can then give a value to a like

a="hello world";

The question is, how should I assign values to b? A simple

b[0]="string";

results in a segmentation fault.

Answers greatly appreciated.

Regards, Emyl.

[santosh]

Ark Khasin wrote:

Ben Bacarisse wrote:

<snip>

>No. unsigned char may not have padding bits. All the bits must be
value bits.

Why?
6.2.6.2 says "For unsigned integer types other than unsigned char, the
bits of the object representation shall be divided into two groups:
value bits and padding bits (there need not be any of the latter).
But I couldn't find anything saying that unsigned char *may not* have
padding bits.

Well the above quote says that unsigned char may not have _both_ padding
and value bits. Obviously the bit type left out has to be padding
bits - otherwise one would not be able to potably use unsigned char
objects.

<snip>

[Ark Khasin]

santosh wrote:

Ark Khasin wrote:

>Ben Bacarisse wrote:

<snip>

>>No. unsigned char may not have padding bits. All the bits must be
value bits.

>Why?
6.2.6.2 says "For unsigned integer types other than unsigned char, the
bits of the object representation shall be divided into two groups:
value bits and padding bits (there need not be any of the latter).
But I couldn't find anything saying that unsigned char *may not* have
padding bits.

Well the above quote says that unsigned char may not have _both_ padding
and value bits. Obviously the bit type left out has to be padding
bits - otherwise one would not be able to potably use unsigned char
objects.

Is this "just a theory"? IMHO, 6.2.6.2 says *exactly nothing* about
unsigned char.

[Ark Khasin]

santosh wrote:

Ark Khasin wrote:

>Richard wrote:

<snip>

>I am not to argue who of us two is more of a newbie, but your post
sheds no light on the question asked. Ego bubbling?

This is most hilarious sentence I've read in c.l.c. this year.

Ty. But Richard offered a satisfactory explanation.
--
Ark

[santosh]

Ark Khasin wrote:

santosh wrote:

>Ark Khasin wrote:

>>Ben Bacarisse wrote:

<snip>

>>>No. unsigned char may not have padding bits. All the bits must be
value bits.

>>Why?
6.2.6.2 says "For unsigned integer types other than unsigned char,
the bits of the object representation shall be divided into two
groups: value bits and padding bits (there need not be any of the
latter). But I couldn't find anything saying that unsigned char *may
not* have padding bits.

Well the above quote says that unsigned char may not have _both_
padding and value bits. Obviously the bit type left out has to be
padding bits - otherwise one would not be able to potably use
unsigned char objects.

Is this "just a theory"? IMHO, 6.2.6.2 says *exactly nothing* about
unsigned char.

<quote n1256.pdf>

6.2.6.2 Integer types

1 For unsigned integer types other than unsigned char, the bits of the
object representation shall be divided into two groups: value bits and
padding bits (there need not be any of the latter).

<endquote>

Note closely the text within the parenthesis. To me it _strongly_
implies, to say the least, that value bits are mandatory for objects of
all unsigned integer types. Since unsigned char is disallowed from
having padding bits, it must be composed only of value bits.

<quote n1256.pdf>

If there are N value bits, each bit shall represent a different power of
2 between 1 and 2N-1, so that objects of that type shall be capable of
representing values from 0 to 2N -1 using a pure binary representation;
this shall be known as the value representation. The values of any
padding bits are unspecified.44)

6.2.6.1

3 Values stored in unsigned bit-fields and objects of type unsigned char
shall be represented using a pure binary notation.40)

<endquote>

Again 6.2.6.1(3) in conjunction with 6.2.6.2(1) reinforces the
requirement that unsigned char may not have padding bits.

<quote n1256.pdf>

4 Values stored in non-bit-field objects of any other object type
consist of n ´ CHAR_BIT bits, where n is the size of an object of that
type, in bytes. The value may be copied into an object of type unsigned
char [n] (e.g., by memcpy); the resulting setof bytes is
called the object representation of the value. Values stored in
bit-fields consist of m bits, where m is the size specified for the
bit-field. The object representation is the set of m bits the bit-field
comprises in the addressable storage unit holding it. Two values (other
than NaNs) with the same object representation compare equal, but values
that compare equal may have different object representations .

<endquote>

This answers the other issue that you raised concerning null pointers
not being all bits zero.

[pete]

Ark Khasin wrote:

>
santosh wrote:

Ark Khasin wrote:

Ben Bacarisse wrote:

<snip>

>No. unsigned char may not have padding bits.

Is this "just a theory"?

No.

N869
5.2.4.2.1 Sizes of integer types <limits.h>

[#2] The value UCHAR_MAX+1
shall equal 2 raised to the power CHAR_BIT.

--
pete

[Ark Khasin]

pete wrote:

Ark Khasin wrote:

>santosh wrote:

>>Ark Khasin wrote:
Ben Bacarisse wrote:
<snip>

No. unsigned char may not have padding bits.

>Is this "just a theory"?

No.

N869
5.2.4.2.1 Sizes of integer types <limits.h>

[#2] The value UCHAR_MAX+1
shall equal 2 raised to the power CHAR_BIT.

Thanks to adding to my confusion :)
So I have an 11-bit machine bytes and UCHAR_MAX==8 and 3 padding most
significant bits. Anything wrong?
BTW, if I am not mistaken, in other integer types padding bits don't
have to be contiguous.
--
Ark

[santosh]

Ark Khasin wrote:

pete wrote:

>Ark Khasin wrote:

>>santosh wrote:
Ark Khasin wrote:
Ben Bacarisse wrote:
<snip>

>No. unsigned char may not have padding bits.

>>Is this "just a theory"?

No.

N869
5.2.4.2.1 Sizes of integer types <limits.h>

[#2] The value UCHAR_MAX+1
shall equal 2 raised to the power CHAR_BIT.

Thanks to adding to my confusion :)
So I have an 11-bit machine bytes and UCHAR_MAX==8 and 3 padding most
significant bits. Anything wrong?

What do you mean by UCHAR_MAX==8? Do you mean CHAR_BIT==8?

As far as the Standard is concerned a char i.e., a byte (as defined by
C) contains CHAR_BIT bits. Additionally unsigned char may not contain
padding bits.

I don't know what you mean by "machine bytes" above. Are they supposed
to be different from C bytes?

BTW, if I am not mistaken, in other integer types padding bits don't
have to be contiguous.

Yes. Padding bits need not be contiguous.

[Flash Gordon]

Ark Khasin wrote, On 03/11/07 20:05:

pete wrote:

>Ark Khasin wrote:

>>santosh wrote:
Ark Khasin wrote:
Ben Bacarisse wrote:
<snip>

>No. unsigned char may not have padding bits.

>>Is this "just a theory"?

No.

N869
5.2.4.2.1 Sizes of integer types <limits.h>

[#2] The value UCHAR_MAX+1 shall equal 2 raised to the
power CHAR_BIT.

Thanks to adding to my confusion :)
So I have an 11-bit machine bytes and UCHAR_MAX==8 and 3 padding most
significant bits. Anything wrong?

CHAR_BIT is the number of bits in a signed, unsigned and plain char.
Note, the number of bits, NOT the number of value bits. Therefore, as
UCHAR_MAX is 2 raised to the power of CHAR_BIT all of the bits must be
value bits.

BTW, if I am not mistaken, in other integer types padding bits don't
have to be contiguous.

The padding bits can be anywhere, but short of using an unsigned char
pointer to look at the representation they are hard to get at since the
bitwise operations are defined as operating on values.
--
Flash Gordon

[James Kuyper]

Ark Khasin wrote:

Ben Bacarisse wrote:

>Ark Khasin <ak*****@macroe xpressions.comw rites:

[>Ben Bacarisse wrote:]
....

>RH's point was something else altogether -- that all bits zero is not
guaranteed to produce a null pointer (to be scrupulously correct, it
is not guaranteed to produce a value that compares equal to a null
pointer constant).

The parenthesized comment was not actually needed to make the statement
"scrupulous ly correct"; it would have been just as correct, and less
confusing, without it.

That's where I am lost and reading the standard doesn't help:
What's the difference between a value of an object and how it compares
equal? I mean, if a==b, whatever their representations , in what
context(s) does it make sense to say they may have different values?

There is no difference. Don't let the unnecessary "clarificat ion"
confuse you. The issue isn't having different values with the same
representation in a single type - that can't happen. The issue is that
there can be multiple different representations of the same value in a
given type. However, the values of objects of that type containing those
different representations must compare equal.

You're tripping over a minor issue; the fact that there can be multiple
representations of a null pointer. However, you've lost track of the key
issue: that a pointer object with all of its bits set to 0 doesn't have
to be one of those representations . In fact, it doesn't have to
represent a valid pointer value of any kind.

[NEGATIVE_ZERO comes to mind - and goes away. BTW, is it fair to say
that bitwise logic is a magic performed on representations , and not on
values?]

No. In general, the bitwise operations are defined in terms of their
actions on the values, not the representations . For instance, E>>1 is
defined as dividing the value of E by 2. The complicated exceptions all
involve sign bits, and most result in undefined behavior, which is why
it's strongly recommended that bitwise operations be restricted to
unsigned types, or at least restricted to values which are guaranteed to
be positive both before and after the operation.

> void *a;;
memset_as_above (&a, 0, sizeof a);

There is, at this point, no guarantee that 'a' contains a valid pointer
representation. Therefore, the next line renders the behavior of your
entire program undefined:

> if (a == 0) {
/* not guaranteed */

//Which is correct but implies
{
void **pNULL = 0;
if(a==*pNULL) {
/* not guaranteed */

I'm not sure what your point was; but you've just attempted to
dereference a null pointer, again making the behavior undefined.

[pete]

Ark Khasin wrote:

>
pete wrote:

Ark Khasin wrote:

santosh wrote:
Ark Khasin wrote:
Ben Bacarisse wrote:
<snip>

No. unsigned char may not have padding bits.

Is this "just a theory"?

No.

N869
5.2.4.2.1 Sizes of integer types <limits.h>

[#2] The value UCHAR_MAX+1
shall equal 2 raised to the power CHAR_BIT.

Thanks to adding to my confusion :)
So I have an 11-bit machine bytes

That's what "CHAR_BIT equals eleven" means.

--
pete