Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

Assigning values to char arrays

 
 
Ben Bacarisse
Guest
Posts: n/a
 
      11-07-2007
James Kuyper <(E-Mail Removed)> writes:

> Ben Bacarisse wrote:
> ...
>> If section 6.2.6 was called "Object representation of types" so that
>> it was unambiguously about how values are stored and nothing else,
>> then I believe '-1 | -2' would be undefined. If values, not stored in
>> objects, do not have a representation, then what "bits" are there to
>> or together? It is because values may be represented as collections
>> of bits (as it happens in three different ways) that such expressions
>> can have a meaning defined by combining "corresponding bits".

>
> 6.5p4 says "Some operators (the unary operator ~, and the binary
> operators <<, >>, &, ^, and |, collectively described as bitwise
> operators) are required to have operands that have integer type. These
> operators yield values that depend on the internal representations of
> integers, and have implementation-defined and undefined aspects for
> signed types".
>
> As I understand it, that statement about the "internal
> representations" refers to the object representation, and does not
> imply that the standard attaches any meaning to the representation of
> a value that is not currently stored in any C object.


I can accept that this is the intent, but I do not think it is clear
and unambiguous. Since it can't be detected by a C program, I don't
really care if there is one representation (when a value is stored) or
another, transient one, as well. The latter just seemed to me a
convenient expository device for exactly these cases, but if it is a
fiction of my imagination, so be it!

> It merely
> requires that the bitwise operators act on values in such a way that
> if the resulting value were saved in an object of that value's type,
> it would have the correct bit pattern.
>
> ...
>> I have no other citation than the definition I already cited. I agree
>> the distinction is not crystal clear, but if your reading of the words
>> is that there is essentially no difference between "representation"
>> and "object representation" then how do you give '-1 | -2' a meaning?
>> You could, of course, say that | (and friends) behaves as if its
>> operands where stored in objects and the corresponding bits are
>> combined together, but you'd *still* be referencing the allowed
>> representations.

>
> That's exactly how I understand it. I never denied that the allowed
> representations were referenced,


Well that was exactly what I thought you were doing when you said:

"In general, the bitwise operations are defined in terms of their
actions on the values, not the representations."

I just can't square this with your last remark above. For four of the
six, the representation is a required part of the definition.

> only that the concept of a
> representation of a value only aquires a meaning in the event that it
> is stored in an object.



--
Ben.
 
Reply With Quote
 
 
 
 
Chris Torek
Guest
Posts: n/a
 
      11-07-2007
(comp.std.c would probably be a better group for this...)

In article <(E-Mail Removed)>,
Ben Bacarisse <(E-Mail Removed)> wrote:
>The section called "Representation of types" includes information
>which I think is required in order to put a meaning to expressions
>like '-1 | -2'. ...
>If section 6.2.6 was called "Object representation of types" so that
>it was unambiguously about how values are stored and nothing else,
>then I believe '-1 | -2' would be undefined. If values, not stored in
>objects, do not have a representation, then what "bits" are there to
>or together? ...


Indeed. I suspect that the reason the wording in the Standard is
so fuzzy is that various committee members are aware, either
explicitly or via that "something fishy feeling" in the back of
the mind, that there are some situations on some machines where
the representations of values as stored in objects (i.e., in RAM)
differ in some way from the representations when not "stored in
objects" (i.e., loaded into registers).

The most classic and accessible example today occurs on the x86
architecture, when dealing with floating-point values. These are
stored as 4, 8, or 12-byte representations in RAM, but when loaded
into the FPU stack for doing arithmetic, are kept internally as
80-bit (10-byte) representations. Clearly, the "in-register"
version is never quite the same as any "in-memory" version (though
the 10/12 conversions are entirely straightforward). Fortunately,
C forbids using the bitwise operators on floating point values, so
C programmers never[%] see this.

[% What, never? Well, hardly ever. I have an example in
<http://web.torek.net/torek/c/numbers.html> where the difference
shows up, depending on compiler optimizations and/or flags like
gcc's -ffloat-store.]

Ultimately, the fact is that "values" have representations (possibly
more than one for any given value), and "values stored into memory"
(whose address is then taken with the unary "&" operator) have
"object representations" in RAM, but these need not be quite the
same. The bitwise operators (binary &, |, and ^) work with "value
representations". On modern CPUs, the value representations and
object representations usually match (with the exception of x86
floating point, anyway), so that one need not be concerned about
this. It takes unusual circumstances -- such as using a V9 SPARC's
MMU to invert the endianness on some but not all pages in a given
process -- to make all the distinctions apparent.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      11-08-2007
Chris Torek <(E-Mail Removed)> writes:

> (comp.std.c would probably be a better group for this...)
>
> In article <(E-Mail Removed)>,
> Ben Bacarisse <(E-Mail Removed)> wrote:
>>The section called "Representation of types" includes information
>>which I think is required in order to put a meaning to expressions
>>like '-1 | -2'. ...
>>If section 6.2.6 was called "Object representation of types" so that
>>it was unambiguously about how values are stored and nothing else,
>>then I believe '-1 | -2' would be undefined. If values, not stored in
>>objects, do not have a representation, then what "bits" are there to
>>or together? ...

>
> Indeed. I suspect that the reason the wording in the Standard is
> so fuzzy is that various committee members are aware, either
> explicitly or via that "something fishy feeling" in the back of
> the mind, that there are some situations on some machines where
> the representations of values as stored in objects (i.e., in RAM)
> differ in some way from the representations when not "stored in
> objects" (i.e., loaded into registers).
>
> The most classic and accessible example today occurs on the x86
> architecture, when dealing with floating-point values. These are
> stored as 4, 8, or 12-byte representations in RAM, but when loaded
> into the FPU stack for doing arithmetic, are kept internally as
> 80-bit (10-byte) representations. Clearly, the "in-register"
> version is never quite the same as any "in-memory" version (though
> the 10/12 conversions are entirely straightforward). Fortunately,
> C forbids using the bitwise operators on floating point values, so
> C programmers never[%] see this.


Interesting example. Thanks.

<snip>
> Ultimately, the fact is that "values" have representations (possibly
> more than one for any given value), and "values stored into memory"
> (whose address is then taken with the unary "&" operator) have
> "object representations" in RAM, but these need not be quite the
> same. The bitwise operators (binary &, |, and ^) work with "value
> representations".


Well I am glad I am not alone in thinking the wording is deliberate
and suggests the existence of a representation that is not simply the
object representation.

--
Ben.
 
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