another bizarre architecture

... snip ...

At one point I used to include a function to report the modules version in each complete module. This allowed users to programatically check for suitability. By also including a #define in the header, this can be expanded to compile time checking. The latter is awkward, since it involves altering the header with each revision, which is counter-productive. Leaving the header alone ensures that a revised version is fundamentally compatible with earlier versions.

Deadlines. That's another reason for the software to be the far from perfect.

BTW, this world is created in the way that it is better to be the first then to be the best.

By MISRA rules, if a function returns an error value, this value should be checked. However not checking the return code is the very common mistake. The exception mechanism was invented to prevent this sort of mistakes.

And nothing happens. The error is unnoticed, fread() reads the garbage, the garbage is processed, and there is garbage at the output.

Good for you. Have you ever wrote anything longer then "Hello World" ?

Yes, I would really like to have MS on my client list.

Keep out. Dealing with the idiot is not worth money.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

That's seomthing I'll never understand. Why would they want to kill it? Everything's just there; all they have to do is just make the damn things. It doesn't cost them a bit, so why stop?

robert

But these are very small projects, in software terms. Any half-decent programmer can do that, no matter in what language. It's the huge, millions-of-lines codebases that break.

I once wrote (as an external contractor) a module for an intranet application. The CTO of my customer really wanted me to use Java just because it was "that's what eveybody uses these days". But since they couldn't find anybody else (those were dot-com boom days) they had to make do with the guy who used a language they'd never heard of -- C.

Last thing I knew was that their application never really got going, except for my bit which worked 100% right from the start.

I remember those panicky calls I got from them: "There's a bug in your module". Panicking myself I rushed into their office, only to see that

--again!-- they had fed invalid data into my module. This was easily demonstrated because it had been *me* who wrote all the specs. Billed them big bucks for that wasted time. Now they are broke.

robert

So, you will actually release software that you know is buggy, or that you haven't tested, because of some schedule? Please tell me who you work for, so I can be sure to never buy their stuff.

John

One of my best customers makes jet engines. The engine control computers are mounted under the engine cowling, in the airstream, and the engine fuel runs through the computer before being burned, to moderate the CPU's temperature swing. The programs have no bugs, because they are careful, work at the lowest possible levels of abstraction, use no OS, test exhaustively, and are entirely pragmatic about the consequences of a jet engine failing. And most of the "programmers" are actually engineers.

John

Those are your speculations. I have never said that.

However, at the end of many projects, I know that it would be better to do the certain things different way.

Get real. From time to time shit happens to anyone, and only fools deny it. And in many cases it is more efficient to have certain allowance for the fault, rather then trying to polish everything to perfection. That's why most of the software and the hardware around is a crap, however it is cheap and available.

It does not matter if you like it or not. It does not have anything with me and my attitude. This is how the things are, and I am just trying to answer your question why everything is so bad.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

What a bullshit.

If you take a closer look to those systems, you will find the same pile of lousy code as everywhere. Well, it is more or less tested so the major bugs are unlikely. If you *really* know how the car or the aircraft is build, you will never drive it or fly by it.

:))))) They probably don't use the power tools also.

and are entirely pragmatic

The consequences are excellent: the insurance company pays out the compensation of $1e7.

Most of the programmers are the former elephant riders or rice farmers.

VLV

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

...Jim Thompson

... 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).

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.

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.

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?

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.