Since when is not having a bug patentable?

though.

is

You

would

Did it?

NO, you clearly can't read. I think C does whatever it pleases, which is part of the reason the state of programming is what it is.

This crap is all too common in C. It's no wonder we have all of the malware attacks we do.

If the variables were not defined as signed, you're saying that John is a damned liar. Is that your position?

My favorite '>>' issue with C is that (on an x86, but probably not on an ARM)

for:-

unsigned int x;

x >> 33; is the same as x >> 1

(iow it only looks at the 5 LSBs of the operand- very 8048ish behavior)

On an ARM I'd expect the intuitive result of 0 (32-bit int) for any x if the number of shifts is >= 32.

This is defined in the standard 6.5.7.. wot sez the results are implementation-defined if you try to right shift as many or more bits than are in the operand (or if the number of shifts is negative)- (so don't do that).

Fortunately there are a limited number of these gotchas, so you run through them sooner or later.

though.

I was discussing a problem with a C compiler, and expressing my general feeling that C is an obsolete language full of hazards.

Martin has responded by calling me stupid, calling me a liar, and referring to my programmer as a code monkey who needs to read "C for Dummies."

He has challenged me to prove stuff to him. I'm not interested, because I don't give a damn what he thinks or does. There is an infinite supply of un-likable people, and there's no point in trying to discuss things with them.

--

John Larkin         Highland Technology, Inc

jlarkin at highlandtechnology dot com
http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom laser drivers and controllers
Photonics and fiberoptic TTL data links
VME thermocouple, LVDT, synchro   acquisition and simulation

Sounds like that that compiler is broken, all the parameters are signed, even the 4096 is signed, there no reason for it to generate an unsigned shift

--
?? 100% natural

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net

I think this is a general problem with many compilers and language standards: There is an informal description of the language, like the C language standard, and then the compiler vendors are trying to implement it. You can't prove that the implementation and the generated code is right. To be 100% sure you have to verify the assembler output and try to compare it with the intention in the source code, or at least you have to write many tests.

There are better ideas, like in Haskell, which has some simple language constructs, and then a "prelude", which defines more advanced concepts, but with the basic language. Or Fortress (

), which looks already like mathematics. But I don't know a language, where you can prove down to the assembly level, that the compiler, the output it generates and the runtime system (if needed), is correct and where the language definition itself is based on mathematics, like axioms and provable theorems. Maybe for non-mathematicians it would be more difficult to write programs with it, but I'm sure it would lead to less bugs.

--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

it works fine here.

int32_t blah(int32_t a,int32_t b) { return a * b / 4096; }

compiles with optimisation level 2 as

blah: @ Function supports interworking. @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. mul r0, r1, r0 add r3, r0, #4080 cmp r0, #0 add r3, r3, #15 movlt r0, r3 mov r0, r0, asr #12 bx lr .size blah, .-blah I don't speak "arm" but it looks like it's asking for arithmetic shift right after optionally padding the value to get the standard rounding towards zero and when tested appears to do so both under QEMU and on real hardware.

--
?? 100% natural

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net

no, rounding it up to FFFDEADC would be rounding towards zero

--
?? 100% natural

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net

I think every one agrees it shouldn't, the question is why it did.

I real curious if John could show how the variables was defined, because I also use gcc for arm (codesourcery not code red but I believe it is the same gcc) and I can't make it break like he did.

int test1( int A, int B) { int rval; rval = A * B / 4096; 8002710: fb01 f000 mul.w r0, r1, r0 8002714: f500 637e add.w r3, r0, #4064 ; 0xfe0 8002718: 331f adds r3, #31 800271a: ea30 0020 bics.w r0, r0, r0, asr #32 800271e: bf28 it cs 8002720: 4618 movcs r0, r3 return rval; } 8002722: 1300 asrs r0, r0, #12 8002724: 4770 bx lr 8002726: bf00 nop

08002728 :

int test2(int A,int B) { int rval; rval = A * B; 8002728: fb01 f000 mul.w r0, r1, r0 rval = rval >>12; return rval; } 800272c: 1300 asrs r0, r0, #12 800272e: 4770 bx lr

-lasse

result

that

=20

run

Very clear. Thank you.

?-)

Thank you Jasen. Looks increasingly like user error. Why am I not at all surprised?

--
Regards,
Martin Brown

though.

is

They are now. I was prepared to give him the benefit of the doubt until his latest ridiculous claims. The C language is well defined for the handling of mixed signed and unsigned integer arithmetic as far back as K&R first edition (see page 184 para "6.5 Unsigned" ). You may not like the definition (or even allowing implicit type conversions at all) but the original C standard does define the correct behaviour here.

It is an interesting philosophical question as to whether someone who clearly does not know what they are talking about can be lying. The latter term implies that they know the truth but are hiding it.

I think ignorant and arrogant is a far better description. John made a bogus claim and then later asserted that he "looked it up" - and at that point he was lying but until then he was simply misinformed.

There is no C reference book that I know of that would support his position not even "C for Dummies". I was a bit unfair to that book - they do not make such crass mistakes.

You must have been looking in the mirror. You had a choice but you have conclusively proven that you know even less about the subject than John.

You are utterly clueless.

--
Regards,
Martin Brown

Anyone with a clue would rescale the numerator "scale factor" to compensate. And for a 16 bit dac or less you could choose the scale factor so that the high word was the required result no shift needed.

The purpose here is to establish whether the fault is in the expression being compiled or at the code generation peephole optimiser stage.

The behaviour for shifts that are negative or > bit_width are decidedly compiler dependent and cannot be relied upon. Some smarter compilers will spot expressions that must evaluate to zero at compile time but most fed x>>y will generate code for a shift by (y modulo bit_width).

The secure coding website run by Carnegie Mellon deals with defensive strategies for this under INT34-C and many other potential C gotchas.

And as far as unexpected promotions of integer types is concerned.

Pity that John didn't know where to look it up.

--
Regards,
Martin Brown

though.

experiencing is

As long as everyone here knows who *you* are...

This was revealed in 1993.

====================== Begin ======================= CREATORS ADMIT UNIX, C HOAX

In an announcement that has stunned the computer industry, Ken Thompson, Dennis Ritchie and Brian Kernighan admitted that the Unix operating system and C programming language created by them is an elaborate April Fools prank kept alive for over 20 years. Speaking at the recent UnixWorld Software Development Forum, Thompson revealed the following:

"In 1969, AT&T had just terminated their work with the GE/Honeywell/AT&T Multics project. Brian and I had just started working with an early release of Pascal from Professor Nichlaus Wirth's ETH labs in Switzerland and we were impressed with its elegant simplicity and power. Dennis had just finished reading 'Bored of the Rings', a hilarious National Lampoon parody of the great Tolkien 'Lord of the Rings' trilogy. As a lark, we decided to do parodies of the Multics environment and Pascal. Dennis and I were responsible for the operating environment. We looked at Multics and designed the new system to be as complex and cryptic as possible to maximize casual users' frustration levels, calling it Unix as a parody of Multics, as well as other more risque allusions. Then Dennis and Brian worked on a truly warped version of Pascal, called 'A'. When we found others were actually trying to create real programs with A, we quickly added additional cryptic features and evolved into B, BCPL and finally C. We stopped when we got a clean compile on the following syntax:

for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

To think that modern programmers would try to use a language that allowed such a statement was beyond our comprehension! We actually thought of selling this to the Soviets to set their computer science progress back 20 or more years. Imagine our surprise when AT&T and other US corporations actually began trying to use Unix and C! It has taken them 20 years to develop enough expertise to generate even marginally useful applications using this 1960's technological parody, but we are impressed with the tenacity (if not common sense) of the general Unix and C programmer. In any event, Brian, Dennis and I have been working exclusively in Pascal on the Apple Macintosh for the past few years and feel really guilty about the chaos, confusion and truly bad programming that have resulted from our silly prank so long ago."

Major Unix and C vendors and customers, including AT&T, Microsoft, Hewlett-Packard, GTE, NCR, and DEC have refused comment at this time. Borland International, a leading vendor of Pascal and C tools, including the popular Turbo Pascal, Turbo C and Turbo C++, stated they had suspected this for a number of years and would continue to enhance their Pascal products and halt further efforts to develop C. An IBM spokesman broke into uncontrolled laughter and had to postpone a hastily convened news conference concerning the fate of the RS-6000, merely stating 'VM will be available Real Soon Now'. In a cryptic statement, Professor Wirth of the ETH institute and father of the Pascal, Modula 2 and Oberon structured languages, merely stated that P. T. Barnum was correct.

In a related late-breaking story, usually reliable sources are stating that a similar confession may be forthcoming from William Gates concerning the MS-DOS and Windows operating environments. And IBM spokesman have begun denying that the Virtual Machine (VM) product is an internal prank gone awry. {COMPUTERWORLD 1 April} {contributed by Bernard L. Hayes} ======================= End ========================

--

Reply in group, but if emailing add one more
zero, and remove the last word.

--

John Larkin         Highland Technology, Inc

jlarkin at highlandtechnology dot com
http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom laser drivers and controllers
Photonics and fiberoptic TTL data links
VME thermocouple, LVDT, synchro   acquisition and simulation

[...] JL > The Space Shuttle, on its very first launch, JL > took a crew into orbit and brought them back alive.

Where did you get the idea that was a triumph of perfectionism and fine craftsmanship over testing, Mr. Larkin?

Isn't the equipment you make used for testing? LOL

Much of the important stuff on the shuttle could not be tested. Like the guidance servos in an acutal trans-sonic flight to orbit, the re-entry dynamics, fuel flow at 7Gs and at zero Gs, stuff like that.

--

John Larkin         Highland Technology, Inc

jlarkin at highlandtechnology dot com
http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom laser drivers and controllers
Photonics and fiberoptic TTL data links
VME thermocouple, LVDT, synchro   acquisition and simulation

We had them in 1972 at Ft. Rucker, Alabama that baked & sold pizza in front of your barracks

Mobile food vendors have been around for a long time. Working many port towns and other transportation hubs since at least the 1700s (fish and chips in London, minimum), maybe since Rome or ancient Greece.

?-)