another bizarre architecture

Hey, John Larkin! How come you keep attracting the nutcases ?:-)

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
|  Analog/Mixed-Signal ASIC\'s and Discrete Systems  |    manus    |
|  Phoenix, Arizona            Voice:(480)460-2350  |             |
|  E-mail Address at Website     Fax:(480)460-2142  |  Brass Rat  |
|       http://www.analog-innovations.com           |    1962     |
             
I love to cook with wine.      Sometimes I even put it in the food.

... snip ...

The code may or may not be lousy, in terms of clarity and maintainability. However, it will not be buggy. You are obviously unfamiliar with what it takes to get instrumentation certified for airworthiness. The specifications may have been foolish (i.e. the Airbus fiasco).

--
 

 "A man who is right every time is not likely to do very much."
                           -- Francis Crick, co-discover of DNA
 "There is nothing more amazing than stupidity in action."
                                             -- Thomas Matthews

at least it's C.

not in C it's not.

Bye. Jasen

Yes it can. The source files contains comments describing them. A diff performed on two copies of the library will show exactly the differences in the comments, as well as in the code.

Comments are in the source file.

You can run a "diff" command on the whole library, or on any subset thereof, to show all the differences between any version and any other. The Changelog will also contain comments saying what changed and why.

Of course I comment the source code - I was just making the point that you don't always want some "version" number written as a comment in the C source file. There can be better ways to handle revision control than typing a number into each source file.

--

John Devereux

Apparently so. Did you miss the part where he expressed his desire to be a member of the MS crew?

Given his post, I'd sure never hire the guy. "However not checking the return code is the very common mistake. The exception mechanism was invented to prevent this sort of mistakes."

No, Vladimir. Learning how to program properly was invented to prevent this sort of mistakes[SIC]. "Exceptions" just add another level of bloat to protect scriptkiddies from their ignorance.

And who's to say the guy who wrote the exception routines wasn't just as sloppy of a "programmer" as the idiot who's depending on the machine to do his thinking for him?

Thanks, Rich

divide by a too-small or zero and you'll get some sort of infinite or not-a-number from the divide,

so, just divide and check the result using isfinite or isnormal(). depending on the result you're expecting.

Bye. Jasen

At twelve to fifteen bucks a pop, it'd almost be worth plopping a core into a mongo CPLD ;-)

Cheers! Rich

It's easy to post bad code, how would you fix it?

seriously, checking for equal to zero is pointless,

The number could be so close to zero that it would have pracctically the same result as dividing by zero (the only difference is you get "infinite" as a result instead of "not a number")

double d = 1.2 - 0.4 - 0.4 - 0.4; d is a small number, but, quite possibly, not 0.

Bye. Jasen

It looks like yet-another-risc-processor which doesn't program well using c . Where other players in the field (like TI) discovered programming a risc processor takes a lot of code to do something. The MSP430 series is extremely efficient when it comes to code size.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

... snip ...

There is no need to use those continuation lines, which just distort your code. A '\n' is just another whitespace char. to a C compiler. In addition strings separated by only whitespace are automatically concatenated. You can be much clearer with:

BOOL calculate_current(double resistance, double voltage, double

*current) { if (debug) { fprintf(stderr, "calculate_current: %f %f\n", resistance, voltage); } if (resistance < 0.0) { fprintf(stderr, "My-Program: calculate_current():\n" "Your resistance is negative (%.2f)," " you must be kidding right? Aborting.\n",\ resistance); return SUCKS; } else /* whatever */; }

Note how I try to associate a format specifier with the appropriate object. By the way, negative resistance normally implies an amplifier.

--
 

 "A man who is right every time is not likely to do very much."
                           -- Francis Crick, co-discover of DNA
 "There is nothing more amazing than stupidity in action."
                                             -- Thomas Matthews

... snip ...

Look at the documentation for your version control system. There is almost certainly a way of automatically updating a version comment when the source is checked in. No pain whatsoever.

--
 

 "A man who is right every time is not likely to do very much."
                           -- Francis Crick, co-discover of DNA
 "There is nothing more amazing than stupidity in action."
                                             -- Thomas Matthews

On a sunny day (Fri, 02 Feb 2007 15:13:53 GMT) it happened Vladimir Vassilevsky wrote in :

Yes, but it is realy bad not to check return values. In fact the soft would be worth absolutely nothing.

^^^^^^^^

Yes a _mistake_, do not make these!!

Yo uare just from school right? #include #include

main() { FILE *fptr = 0; char buffer[100]; size_t bytes_read;

fptr = fopen ("flipflap", "r");

// size_t fread(void *ptr, size_t size, size_t nmemb, FILE *stream); bytes_read = fread(buffer, sizeof(char), 100, fptr);

fprintf(stderr, "bytes_read=%d\\n", (int)bytes_read); }

Compile this: grml: ~ # gcc -o test3 test3.c

Run it: grml: ~ # ./test3 zsh: segmentation fault ./test3

Create the missing file: grml: ~ # touch flipflap grml: ~ # ./test3 bytes_read=0

You should REALLY and I mean _REALLY_ have a good read at libc.info. You can find it in /usrshare/libc.info* on a Linux system. It will take you a few month. After that you will check return values.

My programs are used all over the globe. Several are downloaded each day from my site. I get very very few problems reported, and it runs on many systems.

Try to learn, else you will always talk crap.

On a sunny day (Fri, 02 Feb 2007 08:46:12 -0800) it happened John Larkin wrote in :

So?

That would be an honor to have MS on my client list.

Go to hell. No problem. I can afford not working for fools.

"However not checking the

People are weak. They do mistakes much more often then the machine does. The more they are restricted and abstracted, the less likely they will screw up. Look at the tremendous success of labview, matlab and automatic code generation tools.

"Exceptions" just add another level of bloat

You got to understand that the programming is no longer the black art for the chosen ones, but a dirty work for the cheap bunch.

There is a difference. There should be one smart guy to create the development framework, so the bunch of mediocrits can use it.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

Didn't try that. CMOS seems to generally slow down a few tenths of a per cent per degree C (anybody got better numbers?) so we probably have lots of margin at 20 MHz.

John

Strange. Some people have a powerful vested interest in the premise that good programming is impossible.

John

But it's seldom the CPU or the memory that fails; it's the software itself. Memories don't leak, but memory allocators/deallocators do.

John

The road to hell is build of good intentions. If everybody could be always perfect, we would live in the perfect world.

Independent contractor, Ph.D., ~20 years experience, ~10..15 projects per year, automotive, instrumentation, DSP, the products are manufactured in the quantities ~ tens of thousands units p.a., customers worldwide.

JFYI: there are no such things as char, int, float, double. There are machine independent u8, s8, f32, s32 and such.

Don't care. This is a task for juniors.

I don't share the views of linux opensource gnu maniacs.

A lousy C programmer is teaching me. First, you should learn how to write clear, safe and portable code. :)

URL?

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

On a sunny day (Fri, 02 Feb 2007 12:26:59 -0800) it happened John Larkin wrote in :

John, its not fair. Its late here, but anyways.... Software does not 'start failing' all of the sudden, unless data was damaged (the executable), if you started with good software. Same for hardware, but hardware _WILL_ fail over time. Be it electrolytic caps, overloads, or whatever.

I must say if you can write perfect software that is very good. I _do_ put restriction on what I am prepared to do, this especially in view of 'attacks' (as via the internet), 'fixed' jpeg or movies, what not (often buffer overflow exploits). I do not at this time design for life support systems so I feel safe. Nevertheless, unlike Vladimir, I try to write correct code, and some lively discussion on the issue of headers and structures on 32 and 64 bit machines happened recently in comp.os.linux.apps, that caused me to re-write some of my code (although it worked OK). The perfect portable code likely does not exist anyways. In the case of the airplane, I do not know what it did you wrote, but some systems are more complicated then a simple controller and the chances of something going wrong are then bigger, so maybe 3 systems are used with an arbiter.. Especially in the case of airplanes or space, a cosmic ray can cause your hardware to do unexpected things (and the software), so triple redundancy was for example already in the Concorde. So... and now with glass cockpits (all TV screens) I would expect to see a lot of these triple systems... Arbiter is in itself some fascinating thing.