From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,30e368bdb3310fe5 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,30e368bdb3310fe5 X-Google-Attributes: gid103376,public X-Google-Thread: 1008e3,30e368bdb3310fe5 X-Google-Attributes: gid1008e3,public X-Google-Thread: f8c65,30e368bdb3310fe5 X-Google-Attributes: gidf8c65,public X-Google-Thread: 1014db,30e368bdb3310fe5 X-Google-Attributes: gid1014db,public From: ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) Subject: Re: Hungarian notation - whoops! Date: 1996/02/19 Message-ID: <4g9255$74s@goanna.cs.rmit.EDU.AU> X-Deja-AN: 140000710 references: <30C40F77.53B5@swsbbs.com> <4fc157$jsf@goanna.cs.rmit.EDU.AU> <4fms62$c0p@goanna.cs.rmit.EDU.AU> <4ft1ruINN6dr@keats.ugrad.cs.ubc.ca> organization: Comp Sci, RMIT, Melbourne, Australia newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2 Date: 1996-02-19T00:00:00+00:00 List-Id: 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.