Re: Hungarian notation - whoops!

[ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe)]

I wrote:
    The underlying base is not something I usually have to think about.
    Most of my C code would work just as well in base 2, 3, 10, or even
    balanced ternary.

c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:

>But that is irrelevant since the standard restricts C to binary architectures.

Irrelevant to what?  I *know* what the C standard requires.  I keep a copy
of the C standard (and the draft C++ standard, and Pascal, and Pascal
Extended, and Ada 83, and Ada 95) close by my desk for handy reference.
(The Fortran standards I have read on microfiche in the library.)

Of necessity, my Fortran and Pascal code cannot depend on the machine base.
The fact that most of my C code turns out not to depend on the machine
base even though it _could_ is most certainly relevant to a discussion of
arithmetic in programming languages.  The form of my argument was "how
much more".

It so happens that the C standard was carefully crafted to allow
2s complement, 1s complement, AND sign-and-magnitude.

I wrote:
    But the fact that abs(x) may deliver a negative
    number is something I have to live with the whole time.

Kazimir Kyheku again completely misses the point by a country mile.

>Not true. If you use the unsigned type, there is no such thing as overflow.
>It's called residue math. No operation between two unsigned numbers yields
>undefined results. The "X % Y" operation between unsigned numbers gives you the
>smallest positive residue of X with respect to Y. Nothing undefined or
>overflown about that. 

Kazimir, you will get a LOT further in life if you realise that people who
disagree with you sometimes know what they are talking about.

The abs function in C is defined by the standard to take SIGNED int as
parameter and deliver SIGNED int as result.  I am not claiming now, did
not claim in the quoted message, and have never claimed in the past that
C has no arithmetic types which cannot overflow.  (Actually, in UNIX
Version 6, C _didn't_ have unsigned arithmetic; one did arithmetic on
pointers to get unsigned.  I kid you not.)  By the way, "X % 0" is still
undefined in unsigned arithmetic, so the claim that there is "nothing
undefined" about it is not true.

Let me say it again:

	C, like many programming languages, has two mathematically
	simple functions on ***SIGNED*** integers:
		-x
		abs(x)
	An implementation of C, or any other such language, using
	ones-complement or sign-and-magnitude arithmetic, easily
	delivers correct outputs for all legal inputs to these operations.

	An implementation of C, or any other such language, using
	twos-complement arithmetic, EITHER delivers incorrect outputs
	for some legal inputs OR requires checking which is in practice
	seldom offered.

Now, it so happens that a C compiler _is_ free to generate overflow checks
for signed integer arithmetic, so a twos-complement implementation COULD
guarantee "correct result or exception in all cases".  This is occasionally
done for Pascal compilers.  I have access to three C compilers (lcc, gcc,
and SPARCompiler cc) and if any of them has an option to check that signed
arithmetic is done correctly I would be most grateful to be told what it is.

The practical consequence of this is that responsibility for ensuring that
the input to unary minus or absolute value is in range is passed onto the
programmer.  It is that which I am complaining about.  It doesn't make my
life as a programmer one teeny tiny bit easier.

>The unsigned type is the ticket for portable integer modulo arithmetic.

Modular arithmetic in Ada 95 *is* the ticket for portable hackery.
Unsigned arithmetic in C is indeed defined to be modulo 2**n for some
n, but the bounds on n are very very loose, and the price of portability
is much programmer-inserted masking.

More importantly, while overflow in signed arithmetic is a run-time error,
unsigned arithmetic is very often a design-time error.

For example, suppose I want to count the number of times some event occurs.
Unless I can *prove* at design time that the event can occur no more than
65535 times, use of 'unsigned int' in C is a design-time error.  There is
at least one "commodity ISA" with a 300Mhz implementation getting close.
How long is a 32-bit unsigned counter usable with 3e8 events per second?

A little over 14 seconds.

Overflows aren't the problem.  Restricted machine arithmetic is the problem.

>You need unaligned access if you want to have packed character arrays.

Sorry, but this simply isn't true.  It may surprise you to know that Pascal
(the programming language which introduced the term 'packed') was first
implemented on a machine which did not have unaligned access.  The
machine in question had 60-bit words, 6 bit characters, and no character
addressing, only word addressing (which made unaligned access impossible
to express).

>If you
>don't allow any sort of unaligned access, allowing only contiguous 32-bit words
>to be accessed individually, you force size N arrays of characters to be 4N
>bytes long. That is seen by some people as a waste of memory. 

You are confusing *unaligned* access with *byte* access.  Like it or not, it
is a fact that the machines I was talking about DID support byte access,
DID support packed arrays of character, but did NOT support unaligned
access.

(Kazimir Kylheku) then contradicts himself and writes

>Just because a machine does enforce alignment doesn't mean that C cannot
>operate on packed byte arrays.

>Chances are that you may even be working on an architecture whose compiler does
>this, and not even know it! :)

I am working on a SPARC.  I also keep the SPARC V8 ABI manual close to my
desk, and know it pretty well.  Architectures don't have unique compilers.
I use three compilers.  I've only read one of them (lcc), but I occasionally
check the output of the others (gcc, cc).  There are several other compilers
for this architecture, including one which doesn't use register windows.

-- 
Election time; but how to get Labour _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.