another bizarre architecture

Hardware will fail quite often due to radiation, EMC problems, UPS failure or simply capacitor "rot".

I try to write my software so that it wont't fail until I am retired.

You have memory leak problems only if you use deallocators :-).

A program can use allocators at startup, but should avoid them during the next decades the program is running.

Paul

That is a lot of code for a short amount of time .... I'm starting to get an inferiority complex. Bug free as well ???

Right, that's it, I'm out of here ;-)

Regards,

Paul.

So clean, safe, documented, bug-free code is routinely produced when it matters. But a premise is that the people who create the code first have to believe that clean, bug-free code is possible, and then they have to pragmatically adopt the engineering disciplines needed to make it so.

It helps if they have never studied CS, and that jet engines are not abstractions to them.

John

typically they will be in the charge of the revision control system

there's a program called diff that compares text files and points out differences..., it's great for this sort of stuff.

you read the changelog.

Noone should modify a libgary function in a way that reduces it's capability. Adding sign checks to the resistor function would be a bad thing, - suppose you were using it elsewhere on an inverting transconductance stage,,,

Bye. Jasen

I think Homer is calling in all of his friends to show their idiocy, in an attempt to lower the standards. :(

--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida

The biggest help is that jet engine control does not require a complex program with millions of bits of state, so that abstractions are not needed. Once you are familiar with the math and physics involved, the actual software is not a big deal.

Real big CS tasks, such as synthesizing, floorplanning and routing an FPGA based on HDL description are immensely more complex. These programs require millions of lines of code, and megabytes worth of state to accomplish their task. The user input is never the same, so every time you run the program, it follows a completely different path through all the states, most of which could never have been tested before. Without abstractions upon abstractions, our brains are simply too small to comprehend the entire program at once. Of course, once you cannot hold everything in your brain, you are much more likely to make mistakes and miss subtle interactions between different parts.

On a sunny day (Fri, 02 Feb 2007 14:56:05 -0500) it happened CBFalconer wrote in :

There is a problem with that, in case of text, consider this on gcc3.3:

Try this, #include

main() { fprintf(stderr, "Hello\n World\n"); }

grml: ~ # set-gcc-2.95 Reading specs from /usr/lib/gcc-lib/i486-linux-gnu/2.95.4/specs gcc version 2.95.4 20011002 (Debian prerelease) grml: ~ # gcc -o test4 test4.c grml: ~ # ./test4 Hello

World grml: ~ #

That compiles and works as expected.

But now with gcc-4.0: grml: ~ # set-gcc-4.0 Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v

--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr

--enable-shared --with-system-zlib --libexecdir=/usr/lib

--without-included-gettext --enable-threads=posix --enable-nls

--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu

--enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo

--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr

--disable-werror --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.3 20060104 (prerelease) (Debian 4.0.2-6) grml: ~ # gcc -o test4 test4.c test4.c: In function 'main': test4.c:8: error: missing terminating " character test4.c:9: error: stray '' in program test4.c:9: error: 'World' undeclared (first use in this function) test4.c:9: error: (Each undeclared identifier is reported only once test4.c:9: error: for each function it appears in.) test4.c:9: error: syntax error before 'n' test4.c:9: error: missing terminating " character

Have fun.

That is true, about the ''.

What is not so good here, is that you use an if-else after an error return. The normal program flow is to eliminate all special conditions, and then end up with a usable case:

if(this_wrong) return ERROR_THIS; if(that_wrong) return ERROR_THAT; if(disaster) { eject(); exit; } do_your_thing return OK

No need for if-else, and always the fastest way out, (as one would (hopefully) do in asm too).

In fact if-else, and especially 'else' is a very very dangerous statement, as else includes all other cases!

:-)

On a sunny day (2 Feb 2007 19:17:49 GMT) it happened jasen wrote in :

You check the return value and look at errno. Read the rest of the thread (and libc.info, but I know you did read that).

It is not so pointless if that makes the rest of your processing not needed. I did refer him to sci.physics for super conductor ;-).

Tell that my math teacher ;-)

You have failed to supply the closing quotes, i.e.:

fprintf(stderr, "Hello\n" "World\n");

Please snip useless portions. The practice of topposting something that has a selected quote is ridiculous. Snip the irrelevant portions of the quote.

--
 

 "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 20:45:57 GMT) it happened Vladimir Vassilevsky wrote in :

Oh really, well and you insult open source programmers too, maybe because you steal their code and use in your close sources projects? WTF should I bother with somebody who does not check return values, or refuses to learn about the C library.

On a sunny day (Fri, 02 Feb 2007 23:17:03 +0200) it happened Paul Keinanen wrote in :

That may be really difficult if you want to process video or images for example. (User opens a bigger jpeg for example).

On a sunny day (Fri, 02 Feb 2007 13:55:44 -0800) it happened John Larkin wrote in :

I can agree with that, but it gives me that sales people feeling. There was the NASA PC soft for the mars rovers, it was written in Java IIRC, and it had a 3D verison for on the PC for Linux. I installed it, and it 1) did not install (path was wrong and hardcoded IIRC),

2) got stuck after fixing that. I realized something that moment I looked at that code, and I made the statement in sci.astro, that if the same people programmed the_real_ rover, then it would be in serious problems. Of course it _WAS_ in serious problems when its directory structure filled up with too many files a week later.... (IIRC). They fixed it remotely (relief). I can feel that signature of disaster programming from just a quick look it seems.

So, if you can do it, very good. But some still have a learning curve to take.

On a sunny day (Sat, 03 Feb 2007 06:02:12 -0500) it happened CBFalconer wrote in :

Take your pills

... snip ...

PLONK.

--
 

 "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

not),

It's pretty rare that a chip has a bug that is not documented, as opposed to a faulty device. Certainly someone has to find unintended features of ICs, but more often than not it is the manufacturer, although Joerg had some frustrating times with a TI LDO. That said, I review all the documents for a chip thoroughly, just as John notes below, including any errata. My datasheet error rate (finding incorrect or even missing information in a datasheet) is pretty high; probably about 1 in 5 data sheets. I would prefer the information to be missing to being wrong - I know a number of people who have been bitten by such things. I then talk to the manufacturer to get the right answer; refusal to accept/fix an error in the datasheet is grounds to ditch the part.

I (and probably any designer of reasonable experience) use that same discipline. Software guys'n'gals might not understand the shudders the words 'single-source' and 'allocation' cause to a hardware designer.

It's a good thing to have an anal-retentive parts czar for a lot of reasons. The two primary ones (my view, YMMVG) are a part I am already using is known to operate within a spec (which may or may not be the datasheet, but it's the devil I know) and using the same part gives me economies of scale, quite apart from the administrative and engineering cost of adding a part, new schematic part, new symbol (all of which must be checked of course), footprint etc.

Again, (for Jan's benefit) this is a discipline that hardware designers live with daily.

Amen.

Well, code reviews can happen, but in general (as with all generalisations, it's not necessarily true of any one person) software types tend to be more defensive about their designs that hardware. I've been in design reviews where asbestos underwear might have been a reasonable clothing choice, but all the comments were criticism of the design and methodology, not the person. I've also noticed this tends to afflict pure HDL people as well (as opposed to a board designer who also does HDL). Obviously, YMMVG.

With a defensive posture, the review breaks down long before any reasonable work could be done. I've let hardware designers go because they couldn't separate criticism of a design from criticism of themselves as people, and therefore simply argued because they felt insulted rather than argue the technical merit of their approach.

I've done a huge amount of code to test hardware, and it is (imo) perhaps the toughest code I had to write. It has to trap all possible errors (and report unusual events I had not foreseen) without crashing / unloading the driver / other side effects; indeed the test code has to be so robust it keeps on running even in the event of a critical failure of the test item *so I can know what failed*.

Typical production code just bombs out with 'failed' - like that's really a lot of information. At one place we had a some compact PCI boards we designed and I rewrote the drivers so they wouldn't just stop on encountering an error; they instead maintained a status word that could be queried so I would know that *if* the driver encountered problems it could let me know what the problem was. That code was ultimately found to be quite useful and ended up in the shipping product.

siliocon.

Perhaps discipline is the key; software can simply edit and rebuild, but a hardware change is not quite as simple. For that reasons we have to strive all the time to 'get it right the first time', a discipline some in software see as not applicable (perhaps with some justification, although I don't subscribe to that view).

I still wish for FPGA design tools that will let me override the optimisation settings on a per module (at least) basis - I might have very good reasons for not desiring to optimise a gate away. Indeed some tools are, in a phrase I have coined many a time, 'just smart enough to be stupid'.

Schematic and layout tools have their issues, but given the type of feedback those vendors get, they aren't nearly as bad as some synthesis tools.

Cheers

PeteS

So what? Comments aren't executed. Comments are for conveying to the human reader the reasons for the instructions used. Justifications for decisions taken, limitations of the routine/approach. To let the reader know what is supposed to happen and how ro use the routines in question. Sometimes the explanation will, of course, be too involved to include in the comments in its entirety and in that case they may refer to external references such as standards texts and of course lab book derivations.

And banks are robbed. Theft is however, still illegal. Just because people don't take the discipline to do something properly does not mean it should not be done. And I don't intend to hold myself up as a paragon of virtue in that regard either, part of the discipline of programming is continually correcting bad habits. And comments must be maintained just as the code does.

A source code file more nearly resembles a schematic than it resembles a layout. It's at least as much about communicating intent to the human as it is about communicating to the compiler.

So can I. That doesn't mean they shouldn't be there. And part of his complaint as well as a big part of mine is that the larger more complex functions are even worse.

As an example the header in one file contains the following

• FILE: lib/crtdll/conio/kbhit.c * PURPOSE: Checks for keyboard hits

And the first function starts as

int fflush(FILE *f)

Now either they've used very bad practice and fflush check for keyboard hits, or the header is completely at odds with the body. It would be laughable it it weren't tragic. If it were an isolated case it could be just a simple error and would hardly be worth this complaint, although it should still be corrected. It is not isolated though.

I'm not saying you are. Just that the commenting in the example John was given was poor. Unfortunately it appears the other examples on the same site are worse. Not much wonder John dislikes C if that's what he's got to go on.

Robert

--
Posted via a free Usenet account from http://www.teranews.com

Now that's more like it. There's no reason the original example couldn't have been done that well. It just take a certain amount of self discipline and pride in your work.

Robert

--
Posted via a free Usenet account from http://www.teranews.com

Poor discipline is the bane of the industry, and I must agree with John on this, even though I prefer to write in C.

#include I have spoken with many a programmer unworthy of the name if only because they think hardware is something that automagically does what they need; it's the product of a great deal of hard disciplined work!

In this, incidentally, I include those who are software engineers and computer scientists (I have yet to divine the distinction).

#undef rant

Discipline is something foreign to many software engineers (but not all, as I can attest from personal knowledge) and is necessary if a product is to be successful.

So the answer seems to be; a disciplined approach is likely to produce successful results. Duh.

Cheers

PeteS

there's no bad consequence from doing fread() on a FILE* that may be NULL. The real problem is ignoring the return from fread, suppose the file is too short for instance.

Bye. Jasen