Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Assigning values to char arrays

Reply
Thread Tools

Assigning values to char arrays

 
 
Ark Khasin
Guest
Posts: n/a
 
      11-03-2007
Richard Heathfield wrote:
<snip>
> The memset function can be (isn't!, but can legally be) implemented like
> this:
>
> #include <stddef.h>
> void *memset(void *s, int c, size_t n)
> {
> unsigned char *p = s;
> while(n--)
> {
> *p++ = c;
> }
> return s;
> }
>

<snip>
> would merely have set the object
> representation to all-bits-zero, without any attempt whatsoever to address
> the question of which value the object would have afterwards.
>

As a practitioner, I didn't think twice to clear all bits with memset
clones including the likes of the code above. But now this post scared
me: if unsigned char has padding bits in its representation (which I
guess is allowed) then what do I get?
unsigned a;
memset_as_above(&a, 0, sizeof(a));
Will a necessarily compare equal to 0?
--
Thank you,
Ark
 
Reply With Quote
 
 
 
 
Richard
Guest
Posts: n/a
 
      11-03-2007
Ark Khasin <(E-Mail Removed)> writes:

> Richard Heathfield wrote:
> <snip>
>> The memset function can be (isn't!, but can legally be) implemented
>> like this:
>>
>> #include <stddef.h>
>> void *memset(void *s, int c, size_t n)
>> {
>> unsigned char *p = s;
>> while(n--)
>> {
>> *p++ = c;
>> }
>> return s;
>> }
>>

> <snip>
>> would merely have set the object representation to all-bits-zero,
>> without any attempt whatsoever to address the question of which
>> value the object would have afterwards.
>>

> As a practitioner, I didn't think twice to clear all bits with memset
> clones including the likes of the code above. But now this post scared
> me: if unsigned char has padding bits in its representation (which I


Scarey isn't it. The explanations given here confuse the newbie no end
because they include the instances of extinct system and a tiny minority
of systems which feature all sorts of hocus pocus. You know "a NULL
pointer is not necessarily all bit 0s" for example.....

or

p=0; /* p is not necessarily equal to zero */


> guess is allowed) then what do I get?
> unsigned a;
> memset_as_above(&a, 0, sizeof(a));
> Will a necessarily compare equal to 0?

 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      11-03-2007
Ark Khasin <(E-Mail Removed)> writes:

> Richard Heathfield wrote:
> <snip>
>> The memset function can be (isn't!, but can legally be) implemented
>> like this:
>>
>> #include <stddef.h>
>> void *memset(void *s, int c, size_t n)
>> {
>> unsigned char *p = s;
>> while(n--)
>> {
>> *p++ = c;
>> }
>> return s;
>> }
>>

> <snip>
>> would merely have set the object representation to all-bits-zero,
>> without any attempt whatsoever to address the question of which
>> value the object would have afterwards.
>>

> As a practitioner, I didn't think twice to clear all bits with memset
> clones including the likes of the code above. But now this post scared
> me: if unsigned char has padding bits in its representation (which I
> guess is allowed)


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

> then what do I get?
> unsigned a;
> memset_as_above(&a, 0, sizeof(a));
> Will a necessarily compare equal to 0?


Yes. 6.2.6.2p5 says (in part):

"... For any integer type, the object representation where all the
bits are zero shall be a representation of the value zero in that
type."

This is marked with change bars in recent PDFs so I suspect it is the
result of a clarification. But of what? Unsigned integer values are
represented with two sets of bits: values bits and padding bits. On a
machine with no padding bits, the above produces a value of 0. On one
with padding bits there are two possibilities. if there are no trap
representations (the padding bits are just that -- pure padding) then,
again a value of zero is guaranteed. Only on a machine with some trap
representations could the above code not produce a value of zero. It
is very unlikely that all bits zero would be a trap rep. (the only one
I have ever seen uses a parity bit) and it seems the committee has
clarified that this daft case is to be ruled out.

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). I.e.

void *a;;
memset_as_above(&a, 0, sizeof a);
if (a == 0) {
/* not guaranteed */
}

I would not be seriously concerned about code that makes this
assumption, but one can always test it at run time to be sure. On my
personal nervousness scale, this one is very low down.

--
Ben.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      11-03-2007
Richard <(E-Mail Removed)> writes:

> Ark Khasin <(E-Mail Removed)> writes:
>
>> Richard Heathfield wrote:
>> <snip>
>>> The memset function can be (isn't!, but can legally be) implemented
>>> like this:

<snip example of how memset might work>
>> <snip>
>>> would merely have set the object representation to all-bits-zero,
>>> without any attempt whatsoever to address the question of which
>>> value the object would have afterwards.
>>>

>> As a practitioner, I didn't think twice to clear all bits with memset
>> clones including the likes of the code above. But now this post scared
>> me: if unsigned char has padding bits in its representation (which I

>
> Scarey isn't it. The explanations given here confuse the newbie no end
> because they include the instances of extinct system and a tiny minority
> of systems which feature all sorts of hocus pocus. You know "a NULL
> pointer is not necessarily all bit 0s" for example.....


Beginners can, and should, skip those post they find confusing. We
can't restrict posting to those that can't be misunderstood by some
learners. Personally (having lived though the days of peculiar
hardware) I am more worried a bout *future* systems than obsolete
ones.

> p=0; /* p is not necessarily equal to zero */


Who is suggesting this? What do you mean by it? If you are trying to
avoid confusing beginners, do you think the above helps to keep things
clear?

--
Ben.
 
Reply With Quote
 
Ark Khasin
Guest
Posts: n/a
 
      11-03-2007
Ben Bacarisse wrote:
> Ark Khasin <(E-Mail Removed)> writes:
>
>> Richard Heathfield wrote:
>> <snip>
>>> The memset function can be (isn't!, but can legally be) implemented
>>> like this:
>>>
>>> #include <stddef.h>
>>> void *memset(void *s, int c, size_t n)
>>> {
>>> unsigned char *p = s;
>>> while(n--)
>>> {
>>> *p++ = c;
>>> }
>>> return s;
>>> }
>>>

>> <snip>
>>> would merely have set the object representation to all-bits-zero,
>>> without any attempt whatsoever to address the question of which
>>> value the object would have afterwards.
>>>

>> As a practitioner, I didn't think twice to clear all bits with memset
>> clones including the likes of the code above. But now this post scared
>> me: if unsigned char has padding bits in its representation (which I
>> guess is allowed)

>
> 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.
>
>> then what do I get?
>> unsigned a;
>> memset_as_above(&a, 0, sizeof(a));
>> Will a necessarily compare equal to 0?

>
> Yes. 6.2.6.2p5 says (in part):
>
> "... For any integer type, the object representation where all the
> bits are zero shall be a representation of the value zero in that
> type."
>
> This is marked with change bars in recent PDFs so I suspect it is the
> result of a clarification. But of what? Unsigned integer values are
> represented with two sets of bits: values bits and padding bits. On a
> machine with no padding bits, the above produces a value of 0. On one
> with padding bits there are two possibilities. if there are no trap
> representations (the padding bits are just that -- pure padding) then,
> again a value of zero is guaranteed.

Agreed - if indeed unsigned char must have no padding

> Only on a machine with some trap
> representations could the above code not produce a value of zero. It
> is very unlikely that all bits zero would be a trap rep. (the only one
> I have ever seen uses a parity bit) and it seems the committee has
> clarified that this daft case is to be ruled out.
>
> RH's point was something else altogether

That's why my a propos question was with the subject changed
-- 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).

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?
[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?]

I.e.
>
> void *a;;
> memset_as_above(&a, 0, sizeof a);
> if (a == 0) {
> /* not guaranteed */

//Which is correct but implies
{
void **pNULL = 0;
if(a==*pNULL) {
/* not guaranteed */
}
} //Weird!..
> }
>
> I would not be seriously concerned about code that makes this
> assumption, but one can always test it at run time to be sure. On my
> personal nervousness scale, this one is very low down.
>

 
Reply With Quote
 
Ark Khasin
Guest
Posts: n/a
 
      11-03-2007
Richard wrote:
> Ark Khasin <(E-Mail Removed)> writes:
>
>> Richard Heathfield wrote:
>> <snip>
>>> The memset function can be (isn't!, but can legally be) implemented
>>> like this:
>>>
>>> #include <stddef.h>
>>> void *memset(void *s, int c, size_t n)
>>> {
>>> unsigned char *p = s;
>>> while(n--)
>>> {
>>> *p++ = c;
>>> }
>>> return s;
>>> }
>>>

>> <snip>
>>> would merely have set the object representation to all-bits-zero,
>>> without any attempt whatsoever to address the question of which
>>> value the object would have afterwards.
>>>

>> As a practitioner, I didn't think twice to clear all bits with memset
>> clones including the likes of the code above. But now this post scared
>> me: if unsigned char has padding bits in its representation (which I

>
> Scarey isn't it. The explanations given here confuse the newbie no end
> because they include the instances of extinct system and a tiny minority
> of systems which feature all sorts of hocus pocus. You know "a NULL
> pointer is not necessarily all bit 0s" for example.....
>
> or
>
> p=0; /* p is not necessarily equal to zero */
>
>
>> guess is allowed) then what do I get?
>> unsigned a;
>> memset_as_above(&a, 0, sizeof(a));
>> Will a necessarily compare equal to 0?

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?
 
Reply With Quote
 
Richard
Guest
Posts: n/a
 
      11-03-2007
Ark Khasin <(E-Mail Removed)> writes:

> Richard wrote:
>> Ark Khasin <(E-Mail Removed)> writes:
>>
>>> Richard Heathfield wrote:
>>> <snip>
>>>> The memset function can be (isn't!, but can legally be) implemented
>>>> like this:
>>>>
>>>> #include <stddef.h>
>>>> void *memset(void *s, int c, size_t n)
>>>> {
>>>> unsigned char *p = s;
>>>> while(n--)
>>>> {
>>>> *p++ = c;
>>>> }
>>>> return s;
>>>> }
>>>>
>>> <snip>
>>>> would merely have set the object representation to all-bits-zero,
>>>> without any attempt whatsoever to address the question of which
>>>> value the object would have afterwards.
>>>>
>>> As a practitioner, I didn't think twice to clear all bits with memset
>>> clones including the likes of the code above. But now this post scared
>>> me: if unsigned char has padding bits in its representation (which I

>>
>> Scarey isn't it. The explanations given here confuse the newbie no end
>> because they include the instances of extinct system and a tiny minority
>> of systems which feature all sorts of hocus pocus. You know "a NULL
>> pointer is not necessarily all bit 0s" for example.....
>>
>> or
>>
>> p=0; /* p is not necessarily equal to zero */
>>
>>
>>> guess is allowed) then what do I get?
>>> unsigned a;
>>> memset_as_above(&a, 0, sizeof(a));
>>> Will a necessarily compare equal to 0?

> 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?


More sharing your "scared" comment. It's easy to forget to think these
things out and these are things that some C programmer go their entire
lives without realising exist.
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      11-03-2007
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.

 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      11-03-2007
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>

 
Reply With Quote
 
Ark Khasin
Guest
Posts: n/a
 
      11-03-2007
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
assigning "const char *" to "char *" thomas C++ 8 08-21-2012 01:32 PM
C: assigning values to arrays inside structures nflemming2004 C Programming 0 06-09-2008 11:13 PM
assigning const char* to char* Peithon C Programming 6 06-01-2007 08:20 PM
(const char *cp) and (char *p) are consistent type, (const char **cpp) and (char **pp) are not consistent lovecreatesbeauty C Programming 1 05-09-2006 08:01 AM
/usr/bin/ld: ../../dist/lib/libjsdombase_s.a(BlockGrouper.o)(.text+0x98): unresolvable relocation against symbol `std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostre silverburgh.meryl@gmail.com C++ 3 03-09-2006 12:14 AM



Advertisments