C programming in 2011

[Kleuskes & Moos]

It certainly can be a rhetorical device, and it looked like one in that
context.

It looked to me as if someone was claiming unsigned integers don't
exist, and i wanted to be sure that's what he meant.

I saw no evidence of playing games.

You're responsible for your assessments as i am for mine. If you wanna
play with Willem, go ahead, but I decide who gets what answer from me,
not you.

 The initial evaluation was quite
correct; your argument that program counters require hardware support for
unsigned integers is that you believe program counters to be unsigned
integers.  Nothing prevents a system from having a program counter which
is effectively a signed integer, and using that instead.

Nope, it's possible, as i've stated at least 4 or 5 times already, but
as explained elsethread several times (obviously, everyone wants it
explained personally and nobody reads any post except his own), it
just ain't practical.

So if you want to imagine all kinds of weird and wonderful hardware,
having all kinds of strange restraints and a fairytale design, feel
free, but remember they exist in your imagination only and they are
not as interesting (let alone useful) as you may think.

If you claim otherwise, bring an example.

 

[Angel]

Nope, it's possible, as i've stated at least 4 or 5 times already, but
as explained elsethread several times (obviously, everyone wants it
explained personally and nobody reads any post except his own), it
just ain't practical.

"unsigned integer" is a human interpretation, a computer works only with
bits. You're right in claiming that unsigned int is the most practical
way of making the program counter visible to humans, but the mere
existence of a program counter is no proof that the implementation
supports unsigned integer calculations. Jumps and branches are implemented
in the hardware wiring, not in some arithmetic unit.

 

[James Kuyper]

On 06/03/2011 04:37 AM, Angel wrote:
....

"unsigned integer" is a human interpretation, a computer works only with
bits. You're right in claiming that unsigned int is the most practical
way of making the program counter visible to humans, but the mere
existence of a program counter is no proof that the implementation
supports unsigned integer calculations. Jumps and branches are implemented
in the hardware wiring, not in some arithmetic unit.

The interpretation need not be completely arbitrary. Let's assume, for
the sake of keeping the numbers small, a machine with 32-bit addresses.
Interpreting the addresses as unsigned integers implies that the piece
of memory with an address whose address is 0x7FFFFFFF is "close", in
some sense, to the one whose address is 0x80000000. Interpreting them
with signed integers implies that the memory with an address of -1 is
"close" to the memory with an address of 0. In what sense are they
"close"? That varies from platform to platform, and there doesn't have
to be any meaningful concept of some memory addresses being closer
together than others. However, one way of measuring closeness would be
in terms of how many times you must either decrement or increment an one
address, in order to reach the other address. Keith suggested one
possibility, trapping on overflow, which would make the minimum and
maximum addresses very far apart by this measure. If address arithmetic
traps on overflow, it makes a big difference whether it overflows when
the bit pattern is 0x7FFFFFFF (signed), or 0xFFFFFFFF (unsigned).

If addresses are interpreted as signed integers with 1's complement or
sign-magnitude representations, the consequences are even stronger. The
bit pattern which would represent a negative zero must either be an
invalid address, or a second way of representing the same location in
memory as the bit pattern representing a positive zero.

 

[Angel]

On 06/03/2011 04:37 AM, Angel wrote:
...

The interpretation need not be completely arbitrary. Let's assume, for
the sake of keeping the numbers small, a machine with 32-bit addresses.
Interpreting the addresses as unsigned integers implies that the piece
of memory with an address whose address is 0x7FFFFFFF is "close", in
some sense, to the one whose address is 0x80000000. Interpreting them
with signed integers implies that the memory with an address of -1 is
"close" to the memory with an address of 0. In what sense are they
"close"? That varies from platform to platform, and there doesn't have
to be any meaningful concept of some memory addresses being closer
together than others. However, one way of measuring closeness would be
in terms of how many times you must either decrement or increment an one
address, in order to reach the other address. Keith suggested one
possibility, trapping on overflow, which would make the minimum and
maximum addresses very far apart by this measure. If address arithmetic
traps on overflow, it makes a big difference whether it overflows when
the bit pattern is 0x7FFFFFFF (signed), or 0xFFFFFFFF (unsigned).

If addresses are interpreted as signed integers with 1's complement or
sign-magnitude representations, the consequences are even stronger. The
bit pattern which would represent a negative zero must either be an
invalid address, or a second way of representing the same location in
memory as the bit pattern representing a positive zero.

Good points, I admit. And I guess this confusion that a signed
representation would bring is another reason why interpreting addresses
as unsigned integers makes much more sense to us poor humans.

It's been a long time since I did any assembler programming, but my
understanding was always that relative jumps aren't calculated as such
but hard-wired into the chip. The CPU just counts x steps ahead or back
in binary, regardless of how this binary stuff is later interpreted by
us silly (hexa)decimal-minded humans.

 

[Seebs]

It looked to me as if someone was claiming unsigned integers don't
exist, and i wanted to be sure that's what he meant.

Not claiming they don't exist, just pointing out that your argument that
hardware had to have unsigned integers was to take something hardware
does, and assume that it was unsigned integers.

Nope, it's possible, as i've stated at least 4 or 5 times already, but
as explained elsethread several times (obviously, everyone wants it
explained personally and nobody reads any post except his own), it
just ain't practical.

So you keep saying, but frankly, your explanations have been pretty
much illucid, so far as I can tell.

You're insulting, you don't use the principle of charity when debating,
you don't appear to understand the role of hypotheticals in planning for
unexpected future happenings, and generally you don't make much sense.
*plonk*

-s

 

[Kleuskes & Moos]

Not claiming they don't exist, just pointing out that your argument that
hardware had to have unsigned integers was to take something hardware
does, and assume that it was unsigned integers.


So you keep saying, but frankly, your explanations have been pretty
much illucid, so far as I can tell.

Ok. They were pretty ad hoc, and i'f i had prepared a presentation, i
would certainly have put it differently. But then again, this is
usenet
and i give as much charity as i receive.

What practical use do you see for viewing addresses as signed? If i'm
illucid, then please enlighten me.

You're insulting, you don't use the principle of charity when debating,
you don't appear to understand the role of hypotheticals in planning for
unexpected future happenings, and generally you don't make much sense.

I understand the role of hypotheticals in planning, but then again,
it's
not much use if those hypotheticals are highly implausible.

Illucid or not, so far nobody has shown me to be wrong, which would be
easy if i were illucid, i would think.

*plonk*

Bye.

 

[Angel]

Illucid or not, so far nobody has shown me to be wrong, which would be
easy if i were illucid, i would think.

Actually, showing an illucid person that he is wrong is pretty much
impossible, and discussion with such a person is pointless.

 

[Seebs]

Actually, showing an illucid person that he is wrong is pretty much
impossible, and discussion with such a person is pointless.

Yes, that's rather the central point. At some point, we're down to
arguing with the guy who can prove that pi is exactly 3.125 because you
have to measure it using a circle inscribed in a square exactly 4 units
across*.

-s
[*] Actual example, but probably misremembered.

 

[Keith Thompson]

Illucid or not, so far nobody has shown me to be wrong, which would be
easy if i were illucid, i would think.

Proving you wrong about what? That would require you making a
specific claim with which we disagree.

You've claimed that there are no existing systems that do not support
unsigned integer arithmetic. You're very likely right about that.

You've claimed that it's inconvenient to view addresses as signed
integers, and more convenient to view them as unsigned integers.
Again, I believe that's correct in most cases; I can't really
comment on whether it's correct in all cases.

You respond to statements that UINT_MAX==INT_MAX is possible with
claims that it's not true on any real systems. This does not refute
the original statement.

You've expressed a lack of interest in hypothetical systems.
That's not a falsifiable claim.

If you have a specific claim that you think we'd disagree with,
by all means state it and we can discuss it.

 

[Angel]

Yes, that's rather the central point. At some point, we're down to
arguing with the guy who can prove that pi is exactly 3.125 because you
have to measure it using a circle inscribed in a square exactly 4 units
across*.

There have been several mathematical cranks who have made false claims
about pi, some of the stories are on Wikipedia. If I recall right, there
was even once a lawsuit started where the claim was that pi == 3,
because the bible says so.

Others have claimed that pi is a rational number (it's not, the decimals
are infinite and non-repeating) or that it can be constructed with compass
and straightedge (it can't).


But I guess I'm digressing off-topic here.

 

[Kleuskes & Moos]

Proving you wrong about what?  That would require you making a
specific claim with which we disagree.

Sigh... I repeated a very specific claim concerning "UINT_MAX ==
INTMAX"
quite a few times now, wht which you and others heartily disagreed. So
the above, frankly, is nonsense.

You've claimed that there are no existing systems that do not support
unsigned integer arithmetic.  You're very likely right about that.

And that was another claim i made in the course of the discussion,
only
to counter an argument about a hypothetical machine i thought was
_very_
implausible.

You've claimed that it's inconvenient to view addresses as signed
integers, and more convenient to view them as unsigned integers.
Again, I believe that's correct in most cases; I can't really
comment on whether it's correct in all cases.

I can't imagine any situation where such an arrangement would be an
advantage.

You respond to statements that UINT_MAX==INT_MAX is possible with
claims that it's not true on any real systems.  This does not refute
the original statement.

It is possible, but for reasons i've explained quite a few times, it's
highly improbable that you'll ever run into a system where it's
actually valid.

You've expressed a lack of interest in hypothetical systems.

Yes. Because anyone in this newsgroup is able to produce a dozen
hypothetical machines a day that no sane CPU-manufacturer would ever
produce. As an encore, it serves as a confirmation of the claim that
the now infamous condition is only valid hypothetically if almost all
attempts to show the opposite involve hypothetical processors and the
one exception (the Burroughs machine, and kudos for finding it) never
supported C in the first place.

That's not a falsifiable claim.

The statement that UINT_MAX == INT_MAX is only valid hypothetically is
easily falsifiable by bringing a single counterexample of a system in
use where it's valid. But then again, this is not a scientific thesis
under the watchful eyes of Karl Popper, but an informal discussion on
a public forum.

If you have a specific claim that you think we'd disagree with,
by all means state it and we can discuss it.

I've done that already, and you've summed them up quite nicely, above.
Besides, i started out woith a question:

<quote>
I've been scratching my head for a bit, reading the above. In any
numbersystem i can come up with it seems that UINT_MAX > INT_MAX, if
only because of the sign bit required in integers.

So please, which situation did you have in mind where UINT_MAX ==
INT_MAX?
</quote>

And i feel it has been thoroughly answered: none that anyone can think
of except hypothetical machines and a museum exhibit.

 

[Kleuskes & Moos]

"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

<snigger> Hey! That's _my_ quote!

 

[Keith Thompson]

Sigh... I repeated a very specific claim concerning "UINT_MAX ==
INTMAX" quite a few times now, wht which you and others heartily
disagreed. So the above, frankly, is nonsense.

Can you please humor me and re-state this "very specific claim"?

 

[Kleuskes & Moos]

[...]
Illucid or not, so far nobody has shown me to be wrong, which would be
easy if i were illucid, i would think.
Proving you wrong about what?  That would require you making a
specific claim with which we disagree.

Sigh... I repeated a very specific claim concerning "UINT_MAX ==
INTMAX" quite a few times now, wht which you and others heartily
disagreed. So the above, frankly, is nonsense.

Can you please humor me and re-state this "very specific claim"?

--
Keith Thompson (The_Other_Keith) (e-mail address removed)  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Copied from the part you snipped:

"UINT_MAX == INT_MAX is only valid hypothetically",

or more formally correct:

"The boolean expression UINT_MAX == INT_MAX only evaluates as 'true'
in hypothetical cases"*).

*) Barring any tomfoolery by the programmer, of course. If you're
hellbent on making it evaluate as 'true', you probably can.

 

[Keith Thompson]

[...]

Illucid or not, so far nobody has shown me to be wrong, which would be
easy if i were illucid, i would think.

Proving you wrong about what?  That would require you making a
specific claim with which we disagree.

Sigh... I repeated a very specific claim concerning "UINT_MAX ==
INTMAX" quite a few times now, wht which you and others heartily
disagreed. So the above, frankly, is nonsense.

Can you please humor me and re-state this "very specific claim"?

Copied from the part you snipped:

"UINT_MAX == INT_MAX is only valid hypothetically",

or more formally correct:

"The boolean expression UINT_MAX == INT_MAX only evaluates as 'true'
in hypothetical cases"*).

*) Barring any tomfoolery by the programmer, of course. If you're
hellbent on making it evaluate as 'true', you probably can.

The initial version was fine; I don't think the "more formally correct"
version adds anything.

(A minor quibble, though: "true" would have been clearer than "valid".
UINT_MAX == INT_MAX is a perfectly valid expression, which evaluates to
0 (false) on all implementations I'm aware of.)

Can you cite the article in which someone disagreed with that claim?

 

[Kleuskes & Moos]

[...]
Illucid or not, so far nobody has shown me to be wrong, which would be
easy if i were illucid, i would think.
Proving you wrong about what?  That would require you making a
specific claim with which we disagree.
Sigh... I repeated a very specific claim concerning "UINT_MAX ==
INTMAX" quite a few times now, wht which you and others heartily
disagreed. So the above, frankly, is nonsense.
Can you please humor me and re-state this "very specific claim"?

Copied from the part you snipped:

"UINT_MAX == INT_MAX is only valid hypothetically",

or more formally correct:

"The boolean expression UINT_MAX == INT_MAX only evaluates as 'true'
in hypothetical cases"*).

*) Barring any tomfoolery by the programmer, of course. If you're
hellbent on making it evaluate as 'true', you probably can.

The initial version was fine; I don't think the "more formally correct"
version adds anything.

(A minor quibble, though: "true" would have been clearer than "valid".
UINT_MAX == INT_MAX is a perfectly valid expression, which evaluates to
0 (false) on all implementations I'm aware of.)

Can you cite the article in which someone disagreed with that claim?

Google is your friend...

 

[Keith Thompson]

"Kleuskes & Moos" <[email protected]> writes:

[...]

Illucid or not, so far nobody has shown me to be wrong, which would be
easy if i were illucid, i would think.

Proving you wrong about what?  That would require you making a
specific claim with which we disagree.

Sigh... I repeated a very specific claim concerning "UINT_MAX ==
INTMAX" quite a few times now, wht which you and others heartily
disagreed. So the above, frankly, is nonsense.

Can you please humor me and re-state this "very specific claim"?

Copied from the part you snipped:

"UINT_MAX == INT_MAX is only valid hypothetically",

or more formally correct:

"The boolean expression UINT_MAX == INT_MAX only evaluates as 'true'
in hypothetical cases"*).

*) Barring any tomfoolery by the programmer, of course. If you're
hellbent on making it evaluate as 'true', you probably can.

The initial version was fine; I don't think the "more formally correct"
version adds anything.

(A minor quibble, though: "true" would have been clearer than "valid".
UINT_MAX == INT_MAX is a perfectly valid expression, which evaluates to
0 (false) on all implementations I'm aware of.)

Can you cite the article in which someone disagreed with that claim?

Google is your friend...

Not in this case.

I don't believe that anyone has actually disagreed with your claim.
If I do a Google search for such a disagreement (using what search
terms?), it's likely that I won't find anything that *I* consider to
be disagreeing with it. My failure to find it would prove nothing.

I could re-read this entire thread, but I've already read it and
not found what you say is there.

Can you cite an article in which *you think* someone disagreed with
your claim that "UINT_MAX == INT_MAX is only valid hypothetically"
(not counting my quibble above about "valid" vs. "true")?

 

[James Kuyper]

[...]

Illucid or not, so far nobody has shown me to be wrong, which would be
easy if i were illucid, i would think.

Proving you wrong about what? �That would require you making a
specific claim with which we disagree.

Sigh... I repeated a very specific claim concerning "UINT_MAX ==
INTMAX" quite a few times now, wht which you and others heartily
disagreed. So the above, frankly, is nonsense.

Can you please humor me and re-state this "very specific claim"?

....
"UINT_MAX == INT_MAX is only valid hypothetically",

I've never disputed the truth of that claim, and I don't recall that
anyone else has, either. I've only disputed it's importance. The fact
that UNIT_MAX >= INT_MAX is guaranteed by the standard makes it an
important constraint to be aware of. The unproven hypothesis that all
real implementations obey UINT_MAX > INT_MAX, even if it happens to be
true, is completely uninteresting to me.

I don't know how you can be justifiably certain about that claim, (being
unjustifiably certain of it is easy) because in principle certainty
would require that you be familiar with every single implementation of C
currently in existence; but I agree that the failure of anyone to
provide a counter example is supporting evidence for such a claim.

Can you provide a citation of anyone disputing the truth of that claim?

 

[Jorge]

[...]
Coding style is quite a personal thing, and I don't think there is a
real right or wrong in that. It was just something I came across while
browsing through the kernel documentation.
I like putting my accolades on separate lines so I can clearly see
where blocks begin and end, but others like to put their opening
accolade at the end of the if/while/for/function. Like I said earlier,
whatever works for you.
Are you sure that "accolade" is the word you're looking for?
Like I pointed out in another thread, it is the correct word in Dutch.
I'm not a native English speaker.
It does have that meaning in English too, but only in the context of
sheet music, it seems. I think "curly brace" is the correct term, no?
Anyway, I mean these things: {}
brackets: []
braces: {}
I thoroughly detest the words curly braces to describe braces.

The problem is that I've seen () referred to as brackets, and []
as braces.  I think there are differences between US and UK usage.

The word "parentheses" is reasonably unambiguous as far as I know,
but I like to refer to "square brackets" and "curly braces" when
there's any chance of confusion.  (Or, in writing, I just use the
characters themselves.)

Let's use french!

() is parenthèses
[] is crochets
{} is accolades
<> is chevrons

Or spanish !

() paréntesis
[] corchetes
{} llaves
<> cuñas

 

[Angel]

Let's use french!

() is parenth?ses
[] is crochets
{} is accolades
<> is chevrons

Or spanish !

() par?ntesis
[] corchetes
{} llaves
<> cu?as

What about dutch, that's what this all started with, eh?

() haakjes
[] blokhaken
{} accolades
<> punthaken