in which form real and integer values are saved in memory

[manish sahu]

in memory characters are stored in form of ascii values

my question is that
Is it also true for integer value if yes how??
also true for real (float and double) values??

 

[Ben Pfaff]

in memory characters are stored in form of ascii values

my question is that
Is it also true for integer value if yes how??
also true for real (float and double) values??

No, integers and reals are usually not stored in memory as ASCII
values.

 

[Keith Thompson]

No, integers and reals are usually not stored in memory as ASCII
values.

And characters aren't *necessarily* stored as ASCII values either.

 

[Ed Prochak]

in memory characters are stored in form of ascii values

my question is that
Is  it also true for integer value   if yes how??
also true for real (float and double) values??

In memory, characters, integers, float, etc. are stored in machine
representation.

characters may be ASCII, UNICODE, EBCDIC, or others

intergers may be big endian or little endian, ones complement or twos
complement, BCD or others.

other numeric values (Float,...) may use internal formats that are
specific to the processor, or the math coprocessor, or some standard
like IEEE floating point formats. (It might even be stored as strings
of digits for some applications.)

The question is: Why do you care?

Ed

 

[Richard Bos]

in memory characters are stored in form of ascii values

This is not necessarily true. _Most_ implementations store characters as
ASCII values, but other encodings are allowed (EBCDIC, for example; or
Unicode).

my question is that
Is it also true for integer value if yes how??
also true for real (float and double) values??

Why on earth would you store a floating point value as ASCII values?

No, integer types are stored as a binary number, and floating point
values are stored as, surprise, a floating point number. How exactly
these are stored in memory depends on the implementation, but the
Standard guarantees this:

For integer types,
- exactly one sign bit, if and only if it's a signed type;
- a number of value bits, each of which represents one position in the
corresponding binary representation;
- possibly a number of padding bits, which do not contribute to the
value of the number. (Most implementations have no padding bits, but
they're allowed to. And padding bits may contribute to trap
representations.)
Nothing is said of how these bits are arranged within the bytes that
make up an integer value, but obviously little- and big-endian are the
most common.

For floating point types, nothing at all is defined about the layout of
the value in memory, but the following is said of what makes up that
value:
- there is a sign;
- there is a base, which must be integer (_not_ a C integer value, but
a conceptual integer underlying the type) and >1, _and_ this base is
the same for all floating types within this implementation;
- there is an exponent, which is also integer and must lie between a
given minimum and maximum value which may differ between types;
- there is a precision, which is the number of base-b digits in the
significand, and which may vary between types;
- there are the significand digits;
- all the above make up the floating point value in a way which is too
complicated to get across reliably in a Usenet post, but which can
be found in any reasonable textbook which covers FP math.
As you can see, the base, the size of the exponent, and the precision,
i.e. the size of the significand part, are fixed within the type, and
therefore need not be represented within each floating point number's
value. Surprisingly enough, though, they're allowed to be (though I know
of no implementation which does so).
As you can also see, the values of the sign, exponent, and significand
digits _do_ vary between individual FP values, and must therefore be
encoded within the FP representation. But, I repeat, the Standard
demands _nothing_ about how they are encoded. As with integers, most
implementations will use one of a limited common formats (usually some
form of IEC 60559, I think), and even those that don't will generally
use base 2 or 16, not 3 or 37.

One other thing: for all of the above, the Standard guarantees minimum
values, but not maxima. For example, a short int must be able to hold at
least the values -32767 to 32767, and the exponent of any floating point
number must be able to run to at least 37. But any implementation is
allowed to admit greater values.

Most importantly, though: if you have to ask this question, you should
not need to know the answer. Let the implementation take care of how it
arranges your longs doubles in memory; you should care only of their
values, and their sizes in bytes - and the latter only for memory
allocation and copying.

Richard

 

[Ben Pfaff]

intergers may be big endian or little endian, ones complement or twos
complement, BCD or others.

I don't think that BCD is a valid representation for C integer
types.

 

[Richard Bos]

intergers may be big endian or little endian, ones complement or twos
complement, BCD or others.

No, not BCD. It must be a pure binary representation, which BCD isn't.

Richard

 

[osmium]

"manish sahu" wqrote:

in memory characters are stored in form of ascii values

my question is that
Is it also true for integer value if yes how??
also true for real (float and double) values??

Wikipedia is often a very good place to get answers to questions such as
that. This link might be helpful, too:
http://c-faq.com/~scs/cclass/progintro/sx5.html

 

[John Bode]

in memory characters are stored in form of ascii values

Or EBCDIC. Or Unicode. Or some other scheme.

my question is that
Is  it also true for integer value   if yes how??
also true for real (float and double) values??

Here's a starting point: http://en.wikipedia.org/wiki/Computer_numbering_formats

Note this is not specific to C.

 

[Keith Thompson]

Or EBCDIC. Or Unicode. Or some other scheme.

[...]

Note that Unicode is not an encoding. There are several encodings
used with Unicode, such as UTF-8 and UCS-4.

 

[Charlton Wilbur]

BP> I don't think that BCD is a valid representation for C integer
BP> types.

....unless there's no way for a conforming program to know the
difference.

Charlton

 

[Keith Thompson]

BP> I don't think that BCD is a valid representation for C integer
BP> types.

...unless there's no way for a conforming program to know the
difference.

It would be difficult to arrange that, though not impossible.

A strictly conforming program can store a value in an int object,
then interpret it as an array of unsigned char and test whether the
resulting sequence of values conforms to the standard's requirements.
Its output can't depend on the implementation-defined details;
if it does, then the program isn't strictly conforming. But it
can perform some tests and print a yes/no result.

And considering just unsigned char, it must be the case that
UCHAR_MAX == (1<<CHAR_BIT)-1 (i.e., unsigned char must act like it
has a pure binary representation with no padding bits) -- though
it might not be possible to evaluate that expression in that form
if CHAR_BIT is sufficiently large.

A compiler *could* generate code that goes through whatever
gymnastics are needed to make a BCD representation look like it
satisfies the standard's requirements, but it would be much easier
just to implement binary in the first place.

On the other hand, if there were any currently significant hardware
that supports BCD but not pure binary, there would likely be a
non-conforming C implementation for it -- and the standard might
eventually be updated to allow for a conforming implementation.
But that's not likely to happen.

 

[Kaz Kylheku]

in memory characters are stored in form of ascii values

What is an ``ascii value''? It is a bit pattern which is assigned to a
character by a convention, associating the character as understood by humans
with a computer code.

For instance the picture made with three sticks in the shape of a classic roof
is the first letter of the Roman alphabet: A.

This shape is a glyph (character-picture) which, through the USASCII code, is
associated with the number 65. (Through other codes like EBCDIC it is
associated with a different number). Thus relationship between A and 65 is that
65 is a kind of ``value'' of A in the USASCII character set. Further, this
value 65 has a 7 bit encoding as the bit pattern 01000001. This is the ASCII
encoding of A.

my question is that
Is it also true for integer value if yes how??

An integer is not a character, but a number. Numbers themselves are not
understood to be characters (but the digit glyphs used to write them are
characters). Character sets like USASCII do not assign code values to numbers,
but to characters. So, consequently, numbers do not have an ``ASCII value''.

The digit glyphs 0 through 9 /are/ characters, used to write numbers (for
instance using the decimal system), together with other symbols like +, -,
comma and period.

If that is what you are asking, C programs do not store numbers in this printed
representation. C programs store signed, positive integer values in a binary
form according to the usual binary enumeration based on powers of two. The bit
after the highest bit is treated specially; it is involved in the
representation of negative numbers.

Negative integers are represented using one of three ways: two's complement (by
far the most common and nearly ubiquitous), one's complement and
sign-magnitude. In all these representations, a positive number has a 0 value
in its sign bit, and a negative number has a 1 in the sign bit. One's
complement and sign-magnitude representations have two ways of encoding zero,
one with a 1 sign bit, and one with a 0 sign bit.

Unsigned integers use a binary enumeration and do not have a sign bit.

So, for instance, the number 12345 is not stored as the characters "12345",
but rather the bit pattern 00 ... 11000000111001. The ... ellipses indicate
that the bit pattern is padded with zeros to the width of the underlying type.
The leftmost zero is the sign bit; since 12345 is positive, that bit is zero.

The actual encoding of this 00 ... 11000000111001 value in memory may be more
complicated. The bit pattern is chopped up into bytes. The division into bytes
might be inexact, leaving extra padding bits that are not part of the value.
The bytes are then stored in memory in some order, which could be least
significant to most, most significant to least, or some other order.

There do exist encodings for numbers which closely resemble the printed decimal
representation. For instance there is an encoding, or family of encodings, for
numbers called BCD: binary coded decimal. In this encoding, numbers are stored
as digit characters, encoded in four bits each. The bit pattern 0000 stands for
the digit 0, and 1001 stands for the digit 9. But of course this encoding is
not ASCII.

The BCD representation is suitable for situations where the computer must
reproduce exact decimal arithmetic, particularly where fractional numbers
are involved: such as financial calculations.

also true for real (float and double) values??

Floating-point numbers use a floating-point representation made up of three
parts: a sign bit, an exponent, and a mantissa (the significant digits).

 

[jameskuyper]

It would be difficult to arrange that, though not impossible.

A strictly conforming program can store a value in an int object,
then interpret it as an array of unsigned char and test whether the
resulting sequence of values conforms to the standard's requirements.
Its output can't depend on the implementation-defined details;
if it does, then the program isn't strictly conforming. But it
can perform some tests and print a yes/no result.

And considering just unsigned char, it must be the case that
UCHAR_MAX == (1<<CHAR_BIT)-1 (i.e., unsigned char must act like it
has a pure binary representation with no padding bits) -- though
it might not be possible to evaluate that expression in that form
if CHAR_BIT is sufficiently large.

It would have to be done in a very fundamental fashion: use groups of
3 BCD digits stored in three 4-bit nibbles, to emulate an unsigned
char type; it might as well have a range of 0-511, corresponding to
CHAR_BIT==9, wasting only 25% of the underlying 12 bits of storage
space. Bitwise operations would be implemented in terms of the
emulated 9-bit type, not in terms of the actual bits of the underlying
BCD implementation. All operations involving other types would have to
be converted to corresponding operations, working in accordance with
the requirements of the C standard, on these emulated unsigned char
objects.

On a machine with native support only for BCD arithmetic, It would be
horribly inefficient, and rather pointless, but it could be done.

 

[Ed Prochak]

No, not BCD. It must be a pure binary representation, which BCD isn't.

Richard

Hadn't thought that. Good to learn something new.

 

[Nick Keighley]

manish sahu wrote:

     On some systems, yes, but not on all.

I suspect hardly any use pure ASCII. ASCII is a 7-bit code (the top
bit
is used for parity) and many of the values are reserved for starnge
things like STX and EOH. Even the so-called ASCII machines actually
used some form of extended ASCII.

 Characters are stored as
numeric codes, but what those codes "mean" is mostly unspecified.

<snip>

 

[Keith Thompson]

I suspect hardly any use pure ASCII. ASCII is a 7-bit code (the top
bit
is used for parity) and many of the values are reserved for starnge
things like STX and EOH. Even the so-called ASCII machines actually
used some form of extended ASCII.

[...]

I don't believe the ASCII standard specifies what the 8th bit is used
for. Some systems use it for parity, some use it for other purposes.

Almost all modern character sets are based on ASCII, including
the ISO-8859 series and the various Unicode representations.
There are a few character sets that replace some ASCII characters
with accented letters, but I don't think they're used much anymore.
And of course we'll always have EBCDIC.

 

[Nobody]

Almost all modern character sets are based on ASCII, including
the ISO-8859 series and the various Unicode representations.
There are a few character sets that replace some ASCII characters
with accented letters, but I don't think they're used much anymore.

Those are the ISO-646 character sets (US-ASCII is ISO-646-US).

They are the reason that C has trigraphs, and C99 has digraphs.

They aren't commonly seen in the wild, although there are a lot of legacy
systems using them. You probably won't encounter them unless you work on
bespoke software outside of the US.

[The UK has its own ISO-646-UK dialect, which differs from US-ASCII only
in that the # sign is replaced with £ (sterling). 20 years ago, it
was common to see hardcopy source code listings which started with
"£include <stdio.h>".]

 

[Stephen Sprunk]

I suspect hardly any use pure ASCII. ASCII is a 7-bit code (the top
bit is used for parity) and many of the values are reserved for
starnge things like STX and EOH. Even the so-called ASCII machines
actually used some form of extended ASCII.

[...]

I don't believe the ASCII standard specifies what the 8th bit is used
for. Some systems use it for parity, some use it for other purposes.

IIRC, there was one system that used the extra bit for reverse video,
and another that used it to indicate a space after the current character
as a (very rudimentary) form of compression.

I've never heard that ASCII used the 8th bit for parity, though I can
see where some people might get that idea. Many old async serial lines
had 7 data bits plus an even parity bit (aka 7E1), but there were also
8E1 and 7N2 systems out there and probably other variations. Of course,
8N1 had almost completely taken over by the time async serial lines
disappeared from common use.

Almost all modern character sets are based on ASCII, including
the ISO-8859 series and the various Unicode representations.
There are a few character sets that replace some ASCII characters
with accented letters, but I don't think they're used much anymore.

They're still used in Scandinavia, though UTF-8 is gradually making
inroads as more and more applications support it.

And of course we'll always have EBCDIC.

I was about to say "unfortunately", but then we'd be lacking a good
example of why it's a Bad Idea(tm) to assume all strings will be in
ASCII or at least a superset of ASCII...

S

 

[Tim Rentsch]

in memory characters are stored in form of ascii values

No, integer types are stored as a binary number, and floating point
values are stored as, surprise, a floating point number. How exactly
these are stored in memory depends on the implementation, but the
Standard guarantees this:

For integer types, [snip]

For floating point types, nothing at all is defined about the layout of
the value in memory, but the following is said of what makes up that
value:
- there is a sign;
- there is a base, which must be integer (_not_ a C integer value, but
a conceptual integer underlying the type) and >1, _and_ this base is
the same for all floating types within this implementation;
- there is an exponent, which is also integer and must lie between a
given minimum and maximum value which may differ between types;
- there is a precision, which is the number of base-b digits in the
significand, and which may vary between types;
- there are the significand digits;
- all the above make up the floating point value in a way which is too
complicated to get across reliably in a Usenet post, but which can
be found in any reasonable textbook which covers FP math.
As you can see, the base, the size of the exponent, and the precision,
i.e. the size of the significand part, are fixed within the type,
[snip]

Note that these statements describe only the model used
in the Standard to discuss floating point types. They
aren't requirements on how floating types are actually
represented.