On Thu, Dec 2, 2010 at 3:47 PM, <arcarlini at iee.org> wrote: I've done that "slowdown" trick in embedded code and had it optimized down to a simple assignment. I've found that rather than tweak the compilier, tweaking the code this much... for (i=0; i < 100; i++) { a=i; } (i.e. - putting something active in the loop) ... was enough to leave the loop in and generate a few cycles for the delay. If I'm in an environment where C and assembler are mixed (not uncommon with microcontroller programming), a #asm/NOP construct works, too. -ethan

On Thu, Dec 2, 2010 at 5:20 PM, Fred Cisin <cisin at xenosoft.com> wrote: Ooh... never been bitten by that one, but it sounds nasty. I haven't done any assembly on Intel processors past the 286 (and it wasn't mixed-mode), and the only other architectures I've worked with at that level that care about even-address-alignment (PDP-11 and MC68K) shouldn't hurl if some entity pulls out a 16-bit NOP, but, boy, I'd be steamed if I had to manually align some code only to find the compiler tried to "help me out". Sounds like a need for a #DWIM pragma. ;-) -ethan

On Thu, 2010-12-02 at 17:32 -0500, Ethan Dicks wrote: I've had some fun doing Protected Mode on Bochs, in 80386 mode. Bit too masochistic for my liking, though... Thankfully the Motorola 68K is a bit easier to deal with (I've been learning that while debugging the 3B1 emulator)... My current love affair is with 'soft' (FPGA-implemented) CPUs. I've been playing with Lattice's "LatticeMico32" CPU core on an Altera FPGA board (and an Enterpoint Drigmorn2 Xilinx devboard, just for good measure) and the assembly language for that is like a dream come true. It's almost completely orthogonal, opcodes do what their names say... you could probably use it to teach a computer architecture class. The GNU assembler is a piece of cack, but a few hours spent with Flex, Bison and GCC should produce a workable assembler. Tack on a modification of an old C preprocessor and hey, you've got ifdefs and macros! Yeah, I'm a RISC fanboy (as evidenced by the MIPS books on my bookshelf). From memory, LM32 has 64 instruction codes (several of which are unused) versus the several thousand on the 32-bit X86/MMX/SSE/SIMD/3DNOW platform. I have nothing but the utmost respect for any programmer good enough to write (or maintain) a *good* compiler or operating system for the X86 platform.... -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/

On 12/2/2010 2:29 PM, Eric Smith wrote: I'm afraid I must disagree. What if, for my own nefarious purposes, I need the N microseconds of delay achieved via the "spurious" for loop? I know, code loop delays are generally a poor practice, but what does one do if a delay is absolutely required before timer interrupts can be enabled? What if there is no hardware timer (e.g. 8254) that can be read periodically to time the delay? What if I am writing a quick hardware test? Later, Charlie C.

On Dec 3, 2010, at 9:28 AM, Richard wrote: Better yet, have the loop call an external (to the compilation unit) function (that does nothing - ie just returns). The optimizer can't eliminate the loop because it doesn't know what side effects the function may have. The other way to deal with this is to declare a variable as a volatile pointer and keep reading it. The optimizer can't remove the reads (or writes) to a volatile pointer. Although the best case would be to have a high resolution clock that you keep checking (but again that would use either an external function or a volatile pointer). TTFN - Guy

On Dec 3, 2010, at 2:42 PM, Fred Cisin wrote: See my previous post. Using the volatile keyword on a variable requires the compiler to read/write it as expressed in the program (ie if in a loop, the compiler can't just read it once and be done). If the compiler doesn't do that, it's a bug if it in any way claimed be a standards compliant compiler. TTFN - Guy

On Dec 3, 2010, at 3:10 PM, Fred Cisin wrote: Some of these threads go on long enough it's hard to remember how it started. ;-) That was a mistake! One of (many of) the problems with "K&R" was that it assumed that there would be no significant optimization. I'd argue that this was a bit short sighted since at the time there were a number of optimizing compilers out. Some of them were used for systems implementation and had to deal with this very issue. I actually recall the surprise in the early days of BLISS-11 when it optimized out a whole chunk of I/O polling code...it then had to be "taught" about PDP-11 MMIO and that it had to do all of the loads/stores as written. TTFN - Guy

On 12/2/2010 2:59 PM, Ethan Dicks wrote: While we are at it, please don't optimize out while (1) { } as a forever (or semi-forever if there is the possibility of a break) either. :-) BTW, I realize I'm another curmudgeon at large, but I claim the intent of while (1) is more immediately obvious than for (;;). I also claim the difference matters. FWIW, I also claim that many other matters of style matter as well, and that they in fact matter a great deal if one takes more than an immediate view of one's code. I suppose I also would claim that one should always take a relatively long term view of one's code. The trick of course is determining just how long the long term is, so the appropriate amount of effort is applied to make the code maintainable without making the project take forever. Later, Charlie C.

This discussion puts me in mind of a series of columns in "C Users Journal" about the draft ANSI standard and how it changed behaviors exhibited by some well-known compilers at the time. The "quiet changes" were the worst: those that caused working programs to fail if recompiled, but generated no warning. In developing the standard, some things came down to judgement calls, since you could demonstrate successful implementations that were on either side of the question! -- Ian

In the 1975 _C Reference Manual_ it looks like this: Any or all of the expressions may be dropped. A missing expression-2 makes the implied while clause equivalent to "while( 1 )"; other missing expressions are simply dropped from the expansion above. C99 phrases it, in 6.8.5.3, as: An omitted expression-2 is replaced by a nonzero constant. -- Kevin Schoedel <schoedel at kw.igs.net> VA3TCS

On Thu, Dec 2, 2010 at 6:17 PM, Richard <legalize at xmission.com> wrote: I think you are imagining it backwards. A for loop continues *until* the condition is true. (i > 10 or some such). A _missing_ conditional test is always false, so the loop test will never satisfy, so the loop will never exit on its own (which is why a break or a processor reset is needed to break out of it). Those are correct as written, but they are a different keyword with a different sense on the test. A while loop continues _as long as_ the test is true. 1 is never 0, so it's always true. -ethan

On Thu, Dec 2, 2010 at 7:01 PM, Fred Cisin <cisin at xenosoft.com> wrote: Yeah... Sorry. You are correct. I got flipped around one too many times in my head trying to phrase that while trying to shut down and get out the door. That'll learn me to check my logic before pressing 'send'. -ethan

On Thu, Dec 2, 2010 at 11:56 PM, Richard <legalize at xmission.com> wrote: That is a clear way of putting it. I was focusing on the questor's issue about how the construct didn't make sense with null elements and got tangled up elsewhere. Right. I was unclear about the case of once-through vs skipping the payload, but that wasn't the aspect of it that I was trying to address. Apologies for muddling the issue. As I said earlier, I should have taken the time to proof what I read, and in my haste, failed so to do. -ethan

Chuck Guzis wrote: My personal favorite of all the IOCCC winners is 1984/Mullender. I've always thought that was a particularly clever way of screwing with the judges. Peace... Sridhar

On Thu, 2 Dec 2010, Richard wrote: Yes, C DOES permit an empty condition clause. Valid, and often used when a programmer prefers to use the "for" rather than "while" keyword. C permits, and damn near ENCOURAGES, "puzzle code" A sparse commenting style that one might get away with in many other languages, can be a disaster in C. Consider while (*t++=*s++); Or, read any of Holub's work to see great examples of short statements in C that require a lot of thought to figure out. But, I thought that APL was a lot of fun. -- Grumpy Ol' Fred cisin at xenosoft.com

I've been trying to follow this discussion, but there's a huge gap in received email (into the bit bucket?), so now I haven't the faintest idea of what's being discussed. Is there someplace I can request a digest of the last couple dozen messages? Thanks, Chuck

Okay, I compiled this and was shocked at the result (I didn't think it would work, honestly). So what are the answers to your questions above? I'm genuinely interested. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Haiku is easy/Sometimes it doesn't make sense/Refrigerator -- "KFI Haikus" -

That is ... grotesque. I'll file under "things I learned today" -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- When the going gets weird, the weird turn pro. -- Hunter S. Thompson -------

On Thu, Dec 2, 2010 at 6:26 PM, <schoedel at kw.igs.net> wrote: Very concisely put. We're just used to E1 being large and fixed and E2 being small and variable, but there's no lexical requirement of such. -ethan

On Thu, Dec 2, 2010 at 6:14 PM, Ethan Dicks <ethan.dicks at gmail.com> wrote: That's what I figured it was going to do, (it wouldn't be very interesting if the answer was it would SIGSEGV) but I don't know that I understand why the index doesn't get multiplied by the size of the array type before being added to the pointer. If p is int p[] then *(p + sizeof(int)*n) is the same as p[n], right? -chuck ps. certainly not a C expert.

On Thu, 2 Dec 2010, Eric Smith wrote: aren't most?

On 12/2/10 5:03 PM, Eric Smith wrote: It prints "Hello, world!" and a newline (no quotes). It works because C compilers treat array subscripts as simple pointer arithmetic, so i["He...\n"] is the same as (i * sizeof(char)) + "He...\n" (the string is a converted to a pointer internally).

Charles Dickman wrote: No. There shouldn't be a multiplication by sizeof(anything), because C does the scaling automatically, but the automatic scaling has to be of the size of the target of the pointer, which is char, not by the size of the index. The automatic scaling is such that indices 0, 1, 2, etc. always refer to successive elements of the target type, and not to successive bytes. Eric

On 2010 Dec 2, at 5:12 PM, Charles Dickman wrote: No, as has been explained: a[b] == *(a+b); the 'target size' and hence scaling factor for the integer operand of the addition (be it a or b) is determined by the base type of the pointer operand. Problems may be anticipated if the two operands are not constituted In C, indexing with "[]" is really just a syntactic nicety for the sake of convention, it is not a functional addition to the language. (I haven't done any C programming to speak of in over 20 years (1988). I don't think I ever claimed to be a C expert, but I think I can say people used to treat me as such. I will claim that I answered Eric's questions correctly when he first posed them.) -- Way back then, a lowly undergrad learning C came up against a baffling problem. The program would compile and run but produce inexplicable results. The instructor couldn't figure it out, so a bunch of grad students and research assistants were called in, me amongst them. We stood around and scratched our heads and none of us experts could see the error. We cognoscenti left, the student did some more debugging and eventually reported back to us with the explanation. Perhaps it is more or less obvious when presented in stark, pared-down form like this, but what is wrong with the following C program, or what problem might be anticipated? (Arguably, it's not really a C language problem): main() { Read(); } Read() { blah; blah; }

On 2010 Dec 2, at 7:02 PM, ben wrote: You're not stumped, that was exactly the problem. The linker decided to prioritise the Unix system call over the user's routine, without complaint or advisory. In the larger context of all the surrounding code, all us experts who just as a matter of unconscious habit avoided naming routines like that, didn't see the problem. It did always annoy me, that such generic words as "open", "close", "read", "write" were sucked up by the Unix OS, the OS writers having had first pickings from the global symbol name space.

On 2010 Dec 2, at 7:17 PM, George Currie wrote: Yes, it was (insensitive). I think it was on Apollo workstations IIRC, ca. 1987. I don't know whether things are any better in standard C environs these days or not.

On 2010 Dec 2, at 7:34 PM, blstuart at bellsouth.net wrote: I'd agree that's the common expectation, defined behaviour is another matter. To my recollection, such linking and naming issues are not specified in the C language, or at least were not back then.

On 2010 Dec 2, at 7:16 PM, Brian Lanning wrote: Those annoying semi-colons. (Plus I hope you had "true" defined appropriately.)

On Thu, Dec 2, 2010 at 11:15 PM, Chuck Guzis <cclist at sydex.com> wrote: There was a good example of that sort of thing and an intentionally obsoleted feature of C interacting badly in a VAX-C tutorial... It was something like... main() { int i; i=-1; printf("i is %d\n", i); } ... it worked *if* you loaded the program with the debugger, otherwise you got a seemingly large and random value for i. The trick is the "=-" was originally (like c. 1972) the syntax for what's now "-=" and that took precedence over the seemingly obvious interpretation of "i = -1" (note the spaces). The reason it worked in the debugger was that as part of the debugging process, the program loader would clear out one page of the stack frame with zeros so you could see autovariables populate the stack area, so the result was a zero in memory "minus equals" one, or negative one (-1). Later versions of VAX-C (and other C compilers) complain about non-initialized autovariables and obsolete language features (like =- and =+), but the compiler at the time did something odd but quasi-legal and did it quietly. -ethan

Brent Hilpert wrote: Is blah the name of a function? If so, I've definitely encountered this problem before. GCC will warn about it. Eric

On 12/2/2010 8:47 PM, Brent Hilpert wrote: umm ... #define blah write("Blah Humbug\n",3)

George Currie wrote: arithmetic, It's not that C compilers have chosen to do that, but the C language that *requires* it. My little program doesn't work by accident, but is in fact a fully standard-conformant program. string is a converted to a pointer internally). Very close. You omitted the pointer dereference, and the multiplication by sizeof(char) is incorrect, though it expresses your intent. When you write "Somestring" + i The quoted literal is an array of elements of type char, which becomes a pointer to char. The language requires that addition of integers and pointers to someType to have an implicit scaling by sizeof(someType). The multiplication by sizeof(char) thus happens "under the hood". For a character, where sizeof(char) is 1, your explicit multiplication won't cause a problem, but for any type with sizeof(type) > 1, the extra multiplication would cause a problem. In C, the expression a[b] is essentially a shorthand for *(a+b) Since addition is commutative (even between pointers and integers), that is equivalent to *(b+a) which is, of course, equivalent to b[a] In the specific example, i["He...\n"] is equivalent to *(i + "He...\n") or *("He...\n" + i) or "He...\n"[i] Eric

On Thu, 2 Dec 2010, Eric Smith wrote: I'm a rank beginner at C ( <30 years) I would be worried about the ego of anybody who claims to be expert. Of course your example would work. I'm assuming that it was created by mistake, not a deliberate attempt to print 14 characters from pseudo-random places in memory. When you shoot yourself in the foot, C has no "gun-control". What would an excessive optimization compiler change it to? A[i++] = i++; Many people think that they know what that will do. They may even be right for THEIR compiler, but I don't think that even ANSI C is a rigid enough specification to pin down the sequence of certain actions. When I taught, I TRIED to get my students to begin to understand that C will do exactly what you asked for, disunirregardless of what you WANTED. I also explained to my students that one could optimize for speed, optimize for object code size, optimize for source code size, optimize for obfuscation (obfuscated C contest, anyone?), or optimize for readability. All class assignments were to optimized for readability and thoroughly commented. I suggested to them that they should NEVER optimize for speed or size, until AFTER they had debugged a version optimized for readability, and even then, seriously consider including the "readable" code as a comment in their final optimized version. Very little of what I do/did requires much, if any, speed. So I am very much NOT an expert on optimization. -- Grumpy Ol' Fred cisin at xenosoft.com

Fred Cisin wrote: By definition, if it is "excessive" optimization, it might do anything! I can't quote chapter and verse, but I'm fairly sure the standard will say that the result of that assignment is undefined. In pre-standard C, it is also undefined, but for a different reason. Many programmers would say "I would never write code like that", but I've seen statements like that creep into code as a result of cut-and-paste or global-search-and-replace operations that weren't carefully checked. It's also quite possible when writing complex expressions to come up with things like that which are not necessarily obvious to casual inspection. It is good that many compilers will detect these things and generate warnings. When I have the power to do so, I generally treat warnings from the compiler as fatal errors requiring a fix, and not acceptable in released code. Eric

On Thu, 2 Dec 2010, Eric Smith wrote: C can be pretty loose about letting you do such. absolutely. At the bare minimum, understand what is being pointed out. It's hard, but necessary, to get beginning students to realize that an assignment is not complete just because the output has the right number. #define SIX 1+5 #define NINE 8+1 printf("What you get when you multiply SIX by NINE: %d", (SIX * NINE) ); "The mice will be furious." -- Grumpy Ol' Fred cisin at xenosoft.com

On Thu, 2010-12-02 at 16:48 -0800, Fred Cisin wrote: Which is why you should either bracket arithmetic operations in macros, or declare them as 'const' variables: const unsigned int SIX = 1+5; #define NINE (8+1) And your example gives the result 1 + (5*8) + 1 = (5*8)+2 = 42, because of operator precedence rules (multiply first, then add). What you probably wanted was 54, which is what you'd get if you fixed the constants. Whether this is a bug depends on what the code is meant to do. If it's supposed to give you the answer for 1+(5*8)+1, then it's fine (though I'd call it bad code because there's a significant potential for confusion). If you wanted to know what 6*9 was, then you have a problem... Um, what? -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/

On Fri, 3 Dec 2010, Philip Pemberton wrote: Just need to know what the QUESTION is. The crash on earth of the Golgafrincham B ark was a horrible cock-up, and ruined the project. The last iteration of the search for the question (when Arthur Dent tried to teach a neanderthal to play scrabble) was "Whatdoyougetwhenyoumultiplysixbynine" If that is still a "Um, what?": Douglas Adams "Restaurant At The End Of The Universe" (of "Hitchhiker's Guide To The Galaxy") -- Grumpy Ol' Fred cisin at xenosoft.com

On Fri, 3 Dec 2010, Philip Pemberton wrote: I'd recommend them, assuming that your personal tastes run in those directions. The original BBC TV production was great! The books are great! Five volumes in the trilogy, and a sixth book (by somebody else) that is a moderately good attempt to mimic Adams' style. Adams' other books that are NOT part of the series are also worth reading. The Disney movie: I gave away my DVD. -- Grumpy Ol' Fred cisin at xenosoft.com

Are you talking about the 2005 production? That was done by Touchstone, not Disney. My daughter loves that movie. Of course, she's ten.... The original stories are wonderful and belong in any true geek's collection. "Ford, you're turning into a penguin. Stop it." -- Ian

Touchstone *is* Disney (it's just the 'less kidsy' side of the building). That said, Adams I believe had some role in the script, though I'm sure he took the extent and nature of his contribution to the grave. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- 1-GHz Pentium-III + Java + XSLT == 1-MHz 6502. -- Craig Bruce --------------

On Thu, Dec 2, 2010 at 7:48 PM, Fred Cisin <cisin at xenosoft.com> wrote: There are many things that folks commonly do that are officially undefined... like strlen(NULL) (that returned 0 on an NCR box but segfaulted a SPARC - the NCR guys tried to claim it proved the Sun was broken, but I had to point out that it's undefined). Indeed. Very nice. LOL -ethan

On Thu, Dec 2, 2010 at 5:03 PM, Eric Smith <eric at brouhaha.com> wrote: That's awesome. I didn't see at first that the loop pointer was being used as an array. For some reason it was invisible to me, I guess because I wasn't expecting it. But after seeing that, it became somewhat more obvious to me. :-) This reminds me of a problem I once ran into on AIX. I'm not sure if the latest AIX implementation still has this issue, but it would be easy to find out. I was working on a rather large machine scheduling system for brass foundries. I had been in dbx for several hours trying to track down a particularly nasty bug when I discovered that a rather large calculation had a denominator of 0. I stepped through the line of code anyway expecting an error and instead got a plausible value. So I wrote this quick test program: #include <stdio.h> int main() { int x, y, z; x = 1; y = 0; z = x / y; printf("%d\n", z); } Can anyone guess what the output was? 15. Apparently, according to AIX, 1/0 = 15. At the time, I had access to an HPUX box, so I ran the same program over there. It crashed. The error I got was initially puzzling, but after a few minutes was the key to understanding what was happening over on AIX. The error over on HPUX was "floating point exception". My guess is that most C programmers wouldn't know that the divide operator in C takes floats as parameters. The compiler does an implicit conversion from into to float on x and y, does the divide on the floats (hence floating point exception), then converts the value back to an int for storage in z. It looks like when this implicit conversion is done (on AIX) for the 0, instead of getting official floating point zero, you instead get a close approximation. This approximation divided into 1 gets you a number that rounds to 15. (2/0 yields 30) And since dividing by zero is undefined, you get a crazy answer. So while technically correct, IBM really screws over the programmer here. In my opinion, floating point exception is the correct behavior. And it's what solaris and linux (and probably windows) do also. I was happy when we abandoned AIX. brian

On 2010 Dec 2, at 7:35 PM, Chuck Guzis wrote: The notion of integer divide is pretty well defined. I'd be pretty annoyed if I specced two ints, did a divide and didn't get back the 'standard' result. I don't have a C ref at hand, but in C at least, I think it would be stretching acceptable claims of language flexibility or non-specification for compiler implementors to be taking leniency here.

On 2010 Dec 2, at 8:35 PM, Chuck Guzis wrote: ..right, I was forgetting the OP's original problem was for / by 0, so an exception case. I was just thinking/conjecturing that if the implementors were doing inherent floating point conversions, they better have confirmed that the integer divide result would be correct for all (legal) combinations of operand values, with no (say) off-by-1 situations or what-have-you.

At 9:03 pm -0600 2010/12/02, Brian Lanning wrote: No. The reason you got a "floating point exception" is that Unix traditionally lumps integer arithmetic fault together with floating point faults under one signal, SIGFPE. $ cat t.c int a, b; int main() { return a / b; } $ cc t.c; ./a.out Floating exception(coredump) $ otool -tv -p _main ./a.out ./a.out: (__TEXT,__text) section _main: 0000000100000f20 pushq %rbp 0000000100000f21 movq %rsp,%rbp 0000000100000f24 leaq 0x00000139(%rip),%rcx 0000000100000f2b leaq 0x0000012e(%rip),%rax 0000000100000f32 movl (%rax),%edx 0000000100000f34 movl %edx,%eax 0000000100000f36 sarl $0x1f,%edx 0000000100000f39 idivl (%rcx) 0000000100000f3b leave 0000000100000f3c ret At 10:28 pm -0500 2010/12/02, blstuart at bellsouth.net wrote: Also, "TF"[!b] At 8:35 pm -0800 2010/12/02, Chuck Guzis wrote: The current standard allows operations on that standard signed (but not unsigned) integer types to fail on overflow, but I'm not aware of any implementation that does that. There is no standard way to detect overflow. -- Kevin Schoedel <schoedel at kw.igs.net> VA3TCS

On Fri, 2010-12-03 at 11:32 +0100, Christian Corti wrote: The compiler returns either 0 or 1 for the unary inversion operator. The C standard dictates that 0 is false, anything else is true. Problem is, 'b' can contain damn near anything and still be true. So "FT"[b] with b=0x80 -- b is still true, but you get an access violation, or possibly just a crap result. If your boolean is a true boolean (i.e. only 0 and 1 are valid values, for false and true respectively) then the code *will* work. So you use the unary negation operator, which turns your 0x80 (true) into 0 (false). "TF"[0] is "T", because the original value was true. Similarly, !0 = 1, and "TF"[1] is "F". However: the compiler would still be correct to use the value 123 instead of 1, thus that code may not work... So it's compiler dependent, but most compilers use 0/1 for boolean results, meaning you might not spot the Big Nasty Bug until much, much later. A better way: b?'T':'F' If b is true, then this statement evaluates to 'T', otherwise it evaluates to 'F'. Just it does it without tricky pointer math, and is more likely to work across different compilers. -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/

On Fri, 3 Dec 2010, Sean Conner wrote: Really? His posting is missing in cctalk... [...] Right. Indeed, it's compiler dependent. This doesn't change much because !!123 may still be 123 instead of 1. Christian

On 4 Dec 2010 at 5:37, Sean Conner wrote: Or, to put it another way, the prefix ! operator has the same effect as a comparison to zero. i.e. !(expression) is equivalent to ((expression) == 0) --Chuck

On 2010 Dec 6, at 5:47 AM, Christian Corti wrote: Lame. It was the question. You also said: .. which is incorrect. You're making excuses for yourself.

On 2010 Dec 7, at 2:33 AM, Christian Corti wrote: In the same sense that anything is possible if a compiler can do anything it wants regardless of the language definition, I guess it is. Agreed that double negation is not a fix to the error of said broken compiler, but I wasn't sure that was Sean's point in suggesting double negation. You nonetheless agreed with Phil's assertion that it was compiler-dependant behaviour.

Christian Corti wrote: If it's supposed to be a C compiler, the unary negation operator can only return 0 or 1. It returns 0 if its operand is non-zero, and 1 if its operand is zero. If we're not talking about a C compiler, what are we talking about? Eric

On Sat, 4 Dec 2010, Eric Smith wrote: I was referring to the statement Philip Pemberton made. Christian

On Fri, 2010-12-03 at 17:27 -0800, Eric Smith wrote: OK, tricky pointer math wasn't the right way to put it... What I meant was, it doesn't rely on the compiler returning '0' for a false Boolean evaluation, and '1' for a True evaluation. -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/

On Fri, 2010-12-03 at 18:39 -0800, Eric Smith wrote: Point duly noted... -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/

At 11:50 pm -0500 2010/12/03, Sridhar Ayengar wrote: <http://cm.bell-labs.com/cm/cs/who/dmr/>: 7.2.4 ! expression The result of the logical negation operator ! is 1 if the value of the expression is 0, 0 if the value of the expression is non-zero. -- Kevin Schoedel <schoedel at kw.igs.net> VA3TCS

I have a copy of Draft Proposed American National Standard for Information Systems -- Programming Language C Jan 11, 1988 X3J11/88-001 In section 3.3.3.3 (page 45 line 27) it states The result of the logical negation operator ! is 0 if the value of its operand compares unequal to 0, 1 if the value of its operand compares equal to 0. The result has type int. The expression !E is equivalent to (0==E). Keven Miller ----- Original Message ----- From: Eric Smith To: Sridhar Ayengar Cc: On-Topic and Off-Topic Posts Sent: Saturday, December 04, 2010 01:07 AM Subject: Re: Obscure C code (was Re: Excessive optimization) Sridhar Ayengar wrote: The same thing. I just don't have them handy to give specific section references.

On 3 Dec 2010 at 7:39, John Foust wrote: Not at all. On the CDC 6000, the usual way to do an integer divide by a non-constant was: * Divide integer X1 by X2 leaving result in X3. PX4 X1,B0 PX5 X2,B0 NX4 X4 NX5 X5 FX3 X4/X5 UX3 X3,B3 LX3 X3,B3 Hope I've got the syntax right--it's been 30-odd years since I've written any COMPASS. The point is that on some systems, the only divide is a floating-point one and is by far faster than any bit-by- bit software integer divide. I can't recall, but I think the i860 also falls in this category; the Cray-1 certainly does, not even having a floating-point divide, but rather a reciprocal approximation. On the 6000, system code that needed to calculate a low-precision (say, 18 bits) result often substituted a divide by a constant with an unnormalized double-precision multiply of the shifted reciprocal of the divisor. --Chuck

On Dec 2, 2010, at 10:28 PM, blstuart at bellsouth.net wrote: I've done that a few times. -Dave -- Dave McGuire Port Charlotte, FL

On 2 Dec 2010 at 23:10, Chuck Guzis wrote: Make that #define s "0123456789" --Chuck

Fred Cisin wrote: If you want a giggle - try to follow comp.lang.forth for a couple of weeks - Forth has changed sooooo much in the last 40 years that examples written in many older books simply won't work - I suspect the decline started when ANSI got involved..... Bring back FIG forth I say !!! (Duck)