Most negative double value

[Peter Ammon]

What's the most negative double value I can get? Is it always
guaranteed to be -DBL_MAX? If so, why (or rather, where)?

Thanks.

[Malcolm]

"Peter Ammon" <pe*********@rocketmail.com> wrote in message

What's the most negative double value I can get? Is it always
guaranteed to be -DBL_MAX? If so, why (or rather, where)?

Most floating point formats have a negative flag bit which can be set or
unset. The most natural system is for the maximum and minimum to be of the
same magnitude.

[Papadopoulos Giannis]

Peter Ammon wrote:

What's the most negative double value I can get? Is it always
guaranteed to be -DBL_MAX? If so, why (or rather, where)?

Thanks.

It is DBL_MIN and it is always -DBL_MAX in IEEE-754 compliant systems..

--
#include <stdio.h>
#define p(s) printf(#s" endian")
int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.

[Peter Ammon]

Papadopoulos Giannis wrote:

Peter Ammon wrote:

What's the most negative double value I can get? Is it always
guaranteed to be -DBL_MAX? If so, why (or rather, where)?

Thanks.

It is DBL_MIN and it is always -DBL_MAX in IEEE-754 compliant systems..

DBL_MIN on my platform is 2.2250738585072014e-308 which is positive.

--
Pull out a splinter to reply.

[Papadopoulos Giannis]

Peter Ammon wrote:

Papadopoulos Giannis wrote:

Peter Ammon wrote:

What's the most negative double value I can get? Is it always
guaranteed to be -DBL_MAX? If so, why (or rather, where)?

Thanks.

It is DBL_MIN and it is always -DBL_MAX in IEEE-754 compliant systems..

DBL_MIN on my platform is 2.2250738585072014e-308 which is positive.

F**K.....
I should never post again after 02:00 in the morning...

Yes, the most negative value is -DBL_MAX...
The smallest positive is DBL_MIN...

A big sorry...

--
#include <stdio.h>
#define p(s) printf(#s" endian")
int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.

[Christian Bau]

In article <c1**********@ulysses.noc.ntua.gr>,
Papadopoulos Giannis <ip******@inf.uth.gr> wrote:

#include <stdio.h>
#define p(s) printf(#s" endian")
int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}

You are aware that this is nonsense?

If not, then think about it for five minutes before you respond.

[CBFalconer]

Peter Ammon wrote:

Papadopoulos Giannis wrote:

Peter Ammon wrote:

What's the most negative double value I can get? Is it always
guaranteed to be -DBL_MAX? If so, why (or rather, where)?

It is DBL_MIN and it is always -DBL_MAX in IEEE-754 compliant systems..

DBL_MIN on my platform is 2.2250738585072014e-308 which is positive.

Which is apparently correct. From N869:

[#10] The values given in the following list shall be
replaced by implementation-defined constant expressions with
(positive) values that are less than or equal to those
shown:

-- the difference between 1 and the least value greater
than 1 that is representable in the given floating
point type, b1-p

FLT_EPSILON 1E-5
DBL_EPSILON 1E-9
LDBL_EPSILON 1E-9

-- minimum normalized positive floating-point number,
bemin-1

FLT_MIN 1E-37
DBL_MIN 1E-37
LDBL_MIN 1E-37

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Dan Pop]

In <c1**********@news.apple.com> Peter Ammon <pe*********@rocketmail.com> writes:

What's the most negative double value I can get? Is it always
guaranteed to be -DBL_MAX?
Yes.
If so, why (or rather, where)?

Because the standard uses a sign-magnitude model for the floating point
numbers. 5.2.4.2.2 in C99. Sorry, but the text is next to impossible
to quote in plain text format, without using some special convention,
a la TeX and friends.

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

[Papadopoulos Giannis]

Christian Bau wrote:

In article <c1**********@ulysses.noc.ntua.gr>,
Papadopoulos Giannis <ip******@inf.uth.gr> wrote:

#include <stdio.h>
#define p(s) printf(#s" endian")
int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}

You are aware that this is nonsense?

If not, then think about it for five minutes before you respond.

Please explain...

--
#include <stdio.h>
#define p(s) printf(#s" endian")
int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.

[Christian Bau]

In article <c1**********@ulysses.noc.ntua.gr>,
Papadopoulos Giannis <ip******@inf.uth.gr> wrote:

Christian Bau wrote:

In article <c1**********@ulysses.noc.ntua.gr>,
Papadopoulos Giannis <ip******@inf.uth.gr> wrote:

#include <stdio.h>
#define p(s) printf(#s" endian")
int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}

You are aware that this is nonsense?

If not, then think about it for five minutes before you respond.

Please explain...

Do you think that bigendian and littleendian are the only possibilities?
Could the char that you are reading consist completely of padding bits
in the int, in which case you could get two different results when you
run the program twice?

[Old Wolf]

> > >>#include <stdio.h>

>#define p(s) printf(#s" endian")
>int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}
You are aware that this is nonsense?

If not, then think about it for five minutes before you respond.

Please explain...

Do you think that bigendian and littleendian are the only possibilities?
Could the char that you are reading consist completely of padding bits
in the int, in which case you could get two different results when you
run the program twice?

Do you think that "endianness-detector" is the only possibility
for the purpose of this program? It could in fact be a random
greeting program in Martian, or a pedant-trapper, or a
compiler test, or pretty much anything really.

[Papadopoulos Giannis]

Christian Bau wrote:

Do you think that bigendian and littleendian are the only possibilities?
No, but I believe that are the most common ones..
Could the char that you are reading consist completely of padding bits
in the int, in which case you could get two different results when you
run the program twice?

I think if I change *(char*)&v to *(char*)&v==1 I can rid of it.. Or
don't I??

PS If the code below does not work (and I have come across it many
times, in books and the Inet), then what should??

--
#include <stdio.h>
#define p(s) printf(#s" endian")
int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.

[Peter Ammon]

Dan Pop wrote:

In <c1**********@news.apple.com> Peter Ammon <pe*********@rocketmail.com> writes:

What's the most negative double value I can get? Is it always
guaranteed to be -DBL_MAX?

Yes.

If so, why (or rather, where)?

Because the standard uses a sign-magnitude model for the floating point
numbers. 5.2.4.2.2 in C99. Sorry, but the text is next to impossible
to quote in plain text format, without using some special convention,
a la TeX and friends.

Dan

There it is! Thanks.

-Peter

--
Pull out a splinter to reply.

[Christian Bau]

In article <c1***********@ulysses.noc.ntua.gr>,
Papadopoulos Giannis <ip******@inf.uth.gr> wrote:

Christian Bau wrote:

Do you think that bigendian and littleendian are the only possibilities?

No, but I believe that are the most common ones..

Could the char that you are reading consist completely of padding bits
in the int, in which case you could get two different results when you
run the program twice?

I think if I change *(char*)&v to *(char*)&v==1 I can rid of it.. Or
don't I??

PS If the code below does not work (and I have come across it many
times, in books and the Inet), then what should??

The pragmatic solution is to add an appropriate #define into some header
file. Also helpful is to write code that doesn't depend on endianness in
the first place: For example, to write a value x up to 2^32 to a file,
write the bytes (x >> 24) & 0xff, (x >> 16) & 0xff, (x >> 8) & 0xff, x &
0xff and you will get the same results everywhere.

C doesn't even say that there is such a thing as a "byte ordering": If
for example int has 16 bit, char has 8 bit, and sizeof (int) == 2, then
the 16 bits of an int could be mapped in any possible permutation to the
16 bits in an array of two chars.

[Christian Bau]

In article <84**************************@posting.google.com >,
ol*****@inspire.net.nz (Old Wolf) wrote:

>>#include <stdio.h>
>>#define p(s) printf(#s" endian")
>>int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}
>
>
> You are aware that this is nonsense?
>
> If not, then think about it for five minutes before you respond.

Please explain...

Do you think that bigendian and littleendian are the only possibilities?
Could the char that you are reading consist completely of padding bits
in the int, in which case you could get two different results when you
run the program twice?

Do you think that "endianness-detector" is the only possibility
for the purpose of this program? It could in fact be a random
greeting program in Martian, or a pedant-trapper, or a
compiler test, or pretty much anything really.

If you read the next reply of the original poster, you will find that it
is an "endianness-detector".

[Papadopoulos Giannis]

Christian Bau wrote:

The pragmatic solution is to add an appropriate #define into some header
file. Also helpful is to write code that doesn't depend on endianness in
the first place: For example, to write a value x up to 2^32 to a file,
write the bytes (x >> 24) & 0xff, (x >> 16) & 0xff, (x >> 8) & 0xff, x &
0xff and you will get the same results everywhere.
Yes, this is right if I am writing robust code to run everywhere... On
the other hand this is a really simple (and maybe stupid) program that
tries to find machine endianess and is part of my signature...
C doesn't even say that there is such a thing as a "byte ordering": If
for example int has 16 bit, char has 8 bit, and sizeof (int) == 2, then
the 16 bits of an int could be mapped in any possible permutation to the
16 bits in an array of two chars.

OK, but all the great minds of processor design have come to the
conclusion that the 16bit integer will be represented in either big
endian or little endian...

PS even with padding bits, I think *(char*)&v==1 should do the trick...
comments?

--
#include <stdio.h>
#define p(s) printf(#s" endian")
int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.

[Arthur J. O'Dwyer]

On Mon, 23 Feb 2004, Papadopoulos Giannis wrote:

Christian Bau wrote:

The pragmatic solution is [...]
Yes, this is right if I am writing robust code to run everywhere... On
the other hand this is a really simple (and maybe stupid) program that
tries to find machine endianess and is part of my signature...

I.e., it's not pragmatic or correct. Which will attract attention
in comp.lang.c, because that's the kind of thing we do here. :) If
you don't want comments on your sig, then you should not post your
sig to comp.lang.c.

C doesn't even say that there is such a thing as a "byte ordering": If
for example int has 16 bit, char has 8 bit, and sizeof (int) == 2, then
the 16 bits of an int could be mapped in any possible permutation to the
16 bits in an array of two chars.

OK, but all the great minds of processor design have come to the
conclusion that the 16bit integer will be represented in either big
endian or little endian...

Depends on what you mean by "great minds." I think the PDP-11
has been brought up as a (32-bit) counter-example before... or was
it the PDP-7? I don't know. And anyway, comp.lang.c doesn't care
about processor design, we care about C programming.
PS even with padding bits, I think *(char*)&v==1 should do the trick...
comments?

Wrong. Assuming 'v' is an int, you're invoking undefined behavior
by trying to look at its bits as if they represented a valid 'char'
value. So anything can happen, including nasal demons or wrong
answers.

-Arthur

[Papadopoulos Giannis]

Arthur J. O'Dwyer wrote:

I.e., it's not pragmatic or correct. Which will attract attention
in comp.lang.c, because that's the kind of thing we do here. :) If
you don't want comments on your sig, then you should not post your
sig to comp.lang.c.
I've never said I do not want comments on what I'm writing.. Comments
are always acceptable...
Wrong. Assuming 'v' is an int, you're invoking undefined behavior
by trying to look at its bits as if they represented a valid 'char'
value. So anything can happen, including nasal demons or wrong
answers.

-Arthur

For a 32-bit machine would

union boo {
unsigned int i;
unsigned char c[4];
};

union boo a;

and looking at a.c[0]

be more acceptable??

--
#include <stdio.h>
#define p(s) printf(#s" endian")
int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.

[Arthur J. O'Dwyer]

On Mon, 23 Feb 2004, Papadopoulos Giannis wrote:

Arthur J. O'Dwyer wrote:

I.e., it's not pragmatic or correct. Which will attract attention
in comp.lang.c, because that's the kind of thing we do here. :) If
you don't want comments on your sig, then you should not post your
sig to comp.lang.c.

I've never said I do not want comments on what I'm writing.. Comments
are always acceptable...

Well then, stop trying to justify yourself. ;-) ;-)

Wrong. Assuming 'v' is an int, you're invoking undefined behavior
by trying to look at its bits as if they represented a valid 'char'
value. So anything can happen, including nasal demons or wrong
answers.

For a 32-bit machine would

union boo {
unsigned int i;
unsigned char c[4];
};

union boo a;

and looking at a.c[0]
be more acceptable??

Not from the standard's point of view. Let's assume that by
"32-bit machine" you mean "an implementation on which 'CHAR_BIT'
is 8 and 'sizeof(int)' is 4." Then it is *still* possible that
INT_MAX could be 32767 or 65535 (I think) or some other number,
and a.c[0] could be composed entirely of padding bits and thus
irrelevant to the "endianness" of the machine (whatever that
means in a padding-bits context).

Actually, it would be a *little* more "acceptable"; now that
you've switched to 'unsigned char', the Standard guarantees that
'unsigned char' has no trap representations. Thus what you have
now is either implementation-defined or unspecified behavior,
depending on your interpretation of the Standard (I think); but
not undefined behavior, as it was before.

Anyway, the basic point I guess is that you haven't fully defined
what you mean by "endianness." Sure, there are two or three obvious
"endian" cases, but how do you classify the big gray area including
padding bits and weird bit orders?
If you assume as a prerequisite that the implementation *must*
have either the 1234 or the 4321 byte order, and no padding bits,
then your program works perfectly. But standard C doesn't make that
assumption -- it makes different assumptions such that it is actually
impossible to determine whether a given 'int' is big- or little-endian
in a portable fashion. (I'm fairly sure that's right -- something
like the Halting Problem probably applies somehow.)

HTH,
-Arthur

[Clark Cox]

In article <c1***********@ulysses.noc.ntua.gr>,
Papadopoulos Giannis <ip******@inf.uth.gr> wrote:

Christian Bau wrote:

The pragmatic solution is to add an appropriate #define into some header
file. Also helpful is to write code that doesn't depend on endianness in
the first place: For example, to write a value x up to 2^32 to a file,
write the bytes (x >> 24) & 0xff, (x >> 16) & 0xff, (x >> 8) & 0xff, x &
0xff and you will get the same results everywhere.

Yes, this is right if I am writing robust code to run everywhere... On
the other hand this is a really simple (and maybe stupid) program that
tries to find machine endianess and is part of my signature...

C doesn't even say that there is such a thing as a "byte ordering": If
for example int has 16 bit, char has 8 bit, and sizeof (int) == 2, then
the 16 bits of an int could be mapped in any possible permutation to the
16 bits in an array of two chars.

OK, but all the great minds of processor design have come to the
conclusion that the 16bit integer will be represented in either big
endian or little endian...

PS even with padding bits, I think *(char*)&v==1 should do the trick...
comments?

No, consider a situation where:

char is 8 bits
int is 8 padding bits, followed by 24 value bits

The value of the expression (*(char*)&v) could be anything at all, so
comparing it to 1 is completely useless.

[Christian Bau]

In article <c1***********@ulysses.noc.ntua.gr>,
Papadopoulos Giannis <ip******@inf.uth.gr> wrote:

Christian Bau wrote:

The pragmatic solution is to add an appropriate #define into some header
file. Also helpful is to write code that doesn't depend on endianness in
the first place: For example, to write a value x up to 2^32 to a file,
write the bytes (x >> 24) & 0xff, (x >> 16) & 0xff, (x >> 8) & 0xff, x &
0xff and you will get the same results everywhere.
Yes, this is right if I am writing robust code to run everywhere... On
the other hand this is a really simple (and maybe stupid) program that
tries to find machine endianess and is part of my signature...

C doesn't even say that there is such a thing as a "byte ordering": If
for example int has 16 bit, char has 8 bit, and sizeof (int) == 2, then
the 16 bits of an int could be mapped in any possible permutation to the
16 bits in an array of two chars.

OK, but all the great minds of processor design have come to the
conclusion that the 16bit integer will be represented in either big
endian or little endian...

comp.lang.c is about portable C. Using non-portable C in your signature
on comp.lang.c is not too clever.
PS even with padding bits, I think *(char*)&v==1 should do the trick...
comments?

With padding bits, *(char*)&v might read padding bits and nothing else,
so the result could be anything at all. Of course, if you have padding
bits then you would have to define what you call "bigendian" and what
you call "littleendian" first.

[Christian Bau]

In article <c1***********@ulysses.noc.ntua.gr>,
Papadopoulos Giannis <ip******@inf.uth.gr> wrote:

Arthur J. O'Dwyer wrote:

I.e., it's not pragmatic or correct. Which will attract attention
in comp.lang.c, because that's the kind of thing we do here. :) If
you don't want comments on your sig, then you should not post your
sig to comp.lang.c.

I've never said I do not want comments on what I'm writing.. Comments
are always acceptable...

Wrong. Assuming 'v' is an int, you're invoking undefined behavior
by trying to look at its bits as if they represented a valid 'char'
value. So anything can happen, including nasal demons or wrong
answers.

-Arthur

For a 32-bit machine would

union boo {
unsigned int i;
unsigned char c[4];
};

union boo a;

and looking at a.c[0]

be more acceptable??

That doesn't make the slightest difference. The problem is that the
value bits in the unsigned int could be mapped to the value bits in the
unsigned chars in an arbitrary way.

[Keith Thompson]

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:
[...]

Anyway, the basic point I guess is that you haven't fully defined
what you mean by "endianness." Sure, there are two or three obvious
"endian" cases, but how do you classify the big gray area including
padding bits and weird bit orders?
If you assume as a prerequisite that the implementation *must*
have either the 1234 or the 4321 byte order, and no padding bits,
then your program works perfectly. But standard C doesn't make that
assumption -- it makes different assumptions such that it is actually
impossible to determine whether a given 'int' is big- or little-endian
in a portable fashion. (I'm fairly sure that's right -- something
like the Halting Problem probably applies somehow.)

I hardly think that the Halting Problem is relevant. In the very
worst case, you could iterate over all possible unsigned int values,
viewing each one as an array of unsigned char and testing whether it
matches the sequence you'd get from a straighforward big-endian or
little-endian representation. There are three possibilities:

1. All values are stored as big-endian.
2. All values are stored as little-endian.
3. Something else.

The "something else" case is likely to be rare in practice. That
doesn't mean you can ignore it, but it does mean you can reasonably
write your program so it fails (as early as possible) if the platform
doesn't meet condition 1 or 2.

In fact, I'm fairly sure that you don't need to iterate over all
unsigned int values; the language provides enough guarantees about
binary representation that you can take some significant shortcuts.
(I'm not sure exactly what those shortcuts are.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Christian Bau]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

In fact, I'm fairly sure that you don't need to iterate over all
unsigned int values; the language provides enough guarantees about
binary representation that you can take some significant shortcuts.
(I'm not sure exactly what those shortcuts are.)

If there are no padding bits then all you need to do is store the values
1u << n for 0 <= n < CHAR_BITS * sizeof (unsigned int) and check where
they turn up. If there are padding bits, then it is possible that one of
the padding bits and one of the value bits have the same value whenever
you look at them, so they are impossible to distinguish.

[Papadopoulos Giannis]

Christian Bau wrote:

In article <c1***********@ulysses.noc.ntua.gr>,
Papadopoulos Giannis <ip******@inf.uth.gr> wrote:

Christian Bau wrote:

The pragmatic solution is to add an appropriate #define into some header
file. Also helpful is to write code that doesn't depend on endianness in
the first place: For example, to write a value x up to 2^32 to a file,
write the bytes (x >> 24) & 0xff, (x >> 16) & 0xff, (x >> 8) & 0xff, x &
0xff and you will get the same results everywhere.
Yes, this is right if I am writing robust code to run everywhere... On
the other hand this is a really simple (and maybe stupid) program that
tries to find machine endianess and is part of my signature...

C doesn't even say that there is such a thing as a "byte ordering": If
for example int has 16 bit, char has 8 bit, and sizeof (int) == 2, then
the 16 bits of an int could be mapped in any possible permutation to the
16 bits in an array of two chars.

OK, but all the great minds of processor design have come to the
conclusion that the 16bit integer will be represented in either big
endian or little endian...

comp.lang.c is about portable C. Using non-portable C in your signature
on comp.lang.c is not too clever.

Portable code => good code, but bad logic... :(

PS even with padding bits, I think *(char*)&v==1 should do the trick...
comments?

With padding bits, *(char*)&v might read padding bits and nothing else,
so the result could be anything at all. Of course, if you have padding
bits then you would have to define what you call "bigendian" and what
you call "littleendian" first.

Hmmm, I thought all of this and for the time being I do not see a viable
solution... Looking for a new signature already...

--
Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.

[glen herrmannsfeldt]

Dan Pop wrote:

(someone wrote)

What's the most negative double value I can get? Is it always
guaranteed to be -DBL_MAX?

Because the standard uses a sign-magnitude model for the floating point
numbers. 5.2.4.2.2 in C99. Sorry, but the text is next to impossible
to quote in plain text format, without using some special convention,
a la TeX and friends.

There are machines that use twos complement for floating point,
though I don't like it much.

The PDP-10 uses the twos complement of the entire word for negative
floating point, which apparently allows them to use the integer
compare instructions on float values. Otherwise, it seems strange
to mix the mantissa and exponent bits which can happen in certain cases.

-- glen

[CBFalconer]

glen herrmannsfeldt wrote:

Dan Pop wrote:
(someone wrote)

What's the most negative double value I can get? Is it always
guaranteed to be -DBL_MAX?

Because the standard uses a sign-magnitude model for the floating
point numbers. 5.2.4.2.2 in C99. Sorry, but the text is next to
impossible to quote in plain text format, without using some
special convention, a la TeX and friends.

There are machines that use twos complement for floating point,
though I don't like it much.

The PDP-10 uses the twos complement of the entire word for negative
floating point, which apparently allows them to use the integer
compare instructions on float values. Otherwise, it seems strange
to mix the mantissa and exponent bits which can happen in certain
cases.

Almost 30 years ago I wrote a FP package to use 2's complement.
You can see the result if you can find the Intel 8080 user
contribution library from back then. The complications were
astounding. I rebuilt it the next year to use sign/magnitude with
suppressed leading bit, and things were greatly simplified, and
the performance roughly tripled. Accuracy was also improved.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Dan Pop]

In <ch*********************************@slb-newsm1.svr.pol.co.uk> Christian Bau <ch***********@cbau.freeserve.co.uk> writes:

In article <c1**********@ulysses.noc.ntua.gr>,
Papadopoulos Giannis <ip******@inf.uth.gr> wrote:

Christian Bau wrote:

> In article <c1**********@ulysses.noc.ntua.gr>,
> Papadopoulos Giannis <ip******@inf.uth.gr> wrote:
>
>
>>#include <stdio.h>
>>#define p(s) printf(#s" endian")
>>int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}
>
>
> You are aware that this is nonsense?
>
> If not, then think about it for five minutes before you respond.
Please explain...

Do you think that bigendian and littleendian are the only possibilities?

The only ones worth worrying about on modern hosted implementations.
If these are the only byte orders with a well defined name, there must
be a reason.
Could the char that you are reading consist completely of padding bits
in the int, in which case you could get two different results when you
run the program twice?

Yeah, but the compiler doing it this way takes one million years to
compile the simplest C source code.

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

[Dan Pop]

In <YUE_b.49918$4o.71271@attbi_s52> glen herrmannsfeldt <ga*@ugcs.caltech.edu> writes:

Dan Pop wrote:

(someone wrote)

What's the most negative double value I can get? Is it always
guaranteed to be -DBL_MAX?

Because the standard uses a sign-magnitude model for the floating point
numbers. 5.2.4.2.2 in C99. Sorry, but the text is next to impossible
to quote in plain text format, without using some special convention,
a la TeX and friends.

There are machines that use twos complement for floating point,
though I don't like it much.

Do they have conforming C implementations?

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

[Christian Bau]

In article <m3***************@Claudio.Messina>,
Mark L Pappin <ml*@acm.org> wrote:

Long ago, Papadopoulos Giannis <ip******@inf.uth.gr> sigged:

#include <stdio.h>
#define p(s) printf(#s" endian")
int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}

(and there was much wailing and gnashing of teeth)

Having seen much discussion about differend endinannesses than plain
old "big" and "little", and the possibility of padding bits or
arbitrary bit mappings, I put the following together.

#include <stdio.h>
#include <limits.h>

int main(void)
{
unsigned u = 1;
unsigned failsafe = CHAR_BIT * sizeof u + 1;
while (u && failsafe--) {
unsigned i;
if (!failsafe) {
printf("Odd: u == %x\n",u);
break;
}
for (i = 0; i < sizeof u; i++) {
printf("%s%02x",
i? ":": "",
(unsigned)(((unsigned char*)&u)[i]));
}
putchar('\n');
u <<= 1;
}
return 0;
}

Is there any chance of UB here?

CHAR_BIT could be greater than eight, but %02x will print the number
anyway, so you should be fine.

If you look at the output, you can check all the bits in a
representation and decide:

1. A bit in the representation that was never set or set more than once
is definitely a padding bit. A bit in the representation that was set
exactly once could be a value bit or a padding bit.

2. If in line k of your output bit j is the only bit that is a possible
value bit, then bit j in the representation is the value bit
representing bit k in an unsigned int.

3. With the output of this program, you might not be able to decide
which bit in the representation represents a certain bit in an unsigned
int. That would happen if one padding bit is set only once during
execution of your program.

A sixteen bit unsigned int could be stored in 32 bits with 16 padding
bits, and the hardware could set the padding bits equal to the value
bits except on April 1st. To decide which bits are value bits you would
have to wait until April 1st.