C programming in 2011

[Nizumzen]

Steve ? Is that you ?!

It might sound a bit like that but I seriously don't get the problem
with Clang. It is BSD licensed, supports all of C99 except for the
floating point #pragmas and works on multiple OS's and has a static
analyser. What isn't to like?

 

[Angel]

It might sound a bit like that but I seriously don't get the problem
with Clang. It is BSD licensed, supports all of C99 except for the
floating point #pragmas and works on multiple OS's and has a static
analyser. What isn't to like?

That varies from person to person no doubt. At first glance, my dislike
would be that it doesn't support Sparc64 or PowerPC architectures.

 

[J. J. Farrell]

I wasn't. I was just making the point.

Would you mind clarifying what your point is exactly, I've been
struggling to understand it.

Someone said, in effect, "if you want to write code which is correct on
all possible C implementations then you need to allow for the fact that
UINT_MAX == INT_MAX may be true". You appear to be countering with "if
you want to write code which is correct on all known and foreseeable C
implementations, then you don't need to allow for the fact that UINT_MAX
== INT_MAX may be true". I don't see any conflict between these statements.

What exactly is this vehement discussion about?

 

[Nizumzen]

That varies from person to person no doubt. At first glance, my dislike
would be that it doesn't support Sparc64 or PowerPC architectures.

Valid reason. Time will tell if CPU support increases dramatically.
With the FreeBSD devs interested in it I would guess that one of their
top priorities would be to increase the number of supported
architectures.

 

[James Kuyper]

Noob wrote: ....

You could change that to

#if UINT_MAX == INT_MAX

If (UINT_MAX < INT_MAX) is true, then it's not C.

Which would also make it an unsupported platform, would it not?

 

[Kleuskes & Moos]

Would you mind clarifying what your point is exactly, I've been
struggling to understand it.

'UINT_MAX == INTMAX' is only true in hypothetical cases*).

What exactly is this vehement discussion about?

As far as i can gather... next to nothing. Or, if i formulate a bit
more friendly, wether or not hypothetical, highly implausible fringe-
cases should be a consideration when designing software.

*) Anno domini 2011, in the 60's and 70's it may have had some
validity on some machines.

 

[Kleuskes & Moos]

Note the decimal arithmetic was dead, buried, and fossilized until IBM
resurrected it a couple years ago and it suddenly became the hotest
thing in hardware design.

If you think that's the 'hottest thing in hardware design', you
haven't been paying attention to actual 'hot things' in hardware
design.

 

[Kleuskes & Moos]

On 05/31/2011 08:57 AM, Kleuskes & Moos wrote:
...
The closest the standard comes to directly constraining UINT_MAX
relative to INT_MAX is in 6.2.5p9: "The range of nonnegative values of a
signed integer type is a subrange of the corresponding unsigned integer
type, ...". That corresponds to the constraint UINT_MAX >= INT_MAX; it
is not violated by UINT_MAX==INT_MAX.
True. But then there's "not violating a constraint" and there's sheer,
unadulterated sillyness of actually creating an implementation in
which UINT_MAX==INT_MAX, since you would be throwing away half the
range of the unsigned integer (and that goes in all three mandated
numbersystems).
So while it may not violate the standard, it _is_ silly, and i would
very much like to know which compiler meets UINT_MAX==INT_MAX.. Just so
that i can avoid it.
[...]
An obvious possibility is a platform with no hardware support for
unsigned integers - depending upon the precise details of it's
instruction set, it could be easiest to implement unsigned ints as
signed ints with a range restricted to non-negative values. However, I
claim no familiarity with any such system.
Such a system would not be able to operate, since every relative jmp-
instruction involves the addition (or subtraction, which is basically
the same). So name that fabled platform.
How do you know what's involved in relative jump instructions on a
hypothetical system that might not even exist?

What other methods of doing relative jumps did you have in mind? Since
you think there's an alternative, it's up to you to name it.

I have no idea, and no, it's not up to me to name it.  You've made an
assertion about how relative jump instructions work, presumably on *all*
systems.

I have, since it's the only plausible way to implement them, simply
because the simplest definition of a relative jump is

PC <-- PC+offset

and, frankly, i don't see any other way to implement one. But that may
be just my lack of imagination, so if you do know of another method,
then please.

("jibe")

I wasn't aware that signed addresses defied the laws of common
sense.  Perhaps they do.  I do not claim that such systems have
any particular advantages, or even that they necessarily exist (I
honestly don't know whether they do or not), merely that they're
possible.

As pointed out elsthread, signed or unsigned is in the eye of the
beholder. Viewing them as unsigned is simply more convenient, having
an address range [0...MemSize>.

Now that I think about it, perhaps a virtual machine would be more
likely to have such characteristics, especially if it's implemented
in a language that doesn't support unsigned arithmetic (Pascal,
for example).

Implementing a virtual machine in Pascal? Sure it's possible, pascal
is turing-complete, after all.

I have some documentation on the old UCSD Pascal system;
I'll look into it later.

I'd be interested, but i was talking about _real_ processors. Virtual
ones have quite a different set of constraints and design
considerations.

Why not?  There's no particular reason such a system coulnd't
support a conforming C implementation.

True, but the chances of one actually getting a) designed b)
implemented and c) bought and used are approaching 0 with a
frightening speed and such systems do not interest me.

And you find these as plausible as UINT_MAX==INT_MAX?

Slightly less plausible. I'm surprized at having to explain such an
obvious rethorical remark.

You were right about what, exactly?

UINT_MAX == INTE_MAX is only valid in hypothetical cases, as i've
already explained several times.

This is not a zero-sum game where one of us wins and one of us loses.
It's a technical discussion.

Aye. "Winning, loosing, no matter. Make good fight."

Do any systems with UINT_MAX==INT_MAX actually exist?  I don't know; I
make no claim one way or the other.  You claim that there are no such
systems; as far as I know, you may be right.
Ok.

But this is comp.lang.c, not comp.arch, and the main point I've been
making is that such systems are permitted by the C standard.  (I'm
reasonably sure I'm right about that; if you agree, that doens't mean
you're admitting defeat.)

The C standard, by it's very nature, is stated as generally as
possible, and, as i've stated upthread, the standard allows for a lot
of implausible implementations including ones in which the condition
in question is true, simply to give compiler-makers enough leeway to
cater to even the most obscure hardware. That's a good thing.

That does not mean that every possibility allowed by the standard
should be taken into consideration, especially those that, by their
very nature, are _very_ implausible.

Even if it's allowed by the standard, i would not expect any system to
launch the complete nuclear arsenal of the western world every time
someone invokes undefined behavior, nor do i take that into account
when designing software.

You're asking me to support a claim I never made.
Perhaps.


But ok, let's say we have a system with a 16-bit address space,
with addresses ranging from 0 to 65535, and with each byte in that
range being addressible.  What happens if you start with a pointer
to memory location 65535, and then increment it?

I'm sure you can figure that one out for yourself.

Unless there's hardware checking, the result will probably point to
address 0.
Or, equivalently, we started with address -1 and incremented it to
address 0.

That seems plausible. What's the point?

If address arithmetic doesn't check for overflow or wraparound, it may
be *conceptually* more convenient to think of addresses as unsigned, but
the hardware doesn't necessarily care.

That was the point i made above.

Magic.  }  Seriously, I'm not much of a hardware guy, but we can
agree that CPUs can add.


Depends on the system.  On some systems, there might be a hardware trap
on overflow; the conditions in which that trap will be triggered might
differ for signed and unsigned add instructions.  Maybe.  And no, I
don't have concrete examples.

On 2's complement systems, they do not differ. As explained
elsethread, that's one of the main reasons 2's-complement is the de-
facto standard nowadays.

Again, I've never claimed that such a CPU exists.

Non-existent CPU's are also non-interesting.

 

[Willem]

Kleuskes & Moos wrote:
) I have, since it's the only plausible way to implement them, simply
) because the simplest definition of a relative jump is
)
) PC <-- PC+offset

And how does that involve unsigned integers specifically ?


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Kleuskes & Moos]

Kleuskes & Moos wrote:

) I have, since it's the only plausible way to implement them, simply
) because the simplest definition of a relative jump is
)
) PC <-- PC+offset

And how does that involve unsigned integers specifically ?

PC is an unsigned integer, for all intents and purposes.

 

[Willem]

Kleuskes & Moos wrote:
)> Kleuskes & Moos wrote:
)>
)> ) I have, since it's the only plausible way to implement them, simply
)> ) because the simplest definition of a relative jump is
)> )
)> ) PC <-- PC+offset
)>
)> And how does that involve unsigned integers specifically ?
)
) PC is an unsigned integer, for all intents and purposes.

Begging the question: You're assuming the existence of unsigned integers
to prove the existence of unsigned integers.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Angel]

PC is an unsigned integer, for all intents and purposes.

It's a sequence of bits, nothing more and nothing less. Its existence
does not prove that the implementation can handle unsigned integers.

CPUs work with sequences of bits only, because that is the only thing
they can understand. The CPU doesn't usually know what the bits it is
tossing around represent, the interpretation of that happens on a higher
abstraction level.

 

[Kleuskes & Moos]

Kleuskes & Moos wrote:

)> Kleuskes & Moos wrote:
)>
)> ) I have, since it's the only plausible way to implement them, simply
)> ) because the simplest definition of a relative jump is
)> )
)> ) PC <-- PC+offset
)>
)> And how does that involve unsigned integers specifically ?
)
) PC is an unsigned integer, for all intents and purposes.

Begging the question: You're assuming the existence of unsigned integers
to prove the existence of unsigned integers.

Are you claiming unsigned integers don't exist?

 

[Willem]

Kleuskes & Moos wrote:
)> Kleuskes & Moos wrote:
)>
)> )> Kleuskes & Moos wrote:
)> )>
)> )> ) I have, since it's the only plausible way to implement them, simply
)> )> ) because the simplest definition of a relative jump is
)> )> )
)> )> ) PC <-- PC+offset
)> )>
)> )> And how does that involve unsigned integers specifically ?
)> )
)> ) PC is an unsigned integer, for all intents and purposes.
)>
)> Begging the question: You're assuming the existence of unsigned integers
)> to prove the existence of unsigned integers.
)
) Are you claiming unsigned integers don't exist?

Straw-man argument. That's two logical fallacies in as many posts.
Apparently, you don't care about being right, you only care about winning.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Kleuskes & Moos]

Kleuskes & Moos wrote:

)> Kleuskes & Moos wrote:
)>
)> )> Kleuskes & Moos wrote:
)> )>
)> )> ) I have, since it's the only plausible way to implement them, simply
)> )> ) because the simplest definition of a relative jump is
)> )> )
)> )> ) PC <-- PC+offset
)> )>
)> )> And how does that involve unsigned integers specifically ?
)> )
)> ) PC is an unsigned integer, for all intents and purposes.
)>
)> Begging the question: You're assuming the existence of unsigned integers
)> to prove the existence of unsigned integers.
)
) Are you claiming unsigned integers don't exist?

Straw-man argument.  That's two logical fallacies in as many posts.
Apparently, you don't care about being right, you only care about winning..

Asking a question is not making an argument, so if you're interested
in playing games with logical fallacies, be careful not to use one
yourself.

But, since your only object is to play games, any further conversation
is pointless.

Have a nice day.

 

[James Kuyper]

Are you claiming unsigned integers don't exist?

That appears to be poor wording on his part. I think that what he
actually meant was something like:

"You're assuming that support for unsigned integer arithmetic must be
available on all systems, in order to prove that it must be available."

This appears to be a fairly accurate description of your "argument",
such as it is.

 

[Willem]

Kleuskes & Moos wrote:
) Asking a question is not making an argument,

Asking a loaded question *is* making an argument.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Keith Thompson]

I have, since it's the only plausible way to implement them, simply
because the simplest definition of a relative jump is

PC <-- PC+offset

and, frankly, i don't see any other way to implement one. But that may
be just my lack of imagination, so if you do know of another method,
then please.
<snip>

Ok, a relative jump is basically
PC <-- PC+offset

Not that it's necessarily the case that a CPU must directly support
relative jumps, but that's beside the point. (And no, I'm not claiming
that there are CPUs that don't support relative jumps, or that there
aren't; it's just not particularly relevant to C.)

But nothing in that description implies unsigned arithmetic.
Presumably the offset is signed. Why can't the PC (program counter)
be signed?

(Asserting that it's unsigned does not answer the above question.)

("jibe")

I wasn't aware that signed addresses defied the laws of common
sense.  Perhaps they do.  I do not claim that such systems have
any particular advantages, or even that they necessarily exist (I
honestly don't know whether they do or not), merely that they're
possible.

As pointed out elsthread, signed or unsigned is in the eye of the
beholder. Viewing them as unsigned is simply more convenient, having
an address range [0...MemSize>.

Sometimes you argue that signed addresses defy the laws of common sense.
And sometimes you argue that addresses can be viewed as either signed or
unsigned, whichever is more convenient. I see a contradiction.

Implementing a virtual machine in Pascal? Sure it's possible, pascal
is turing-complete, after all.


I'd be interested, but i was talking about _real_ processors. Virtual
ones have quite a different set of constraints and design
considerations.

Virtual processors are just as valid a target for a C implementation as
real ones.

True, but the chances of one actually getting a) designed b)
implemented and c) bought and used are approaching 0 with a
frightening speed and such systems do not interest me.

You spend a great deal of time arguing about something that doesn't
interest you.

Slightly less plausible. I'm surprized at having to explain such an
obvious rethorical remark.


UINT_MAX == INTE_MAX is only valid in hypothetical cases, as i've
already explained several times.

As you've already *asserted* several times.

[...]

The C standard, by it's very nature, is stated as generally as
possible, and, as i've stated upthread, the standard allows for a lot
of implausible implementations including ones in which the condition
in question is true, simply to give compiler-makers enough leeway to
cater to even the most obscure hardware. That's a good thing.

That does not mean that every possibility allowed by the standard
should be taken into consideration, especially those that, by their
very nature, are _very_ implausible.

The C standard is stated very generally, but *not* "as generally as
possible". There are plenty of characteristics, some of them things
that have existed in real-world systems, that are excluded (some of
which can be worked around in software). Some examples: Bytes must
be at least 8 bits. Type int must be at least 16 bits. Data must
be represented in binary. Signed integers must be represented in
either 2's-complement, 1s'-complement, or sign-and-magnitude (biased
representations are not permitted). Floating-point is mandatory.

Most of the flexibility is there either because there have been
real-world systems that need it, or because a greater range of
permitted characteristics is simpler to describe. It's fairly
safe to assume that there are no systems with 137-bit bytes, but
the standard doesn't go out of its way to forbid it.

Even if it's allowed by the standard, i would not expect any system to
launch the complete nuclear arsenal of the western world every time
someone invokes undefined behavior, nor do i take that into account
when designing software.

Not if the hardware doesn't actually interact with the nuclear
arsenal. But some systems do exactly that, and if they're
implemented in C (which, personally, I hope they're not) they had
bloody well better avoid anything approaching undefined behavior.

Perhaps more realistically, you might assume that a C program with
undefined behavior can't possibly reformat your hard drive -- but
if the process it's running in has the capability of invoking the
"please reformat my hard drive" routine, and a function pointer
somewhere gets clobbered, it could very well do that.

[...]

I'm sure you can figure that one out for yourself.

That wasn't the point of the question.

That seems plausible. What's the point?

The point, which you've acknowledged, is that it can be perfectly
reasonable to think of memory addresses as signed integers.
Which means that you can't reasonably use memory addresses as an
argument that all systems *must* support unsigned arithmetic.

That was the point i made above.

That's one of the two contradictory points you made. The other point
you made is that the "practicalities of hardware design" imply somehow
that addresses are necessarly unsigned.

On 2's complement systems, they do not differ. As explained
elsethread, that's one of the main reasons 2's-complement is the de-
facto standard nowadays.

And as I explained, *if the system traps on signed overflow*,
there is a very real difference between signed and unsigned addition.

Non-existent CPU's are also non-interesting.

Again, you've spent a great deal of time discussing something that you
find non-interesting. Are you trying to convince me that I shouldn't be
interested in them either?

 

[Kleuskes & Moos]

Ok, a relative jump is basically
    PC <-- PC+offset

Not that it's necessarily the case that a CPU must directly support
relative jumps, but that's beside the point.  (And no, I'm not claiming
that there are CPUs that don't support relative jumps, or that there
aren't; it's just not particularly relevant to C.)

But nothing in that description implies unsigned arithmetic.
Presumably the offset is signed.  Why can't the PC (program counter)
be signed?

Basically, it makes no big difference, and if you insist on viewing
the PC as signed, then you would end up with a consistent picture. It
may just not be that convenient. In a simple staightforward addressing
scheme, say a 16-bit address bus, your memory layout would be slighly
weird if you install 48k (16 ROM/32kRAM) of actual memory. You would
have one range [0..32k> and one [-32k..-16k>, assuming the layout of
your address-bus isn't something weird, too. And trust me... The
hardware guys don't like that and will probably call you "very silly,
indeed", in polite terms and/or behind your back, of course, if you
ask them to design something like that.

(Asserting that it's unsigned does not answer the above question.)

I hope the above satisfies your demand.

As pointed out elsthread, signed or unsigned is in the eye of the
beholder. Viewing them as unsigned is simply more convenient, having
an address range [0...MemSize>.

Sometimes you argue that signed addresses defy the laws of common sense.
And sometimes you argue that addresses can be viewed as either signed or
unsigned, whichever is more convenient.  I see a contradiction.

In theory, you can view them as whatevery you want. What matters is
not what numerical value _we_ assign to an address, its what's
presented to the hardware what matters. On many systems, especially if
you're dealing with Nkx8 memory, no single memory chip is connected to
every address-line, that is, sees the entire address. The numerical
values are imposed and you can think of them as being signed, if you
like, but as explained above, it just ain't practical.

Virtual processors are just as valid a target for a C implementation as
real ones.
True.



You spend a great deal of time arguing about something that doesn't
interest you.

True. Bu then again, discussion sharpens the mind, and every
participant may end up having learned something, so i still consider
it worthwhile to bicker about not-so-interesting hypotheticals.

And besides... It's fun.

As you've already *asserted* several times.

Yup. I've spent quite some time explaining why i asserted that,
written extensive posts, was accused of logical fallacies, rebuked for
not strictly adhering to the standard, and called irresonsable by
insinuation, but, sofar, nobody's proven the simple assertion wrong.

So please. Bring an example and i will stand corrected.

[...]

The C standard, by it's very nature, is stated as generally as
possible, and, as i've stated upthread, the standard allows for a lot
of implausible implementations including ones in which the condition
in question is true, simply to give compiler-makers enough leeway to
cater to even the most obscure hardware. That's a good thing.

That does not mean that every possibility allowed by the standard
should be taken into consideration, especially those that, by their
very nature, are _very_ implausible.

The C standard is stated very generally, but *not* "as generally as
possible".  There are plenty of characteristics, some of them things
that have existed in real-world systems, that are excluded (some of
which can be worked around in software).  Some examples: Bytes must
be at least 8 bits.  Type int must be at least 16 bits.  Data must
be represented in binary.  Signed integers must be represented in
either 2's-complement, 1s'-complement, or sign-and-magnitude (biased
representations are not permitted).  Floating-point is mandatory.

Ok. You got a nit. It's _only_ stated _very_ generally and not "as
generally as possible". Don't you get a strange feeling that
you might be arguing over semantics here? I would.

Most of the flexibility is there either because there have been
real-world systems that need it, or because a greater range of
permitted characteristics is simpler to describe.  It's fairly
safe to assume that there are no systems with 137-bit bytes, but
the standard doesn't go out of its way to forbid it.

Fortunately not, because there's some _really_ weird hardware out
there.
Especially in the museum. Did you ever hear of "bit-slicers"? It's
perfectly
feasable to build a 137-bit computer using those. 68HC11 has 13 bits
addresses
and a harvard architecture.

But the again, it just ain't practical. Last use i heard of a
bitslicer
was as a fire control in a goalkeeper anti-missile gun, but i don't
remember
much of the detail.

I digress...

Not if the hardware doesn't actually interact with the nuclear
arsenal.  But some systems do exactly that, and if they're
implemented in C (which, personally, I hope they're not) they had
bloody well better avoid anything approaching undefined behavior.

Perhaps more realistically, you might assume that a C program with
undefined behavior can't possibly reformat your hard drive -- but
if the process it's running in has the capability of invoking the
"please reformat my hard drive" routine, and a function pointer
somewhere gets clobbered, it could very well do that.

The point to be made was: "not everything allowed by the standard is
likely, or even possible".

I'm sorry i made you think that i was trying to imply that _any_
invocation of undefined behavior is allowable, but sometimes i
think people argueing the details of The Standard are also
capable of reading a simple post without making undue inferences.

I will try to spell it out next time.

[...]

I'm sure you can figure that one out for yourself.

That wasn't the point of the question.

That seems plausible. What's the point?

The point, which you've acknowledged, is that it can be perfectly
reasonable to think of memory addresses as signed integers.

Yes. But it's just not practical, and i've explained above _why_ it's
not practical. Besides, i've pointed out on several occasions that
it's
possible. It's not practical, is the point.

Which means that you can't reasonably use memory addresses as an
argument that all systems *must* support unsigned arithmetic.

I don't argue they *must*, i argue they *do*. Not for theoretical
reasons, but for very practical reasons. There's a shitload of weird
and
excentric systems one might, hypothetically, build and which would,
theoretically, work, bot the point is, nobody does, since there's no
reason to.

That's one of the two contradictory points you made.  The other point
you made is that the "practicalities of hardware design" imply somehow
that addresses are necessarly unsigned.

I said it's more practical to view them as such, because it's simpler.
You can just view the n bits of the address line as an n-bit number
instead of a 2's complement number. And if you're making electronics-
designs, you like things like that to be simple and straightforward
and not be hindered by positive and negative adresses when there's no
good reason to do so.

And since the CPU-designers view adresses as unsigned integers, and
the board-designers view adresses as unsigned integers, it's best
software guys don't try to invent signed addresses, since that only
complicates things for no good reason whatsoever.

And as I explained, *if the system traps on signed overflow*,
there is a very real difference between signed and unsigned addition.

Not that big a difference.

Again, you've spent a great deal of time discussing something that you
find non-interesting.

I try not to, but then again, you must eat the porridge to get the
raisins.

Are you trying to convince me that I shouldn't be interested in them either?

Not really. I'm merely trying to avoid getting drawn into a quagmire
of ill-conceived,
ad-hoc hypotheticals.

 

[Seebs]

Asking a question is not making an argument,

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

But, since your only object is to play games, any further conversation
is pointless.

I saw no evidence of playing games. 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.

-s