Library bug or my fault?

[jacob navia]

I have used a machine that had trap representations.
It was a 1's complement machine and therefore had a +0
and a -0. Reading a value that contained -0 caused a
trap to occur (I've no idea of the details but it
terminated your program).

<snip>

Can you maybe name an existing machine that shows this
kind of behavior?

 

[Chris Dollin]

Can you maybe name an existing machine that shows this
kind of behavior?

Can you promise that no future machine won't have this
kind of behaviour?

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited registered
no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597
England

 

[jacob navia]

Can you promise that no future machine won't have this
kind of behaviour?

Yes. If it disappeared there was a reason!

 

[Chris Dollin]

If you would care to see the context of the discussion before
starting you would see that the discussion was about accessing
the bits of an uninitialized integer variable.

Angels rush in where fools fear to tread! No, that's not right.
Oops.

In this context
it is obvious that even if the content of the variable is random
the value is an integer!

Isn't that presupposing your conclusion?

when I write

int aFunction(void)
{
int foo;
// Function start
}

At the comment point the value in "foo" is an integer.

At that point "foo" doesn't have a value, as you can tell
in the debugger, which interprets the tag bits for "foo"
as meaning "never set". Assignments to "foo" will set the
tag bits to "has been set", and leaving the scope of
"foo" will set them back to "never set" (or "unbound" or
whatever).

OK, I admit it: not only does your implementation not do this,
I don't have one that does either. But it's clear that an
implementation can -- legally -- do this, and that there are
plausible reasons for having an implementation that can.
(Implementations are, after all, not just the bare machine.)

So claiming that:

At the comment point the value in "foo" is an integer.

assumes that it's legal to interpret "foo" as an integer
bit-pattern: but it isn't, whatever its bits are.

[1] Ha!

 

[jacob navia]

OK, I admit it: not only does your implementation not do this,
I don't have one that does either.

OK. We agree then. There are no implementations that
use some unspecified bits to see if a variable was initialized or not.


lcc-win (with optimization level zero) writes into all those variables
an integer value that is likely to trap if used as a pointer, and
is a NAN if used as a floating point number.

Those types DO have trap representations and accessing an invalid
pointer WILL get trapped by the hardware. I object to the integer
part of this.

 

[Ike Naar]

They exist only on the minds of the regulars here...

As an example, on the Burroughs B6700/7700/7900 (Unisys A series)
mainframe all numbers are represented in a floating point format
("real", in Burroughs jargon).
Integers are reals with a zero exponent.
As a consequence, a bit pattern that has any nonzero bit
in the exponent part is not an integral value.
An attempt to interpret such a pattern as an integral value
results in an 'invalid integer' trap.

Admittedly this is an old-fashioned architecture but it's not impossible
that such a machine is still in operation somewhere.

You are applying logic in comp.lang.c. Note that for most regulars that
is an unknown concept.

According to the stats you're in the top 10 list of frequent posters
in this group. Could that mean you are a regular yourself?
Just curious

Ike

 

[Richard]

jacob navia said:


Well, half-agree, anyway. You agree with your opinion, but he doesn't.


That's not what he said. He said he doesn't have such an implementation.
The fact that two, or three, or even a million people don't have pet
aardvarks does not imply that nobody has a pet aardvark. Furthermore, even
if it could somehow be shown that nobody has a pet aardvark today, that
doesn't imply that nobody will have a pet aardvark tomorrow.

<snip>

But meanwhile in the real world where efficiency and cost effective SW development
is important ...

It's so nice to know that Heathfield's C link list library will run on
HW in 10,000,000 years time.

 

[Walter Roberson]

OK. We agree then. There are no implementations that
use some unspecified bits to see if a variable was initialized or not.

It's all somewhat fuzzy after these years, but if I recall correctly
I did use some very different systems with those properties a
few decades ago. I wasn't programming in C on them myself, but my
understanding is that the C implementations of the day did
respect those properties.

 

[Walter Roberson]

Yes. If it disappeared there was a reason!

Not necessarily a technical reason. See for example the history of
antitrust lawsuits against IBM in the 1970's (a time when technology
was settling down and what would move forward into the future was not
infrequently based upon anti-competitive economic grounds rather than
technical grounds.)

 

[Walter Roberson]

Who cares about machines that do not exist since at least 10 years?
We are discussing a problem in a specific processor here, or at least
in current machines.

A decade old doesn't mean "no productive use". My home and work
desktop machines are both from a line that went end-of-sale more
than a decade ago; there is still an active used market in the
model line. My work has more than once offered me an upgrade to
a MS Windows or Linux PC; I turn them down. With those old
systems I spend remarkably little time "fighting" the operating system
and hardware, because it was very well designed and integrated;
-every- DOS or Windows box I've had, I've had to spend more time
fixing the machine (hardware or software) than using the machine
productively.

 

[jacob navia]

As an example, on the Burroughs B6700/7700/7900 (Unisys A series)
mainframe all numbers are represented in a floating point format
("real", in Burroughs jargon).
Integers are reals with a zero exponent.
As a consequence, a bit pattern that has any nonzero bit
in the exponent part is not an integral value.
An attempt to interpret such a pattern as an integral value
results in an 'invalid integer' trap.

Admittedly this is an old-fashioned architecture but it's not impossible
that such a machine is still in operation somewhere.

http://www.computermuseum.li/Testpage/Burroughs-6700-DP-System.htm
This is a system from the 1960s.

Yes, it is not IMPOSSIBLE that somewhere in the planet, there is still
some B6700 running around using floating point for integers... who
knows?

But since you can't point me to ANY such machine now, I strongly
suspect that when discussing problems in C programming TODAY we should
NOT confuse everyone with obsolete machines.

 

[jacob navia]

jacob navia said:


Well, half-agree, anyway. You agree with your opinion, but he doesn't.

It would be nice if you spoke for yourself. I do not speak
for anyone else. Mr Dollin can say that for himeself

That's not what he said. He said he doesn't have such an implementation.
The fact that two, or three, or even a million people don't have pet
aardvarks does not imply that nobody has a pet aardvark. Furthermore, even
if it could somehow be shown that nobody has a pet aardvark today, that
doesn't imply that nobody will have a pet aardvark tomorrow.

This rubbish is typical of your prose here.

heathfield:

"You have to cross your fingers always BEFORE and AFTER
you enter a house with an impair number in the door."

jacob:
Why? This look quite crazy.

heathfield:
You could be assaulted by the pet aardvarks if you don't!

jacob: What? Those do not exist!

heathfield:

> The fact that two, or three, or even a million people don't have pet
> aardvarks does not imply that nobody has a pet aardvark. Furthermore, even
> if it could somehow be shown that nobody has a pet aardvark today, that
> doesn't imply that nobody will have a pet aardvark tomorrow.
>

THEREFORE:
cross your finger you dammed ignorant. Not all houses are like the
one you live in. There are some WEIRD houses where pet aardvarks loom.

This is pure C.L.C regulars nonsense.

 

[Keith Thompson]

Yes. If it disappeared there was a reason!

So if some future machine uses an integer representation with padding
bits, you will have broken your promise. Fascinating.

 

[jacob navia]

So if some future machine uses an integer representation with padding
bits, you will have broken your promise. Fascinating.

Padding bits are masked by the hardware hence
they can't make a trap unless their value is
scanned by the hardware. But in that case they are not
padding bits.

I know that logic is not the strongest quality of C.L.C regulars
but... please try to follow the above even if it is difficult
ok?

 

[Walter Roberson]

So if some future machine uses an integer representation with padding
bits, you will have broken your promise. Fascinating.

I've heard of some DSPs using the floating point unit for integer
calculations -- saves die "real-estate", especially if integer
calculations are expected to be relatively rare compared to
whatever the DSP is optimized for. I do not, however, have enough
experience to know whether such systems sometimes store integers as a
subset of their floating point format or if they instead always
translate formats on the fly, completely transparently. I would
tend to expect that (copies of?) the values would be left in floating point
format in the floating point registers so as to reduce the overhead
of doing further calculation upon the results.

 

[Ike Naar]

http://www.computermuseum.li/Testpage/Burroughs-6700-DP-System.htm
This is a system from the 1960s.

The B7900 and later Unisys A's are from the eighties.

Yes, it is not IMPOSSIBLE that somewhere in the planet, there is still
some B6700 running around using floating point for integers... who
knows?

But since you can't point me to ANY such machine now, I strongly
suspect that when discussing problems in C programming TODAY we should
NOT confuse everyone with obsolete machines.

My only point was to illustrate that machines, that you claimed only exist
"in the minds of the regulars" exist elsewhere too.

If I cannot point you to "ANY" such machine "TODAY", that does not mean
no such thing exists or will ever exist. In that respect my knowledge is
too limited.

Ike

 

[Keith Thompson]

It would be nice if you spoke for yourself. I do not speak
for anyone else. Mr Dollin can say that for himeself

You attempted to speak for Chris Dollin. You claimed that he agreed
with you, in the absence of any evidence that he actually does.

He said that *he doesn't have* such an implementation. You claimed
that he agreed with your assertion that *no such implementation
exists*.

Do you understand the difference?

For all I know, Chris might actually agree with you that no such
implementation exists, but he hasn't said so here; it's your claim in
the absence of any evidence that I object to.

[snip]

 

[Keith Thompson]

Padding bits are masked by the hardware hence
they can't make a trap unless their value is
scanned by the hardware. But in that case they are not
padding bits.

Do you claim that the above behavior is required for all possible
implementations, or is it merely an example of what you think *should*
be done. If it's merely an example, you could just as well have
asserted that there are no padding bits; that's an equally good
example.

I know that logic is not the strongest quality of C.L.C regulars
but... please try to follow the above even if it is difficult
ok?

Ok. I've tried and failed to follow your argument. Are you arguing
that padding bits cannot exist?

Please re-read C99 6.2.6.2 regarding the representation of integer
types, just to make sure we're both talking about the same thing.
Perhaps you're using the phrase "padding bits" with a different
meaning that what's defined by the standard. If so, please clarify
what you mean, and please consider using a different term.

What exactly do you mean when you say that padding bits are "masked by
the hardware"?

Consider a hypothetical implementation with the following
characteristics:

CHAR_BIT == 8
sizeof(int) == 4 (32 bits)
INT_MIN == -8388608 (-2**23)
INT_MAX == +8388607 (+2**23-1)

Type int has 1 sign bit, 23 value bits, and 8 padding bits.

Storing the result of evaluating any arithmetic expression in an int
object causes the object's padding bits to be set to zero. (This can
be verified by interpreting the object's representation as an array of
unsigned char.) Evaluating the value of an object with non-zero
padding bits causes immediate termination of the program.

I know of no actual system that has the above characteristics; that's
not the point. I do not claim that such a system is likely to be
built in the future; that's not the point either (though there could
be legitimate reasons, reasons I haven't thought of, to build such a
system). The point is that such a system conforms to the C standard,
and there *could* be some future system that does exhibit the
characteristics I've described.

Do you agree? If so, doesn't that contradict your statement about
padding bits being "masked by the hardware"? If you don't agree, why
not?

I understand that you personally dislike the "regulars", of whom I am
one; as you wrote in another thread, "I am completely opposed to that
people". In replying to this, please try to get past your personal
animosity and respond to what I actually wrote.

 

[jacob navia]

The fact that two, or three, or even a million people don't have machines
that can have integer trap representations does not imply that nobody has
a machine that can have integer trap representations. Furthermore, even if
it could somehow be shown that nobody has a machine that can have integer
trap representations today, that doesn't imply that nobody will have a
machine that can have integer trap representations tomorrow.

Is that clearer? Or don't you understand that, either?

Of course I understand it:

"I can confuse everyone with bogus machines as long as I want to
because I do not need to have any relationship with reality. I can
*just invent* a possible machine with the characteristics I desire
so that I can go on confusing issues, making stupid assertions
about things that are legal or not, etc."

I understand it 100%. I just think that you are well, just
spraying nonsense (as most of the time)

 

[Randy Howard]

Of course I understand it:

"I can confuse everyone with bogus machines as long as I want to
because I do not need to have any relationship with reality. I can
*just invent* a possible machine with the characteristics I desire
so that I can go on confusing issues, making stupid assertions
about things that are legal or not, etc."

I understand it 100%. I just think that you are well, just
spraying nonsense (as most of the time)

Why do you spend so much time and energy trying to defend suspect code?
Is it just because you live and breathe for the chance to disagree
with "the evil regulars", or do you truly believe that analyzing the
contents of uninitialized variables is useful?