another bizarre architecture
in [Embedded]
|
From: Rich Grise on 2 Feb 2007 20:53 On Fri, 02 Feb 2007 20:54:53 +0000, Vladimir Vassilevsky wrote: > John Larkin wrote: >> >> Strange. Some people have a powerful vested interest in the premise >> that good programming is impossible. > > It is not impossible. It is just not worthy in many cases. > Or an attitude like this, which is even worse. Thanks, Rich
From: jasen on 2 Feb 2007 21:54 On 2007-02-02, John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: > If your vc system tells you that two subroutine sources differ, what > do you do? > It certainly can't tell you *why* they differ, or how they > might behave differently. For that, you must either read the comments > and revision notes (lots of luck finding them!) typically they will be in the charge of the revision control system > or compare the code > character-by-character and try to figure out what's going on. there's a program called diff that compares text files and points out differences..., it's great for this sort of stuff. > Or just > use the latest one, on the assumption that any bugs aren't your fault. > > Now, what do you do when 12 versions differ? 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
From: Michael A. Terrell on 3 Feb 2007 00:03 Jim Thompson wrote: > > On Fri, 02 Feb 2007 17:16:14 GMT, Vladimir Vassilevsky > <antispam_bogus(a)hotmail.com> wrote: > > > > > > >John Larkin wrote: > > > >>>Look at Airbus fly by wire, _that_ is professional software with > >>>lives at stake. > >> > >> > >> 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, > > > > > > > >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. > > > > > >> work at the lowest possible levels of > >> abstraction, use no OS, test exhaustively, > > > >:))))) > >They probably don't use the power tools also. > > > > > > and are entirely pragmatic > >> about the consequences of a jet engine failing. > > > >The consequences are excellent: the insurance company pays out the > >compensation of $1e7. > > > >> And most of the > >> "programmers" are actually engineers. > > > >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 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
From: Jan Panteltje on 3 Feb 2007 05:49 On a sunny day (Fri, 02 Feb 2007 14:56:05 -0500) it happened CBFalconer <cbfalconer(a)yahoo.com> wrote in <45C39755.6790C28B(a)yahoo.com>: >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: There is a problem with that, in case of text, consider this on gcc3.3: Try this, #include <stdio.h> 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. >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 */; >} That is true, about the '\'. >Note how I try to associate a format specifier with the appropriate >object. By the way, negative resistance normally implies an >amplifier. 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! :-)
From: Jan Panteltje on 3 Feb 2007 06:30
On a sunny day (Fri, 02 Feb 2007 23:17:03 +0200) it happened Paul Keinanen <keinanen(a)sci.fi> wrote in <t997s2d59g1fpso0ql2rgbrs3ca2h129p7(a)4ax.com>: >On Fri, 02 Feb 2007 12:26:59 -0800, John Larkin ><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: > >>But it's seldom the CPU or the memory that fails; > >Hardware will fail quite often due to radiation, EMC problems, UPS >failure or simply capacitor "rot". > >>it's the software itself. > >I try to write my software so that it wont't fail until I am retired. > >>Memories don't leak, but memory allocators/deallocators do. > >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 may be really difficult if you want to process video or images for example. (User opens a bigger jpeg for example). |