another bizarre architecture
in [Embedded]
|
From: Jan Panteltje on 2 Feb 2007 05:58 On a sunny day (Thu, 01 Feb 2007 21:24:37 GMT) it happened Vladimir Vassilevsky <antispam_bogus(a)hotmail.com> wrote in <pUswh.15243$ji1.10317(a)newssvr12.news.prodigy.net>: > > >Jan Panteltje wrote: > >>>Hey, that's C++! That's cheating! > >There is only one language: C++. The so called C is the malformed >realization of C++, where you have to do classes by hand. Na Stroussup coul not program, C++ is a speech disability. >> >> Yea and it sucks, because 'throw' is not in libc in C. >> And throwing an exeption may not always be what you want, expensive missiles >> have unexpectedly returned to earth that way. > >It is better to stay on the earth rather then fall on somebody's head. >Masking the errors is the worst practice. Yes that is true. But you have to try one day to fly.... Errors will show you where to improve. >> Maybe a if a malloc() fails, and continuing has no perspective, >> but just as well you could in this case return to a GUI that asks for >> a correct user input, so returns SUCKS or return OK, report in the function >> itself, and determine in the calling what to do if it sucks. > >Come on, get real. Nobody bothers about checking the return value. You must be kidding right??????????? Yo uare somebody hwo does this? FILE *fptr; fptr = fopen("filename", "r"); fread( fptr...) BANG if file did not exist! Always, as much as possible, I check return values. It is absolutely essential. >> The good thing he did was check for divide by zero. > >Only the amateurs check the floating point for == or !=. You must be programming for Microsoft :-( >Vladimir Vassilevsky > >DSP and Mixed Signal Design Consultant > >http://www.abvolt.com Have to stay clear of that.
From: Robert Latest on 2 Feb 2007 06:16 ["Followup-To:" header set to sci.electronics.design.] John Larkin wrote: >>You do realise that this is an implementation of the C standard >>library? The behaviour of the functions is spelled out, in detail, in >>the C standard, and any number of C reference books and online >>references. > > Suppose it turns out to have a bug. Although I share your sentiments about the whole software business in general, I must inject here that the C Library (at least all major implementations of it) is pretty much like 68332 in terms of maturity and stability. It's OLD, and its features have been carved in stone by the C Standard since almost 20 years (don't let me get started on the C99 Standard though). robert
From: Vladimir Vassilevsky on 2 Feb 2007 10:13 Jan Panteltje wrote: >>It is better to stay on the earth rather then fall on somebody's head. >>Masking the errors is the worst practice. > > > Yes that is true. > But you have to try one day to fly.... Errors will show you where to improve. 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. >> >>Come on, get real. Nobody bothers about checking the return value. > You must be kidding right??????????? > Yo uare somebody hwo does this? 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. > > FILE *fptr; > > fptr = fopen("filename", "r"); > > fread( fptr...) > BANG if file did not exist! And nothing happens. The error is unnoticed, fread() reads the garbage, the garbage is processed, and there is garbage at the output. > Always, as much as possible, I check return values. > It is absolutely essential. Good for you. Have you ever wrote anything longer then "Hello World" ? > You must be programming for Microsoft :-( Yes, I would really like to have MS on my client list. >>Vladimir Vassilevsky >> >>DSP and Mixed Signal Design Consultant >> >>http://www.abvolt.com > > > Have to stay clear of that. Keep out. Dealing with the idiot is not worth money. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
From: CBFalconer on 2 Feb 2007 08:08 John Larkin wrote: > John Devereux <jdREMOVE(a)THISdevereux.me.uk> wrote: > .... snip ... >> >> You use a version control system. A library like this would be >> maintained and released as a unit, i.e. there will be an overall >> version number like e.g libc 2.1. >> >> Using a version control system it is easy to see exactly what has >> changed between revisions, anywhere in the library. This saves >> having to examine each file individually to see if its version >> number has changed. > > 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!) or > compare the code character-by-character and try to figure out > what's going on. 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? > >> If you really want to you could use the version control system to >> automatically insert a comment with the file version number, but >> I think this is not used much these days. At least I don't; it >> clutters up the file. > > Yes, comments are nasty things. 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. -- <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt> "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
From: Robert Latest on 2 Feb 2007 10:38
["Followup-To:" header set to sci.electronics.design.] John Larkin wrote: >>The MC68332 is about old enough to vote, innit? > > Yup. Freescale would like to kill it, but there are enough users that > they can't. 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 |