Den tirsdag den 5. november 2013 23.15.35 UTC+1 skrev John Larkin:
which is how windows gets owned, imagine millions of people with an economic incentive to break your app, they would eventually find a way
-Lasse
Well, all it did was restart the app. No way to get rich off that.
-- John Larkin Highland Technology, Inc jlarkin at highlandtechnology dot com http://www.highlandtechnology.com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom laser drivers and controllers Photonics and fiberoptic TTL data links VME thermocouple, LVDT, synchro acquisition and simulation
You can also use functions as arrays. :^)
I recall there's an IOCCC program that tells you what processor it's been compiled for. It's portable, but unportable (rule abuse!), and contains things like reading main() as an array. Can't seem to find it...
Tim
-- Seven Transistor Labs Electrical Engineering Consultation Website: http://seventransistorlabs.com
On a sunny day (Tue, 05 Nov 2013 23:00:25 +0100) it happened Jeroen wrote in :
I use 'joe' as editor, been using it since 1998 or so. Full screen text editor, small fast.
Lots of control key combinations, ctrl K b, ctrl K v, ctlr K x etc. I have it as default editor in this newsreader, NewsFleX:
It crashes about once a year, I think I know why, but once a year is good enough for me. It has a nice database too, goes back to last century, with search functions.
Now compare that to the current 'multi zilion dolar capable' google newsgroup mess.
Yes same here.
There is one rule I have: You HAVE to use your own programs, best way to improve and debug them...
On a sunny day (Tue, 05 Nov 2013 14:15:35 -0800) it happened John Larkin wrote in :
My newsreader will crash when you feed it a line longer than (some value), as it will overwrite some temp array. This is deliberate, it is called a back door, cannot say who suggested it, top secret.
;-)
Most but not all C buffer overruns trace to a canonical line of undefended code which usually looks something like this:
while (*d++=*s++);
Where d points to a buffer of very finite length and s points to a null terminated string or object that has been designed to fib about its length and is really much longer than the destination buffer.
But that exploit is mainly a Windows weakness. The IBM MS collaboration to write OS/2 was a hard segmented architecture with code and data segments rigorously separated on the same CPU. Industry chose the mess that would become Windows over OS/2 + PM largely because they feared a FUD lock in with the horrible new IBM hardware PS/2 MCA architecture.
If you want to prevent data executing then having a separate address space is one way to strictly enforce it (although the OS itself has to be able to load programs into the address space and flick a switch). Data execution prevention helped for a while on Intel CPUs but the bad guys have now found ways and means to defeat it.
You do realise that your favourite Motorola CPU pioneered the flat memory architecture with its early 16/32bit micros like the 68k. Apple seemed to have no great problem writing their OS robustly on the 68k architecture and in the same language. You can't blame the programming language used for an MS corporate "ship it and be damned" culture.
-- Regards, Martin Brown
There is a cute old program called paranoia that tests all this stuff. The results on some optimising compilers are decidedly interesting.
Pointer to specific object is usually safe enough. I know of one compiler that by default will code a hard trap if any attempt is made to use an uninitialised variable on the RHS of an expression. I have my copy set to warn on finding them when compiling legacy code. It is not unusual to find one or two in 10k lines of code that have lain undetected since it was written. I reckon you always learn something from porting a "Portable" computer code to a new compiler or CPU.
C++ is better, but if you actually care about avoiding ambiguities then you need to use a strongly typed language that makes it so.
The sad thing is that static analysis tools do exist to catch a lot of this sort of stuff but hardly anyone has been taught to use them :(
XP is near end of life but there are a huge number of them running and connected to the internet. When it goes end of life with no further updates those machines will become the zombie hoards...
Certain secure languages have withdrawn unsigned (a decision I seriously disagree with) on the grounds of having closure.
One thing that really depressed me recently was watching an online lecture given by one of the world exponents of good software design. Unfortunately I found myself counting the careless errors in his presentation and example code. This problem is endemic :(
There is also a tendency to view software as flexible and something that can be fixed later after the product has been sold to the punters.
There is also the minor problem that in binary logic a single bit error can give the exact opposite of what you intended.
-- Regards, Martin Brown
To some extent I agree with you. There is too much code, crash and burn in the software industry, but that is what the customers demand!
Some places certainly do. And I do not defend the all too common practice of random application of casts to hide compiler warnings.
There are static analysis tools that can find latent faults and code that is for example too complex for anyone to properly understand. You can't be sure it is buggy, but beyond a certain level of complexity you can be pretty sure that it is the right place to concentrate testing.
There is a lot to be said for having post mortem debuggers that can examine a processes last dying moments. Several compilers I have used back to the mid 1980's had this feature and it was usually possible to find root cause and eliminate it for every in service fault reported. Windows sort of has this in DrWatson and its own reporting scheme but it is a pale shadow of earlier tools that it tries to imitate.
It can be. It must have escaped your notice but the simulators and design tools used for all modern CPUs and electronics circuits are based on very large complex software programs that are good enough to model your electronics designs accurately. They have their quirks but most of the time they do work and there is some very sophisticated sparse network nonlinear numerical solvers deep inside doing the work.
Where would you be without Spice?
-- Regards, Martin Brown
68K was really a 32-bit version of the PDP-11, with more registers. The later 11s, and most of the 68Ks, had memory management that segmented or paged regions that could be execute-only, data-only, read-only, no access. In general, the OS mapped a process so that nothing could modify its code, and data couldn't be executed or, selectively, couldn't be modified. A program could be totally sandboxed, so it couldn't do anything but crash. The only real hazard was DMA, which could do anything, so the OS and drivers had to handle that carefully.
Secure systems are possible, but hardly anybody is interested.
The language is part of the wham-bam programming culture that we now have. Which is why you can now execute a TIFF file.
-- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators
That is design by debug. It will never find all of the bugs, or in a complex system, even most of them.
I'd be slower, and do more classic math, and breadboard more. I used to design very complex systems without Spice, without any electronic calculation assistance. Many people "design" by fiddling with Spice, and you can see many examples posted here. It's not a reliable way to design electronics.
The reliable way to do engineering of any sort is to understand what you're doing, and check it very carefully before you build it. That's usually the fastest way, too.
-- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators
Multicore avoids a lot of nasty real-time bugs, though--it's easy to dedicate a core to each hard real-time task and communicate via FIFOs.
Fast uniprocessors make it harder to get real-time right in general.
Cheers
Phil Hobbs
-- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
If your problem maps well onto linear algebra concepts, Matlab is actually pretty fast, I'm told. Doing things one at a time makes it run more like GW Basic.
My usual way of writing workstation code is to do the grinding with a C++ program written in C-with-classes-and-templates style, and do the rest with a REXX script. My clusterized EM simulator (
Real programmers run their own code or their friends' code. My favourite text editor is X2 by Blair Thompson, which is sort of like EMACS crossed with VM XEDIT crossed with IBM Research E3. It's also REXX-scriptable, and has a nifty feature where it remembers keystrokes and produces an editor macro to do what you just did. You can then edit the macro as you like and save it for later. That has saved me untold aggravation in file format conversions alone.
I like my particular subset of C++ for what I do, because the object-oriented model maps extremely well onto simulation and instrument control jobs.
But yeah, lots of plain pointers, new/delete, hand coded linked lists, etc. It's a luxury when all you have to worry about is a bug causing the program to terminate, rather than killing people or destroying property.
Embedded code is a different case--I don't think I've ever used malloc/free in the guts of an instrument. Certainly not often.
Cheers
Phil Hobbs
-- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
One of the reasons that software is buggy is that programming is hard. Crufting something together is a lot less hard, which is why people do that.
Pascal lost to C because it's a toy, and because of all the mutually incompatible variants. Personally I find that all those BEGIN/END blocks are very hard to read because of the visual noise. (Verilog is the same way.) And besides, you can use untyped pointers in Pascal--see e.g.
ADA is still around--gcc comes with a free ADA front end (GNAT), which uses the same back-end as the C++ compiler.
I'm about the furthest imaginable thing from an adrenaline junkie, but I really like computers that do as they're told.
Cheers
Phil Hobbs
-- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
We're working on a microZED/ZYNQ project now. That is two 800 MHz ARM hard cores inside a Xilinx FPGA. One core will run Linux and do comm/management, and the other will work with the FPGA to do realtime signal processing. The realtime core will run as close to bare-metal as possible.
More cores would be interesting. Like 256 maybe. Then you could assign a core to every process and never context switch. Add some decent hardware protections and you have a bulletproof OS.
-- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators
The typical defect rate in production code is about 0.2%. The problem is that the side effects of that error rate can be enormous.
US cars are designed to kill and seriously injure short people and women drivers. The airbag charge on US vehicles is excessive to stop the fatso that can't be bothered to use a seatbelt.
That is because it is perceived to cost too much to do it that way for anything that doesn't have life threatening consequences.
More like the early middle ages of cathedral building. If it is still standing in 5 years time then we know it was a good design.
Not really correct. C won largely because it was easier to compile and already had an entire OS written in it. The Pascal like languages fragmented pretty badly with no two the same - Modula2 nearly made it but the ISO standard took too long and was in effect the kiss of death.
There were predecessors like BCPL which had some interesting features. Algol was very nice, NAG used it internally but slow for many real world problems and rather difficult to implement a full compiler.
Sadly that is true. You can do stuff using formal methods and get a clearly defined result but attempts at formal proofs of correctness are incredibly difficult as the people who worked on VIPER will testify.
Cyrix also found various lsb bugs in the Intel 8087 when they generated a full formal specification and boundary test set for their own FPU.
I think the mutually incompatible dialects was more bother. Modula2 overcame most of Pascals limitations but was too late by then. It had a toolset on PCs that was worthy of mainframes at the time although the code generator was a bit lacklustre and a 4 pass compiler. Curiously the company that owned the IP, Logitech went on to popularise the mouse!
They always do what they are told (except when there is a chip defect). The problem with C is sometimes the program instructions given are syntactically valid but nothing remotely like what the author intended.
-- Regards, Martin Brown
Electronic design is hard, which is why we check it so carefully before we etch expensive boards and assemble boxes. People wham-bam code precisely because it's easy to compile and run... maybe 50 times per day.
FPGA compile/test cycles take hours to days, which is why people who code in VHDL are more careful than people who compile c. People who design bridges and airplanes are even less likely to hack it and see what happens.
-- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators
But it's not. Designing solid code, commenting it thoroughly, and checking it carefully before it's even compiled, is faster than hack/test/repeat. The bigger the project the stronger the effect.
Most of the programmers that I talk to don't actually understand what a synchronous state machine is!
-- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators
C'mon, Martin, don't be such a chicken. Tell us how you really feel about Americans, and why.
I'm including compilers, not just the hardware. I like to step through code in the debugger, because after code reading, it's the fastest way to find bugs, and you can easily test all the branches, error handling code, and so on.
That's one place where Linux really bites--the best mainstream debugger is ddd, which lacks the features and polish of, say, Microsoft CodeView for DOS, circa 1990.
There's another one-man effort called zerobugs, by the estimable Cristian Vlasceanu, which is very much better but depends on his spare-time support. Highly recommended.
Cheers
Phil Hobbs
-- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
And also that programs today tend to be rather large (the important distinction between features and benefits has been lost along the way).
[snip]I agree with you, but the fact remains that in commercial software bonuses are mainly related to product shipped and paid for. Management doesn't care if it is bug ridden so long as it doesn't attract too much bad press. Vista was slightly unlucky in that respect it was nowhere near as bad as it was portrayed, but it followed XP which was better.
One problem is that anyone who is any good can hack their way through most university sized programming exercises with no process at all. It is only on real world large scale projects that things bite!
There is also the problem that the best tools for doing static analysis are only available in the most insanely expensive packages. CPU cycles are now cheap and getting cheaper whereas talented people cycles are rare and expensive. It makes sense to have the machine do as much of the grunt work to detect human errors and ambiguities at compile time as is reasonably practical (or even better in the specification).
I did at one time think that Nassi-Shneidermann diagrams might serve as a proxy for software circuit diagrams to communicate with customers what their specification looked like. It didn't help that they viewed them somewhat unkindly as "nasty spiderman" diagrams.
Most customers didn't actually want to understand or even think clearly about the ill posed problem they want solved. I have seen plenty of horror stories including modules maliciously edited so that all variable names were legal permutations of I,l,O,0,S,5,B,8.
I have a hunch that the coherence length of modern programs is now limited by the amount of code that can be seen on a screen at once (and at one point that was 25 lines)! In the old days a compile run cycle was long enough that you would look very carefully at the output and printed sourcecode listings before resubmitting the job to run again.
You mix with the wrong crowd then.
-- Regards, Martin Brown
Pascal lost because it was a language designed to teach (specifically,
*structured* programming) and NOT designed to be implemented. It was implemented poorly.I find just the opposite. I find braces get lost in the noise. Can't stand 'em so have never used C. I have no issues with VHDL. Verilog, Blech!
It's not the place for improvisation. ;-)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.