I know what you mean, and of course you are correct, but the way you described it gave the impression that other work or side-effects were unrolled - and that is not the case.
I agree that it is a good thing to write code that is obviously correct, and code that is maintainable. I am not convinced that using a goto instead of a flag necessarily achieves that, but at least we agree on the aims.
If you have multiple nested loops, the code is complex.
Yes. C++ with RAII is your greatest friend here - it's more of a pain with C (unless you "cheat" and use gcc extensions).
Vectorising division is hard in general, I think, unless it is division by a constant or you are otherwise able to turn it into multiplication by the reciprocal.
Get an iAPX432, it should do most of what you want :-).
Unfortunately, it was a fiasco, partly being too ambitious for the technology of the day.
A lighter method is putting each object on a separate virtual memory page and put inaccessible virtual memory pages around it. The program can freely overwrite within the page, but not harming anything else, since there is nothing else on the same page.
When writing outside the own page into non-accessible page and a page fault will occur and can be trapped. For instance Linux Electric Fence does just that for dynamic memory (malloc) object. As long as the malloc allocations are large (1-4 kB) this does not hurt performance badly, but if the mallocs allocate only a few bytes at times, so most of the 4 KB page is unused, wasting memory.
Us far I understand, it does not do anything for stack allocations, but I see no problem if compiler allocated a new page for each stack frame local variables and ask the OS to insert some non-accessible pages between stack frames.
I wouldn't say impossible. Semantically impossible from within the language, without making great abuses (assuming a definition for "abuse") -- perhaps. The issue is as much validating input, and making use of libraries that aren't as well constructed in either respect...
In any case, with _most_ problems being exactly that type of fault -- using better languages than C would go a long way towards security on a day-to-day basis.
Then again maybe not. The zillions of embedded applications that "must use" C, are ever more important on a day-to-day basis, too. You can't audit a single radio module without easily finding piles of bugs in its code. (A recent example from Hackaday was a BlueTooth module that's easily exploitable over the air.)
A general-purpose computer SHOULD be able to run an APL interpreter, and execute data whenever the 'execute' character calls for it. That's just a language element OF THE LANGUAGE, and no OS or hardware that supports the language ought to sabotage that function.
If 'reliability' were the only virtue of a computer, we'd still be using slide rules (one moving part, no electricity).
How can you /possibly/ conclude that from my posts? For one thing, we haven't even been discussing memory management - that is a different thing from memory protection and restricting access to different memory areas.
You have this completely screwed idea that C "mixes up" memory sections of all sorts, and that programmers and OS's don't use memory protection. You have additional screwed up ideas that this imaginary problem is the root of all security issues.
I have put a good deal of time into trying to explain this to you. But you are stuck in your rut. I am forced to conclude that you are either wilfully ignorant, or you are trolling.
I envision some systems being entirely reliable for all practical purposes, and others being more reliable than they are today. But I do not envision complex systems being fully reliable - that would be as silly as envisioning crash-proof cars, fire-proof buildings, and unsinkable ships.
My business is dependent on making high quality software - software that can be relied upon to do the job that is required in the circumstances required by the customer, to within a level that is appropriate for the balance of costs in the development time and the hardware in use.
But I don't expect to get a general-purpose desktop OS and assorted common software that is error-free. I don't expect anyone to pay the huge costs that would be involved in creating such software.
It is a true story, just a few years ago maybe up to one year ago many collisions between US navy ships and commercial ships happened.
Over here you need a license, exams, for any ship over 10 meters, also for how to use communication, and navigation. I actually have one of those. This 'captain' (was he really the captain, looks like some deckhand at the controls), giving away military secrets on top, has no situational awareness, he should be with his nose on the charts looking at depth, AND know the names of the coastal stations and lighthouses.
No, that is standard procedure, the name of the lighthouse is sufficient, the captain should know where he is, and that lighthouse name is indicated on his charts,
After all those recent collisions and that is really only the top of the iceberg so to speak, big changes were made in the navy command chain. I am sure some captains / commanders were demoted, maybe to deckhand ;-).
The brain config 'we are the strongest and we do not give way' and total cluelesness as to navigation and maritime rules is a sign that also appears in the current leadership of the divided states.
Yes, and the same mistake is made again and again and again:
verbose is a global integer, defined in the main header file.
Runing the code with ./program_name - v 1 enables this and prints exactly what happens to stderr, you can write that to a file, see what is wrong if anything. if(verbose > 2) or if(verbose > 3) for other more frequent things.
But what I mostly do when there is some problem just comment out the line in te hrelevant function: //if(verbose) { fprintf(stderr, "test_for_collision(): arg boat_heading=%.2f boat_speed=%.2f boat_heading_to_ais_object=%.2f distance_to_ais_object=%.2f ais_object_heading=%2.f boat_heading, boat_speed, boat_heading_to_ais_object, distance_to_ais_object, ais_object_heading, ais_object_speed); }
and recompile, run it and only see that section.
For the rest I trust gcc, will add as many printf() as needed also for code development. Very very rare that I find problmes with gcc, one small problem in the last 2 years (not even an error), just code around it. And stay with basic C, makes the code portable, much code has been ported to different architectures, Also writing functions for things like this creates a nice libray (collection) of code that you can always re-use.
And pass values by argument, and check for zero pointers passed:
int add_planes_to_viewport(double top_left_lat, double top_left_lon, double bottom_right_lat, double bottom_right_lon, int *planes) { struct plane *pa; int xpos, ypos; double chart_width, chart_height; double dx, dy; struct plane *pdel; struct plane *pprev; struct plane *pnext; time_t now; double heading; double angle; // warning there is also a global angle time_t elapsed_time; double latitude; double longitude; int number_of_planes_plotted; char temp[64]; double b_lat; double b_lon;
Of course - with enough effort, buffer overflows will be possible.
Basically, you don't get buffer overflows when the language knows the size of the buffer, and checks your accesses against that size. If you are using an array in PHP, Python, Lua, etc., that always happens. If you are using C++, it may or may not happen depending on the way you do the access (things like std::vector have methods that do checking, and methods that do not check). If you are using C, you get the checks if you choose to put in the checks manually.
Such checks are always costly. So at some point down the line, from the highest level user code down towards the lowest level system library, there is going to be code that assumes the accesses are valid and skips the checks.
If you manage to lie to the code along the way, you might then be able to provoke a buffer overflow. A common case is once you get to a level of a C API that expects a pointer to a buffer and a size parameter - give it a pointer to a buffer and then lie about the size.
Agreed. C gives you greater flexibility and often greater efficiency, but you have to write more code to do it. And that gives scope for getting it wrong.
(Of course, you can make all sorts of other mistakes in other programming languages - using a high-level language may virtually eliminate buffer overflows, but it does not eliminate other flaws.)
Only a small proportion of these flaws will be buffer overflows. Most will be logical errors - things like not checking incoming data appropriately, which are mostly independent of programming language.
A few of the problems will be caused by things that you could reasonably argue were unpredictable and need to be fixed with updates, but mostly the bugs are due to poor quality development, which in turn is often the result of trying to keep costs down.
There is nothing inherently wrong or bad about using C for embedded development - but you do have to make sure the development process focuses on quality. Other languages can make the process simpler or more effective, and eliminate some types of error, but the process is the same.
As I have said before - when you think you have a simple solution to security, or reliability, you have merely misunderstood the problem.
In particular, on many systems (including all Windows and Linux systems) stack overflows, writes to code space, executing stack or data spaces /do/ cause fatal traps.
He could simply join the 21st century. We don't program with DOS any more.
That sort of system is used by debug libraries in an OS like Linux - things like gcc/llvm's "address sanitizer", valgrind, and other tools for tracing problems. These go far beyond just stopping the kind of problem John Larkin was talking about. But they come at a cost - all memory accesses are noticeably more expensive as you have more indirection, orders of magnitude more memory page definitions, and more wasted memory. So you use them for testing and debugging.
The big problem here would be crippling performance. Allocating a new page for each local variable on the stack frame would make the code impractically slow even for debugging or testing.
On Jan 2, 2019, snipped-for-privacy@nospam.org wrote (in article ):
How? Even very large antennas (measured in wavelengths) are not nearly directive enough. Do some numbers.
Can you cite some reliable sources?
Cites to reliable sources?
Same over here.
If indeed he was in fact the or even a Captain, and that recording was not a hoax.
The size and composition of a Carrier Task Group is not a secret. And how
Even so, one would think that people would have the judgement to realize
Certainly that recording plays directly to a common preconception. But the question is not if personality disorders exist - they most certainly do - but if this recording is a hoax.
There is no doubt that the US Navy has accidents, especially when they allow themselves to become lax,and the commanders are in fact cashiered for allowing preventable accidents.
But the above URLs are irrelevant to our question, which is if the recording about the Carrier Task Group getting into a tangle with an obstinate lighthouse is a hoax.
I am not authorized to answer some of these questions. As to the EMP case and I think this is common knowledge, remember that any exposed piece of wire, including for lighting, on deck cables, antennas, can easily conduct MV into the inside of a Faraday cage. The rest left to the imagination.
Maybe everything is a hoax and we live in the matrix... But let it be a sign on the wall, warning. Personally I doubt the value of the US navy, these days with underwater nuclear drones that can be manufactured for a few k$, an enemy can disable US ports any time. US navy and army is a tax money sink.
And Rome was taken by the Barbarians, after it lost most if not all of its allies. Today I was reading Mr Xi (president of China) does not rule out an attack on Taiwan. China possibly overtaking US in power and in a way challenging it in the Chinese Sea.
The one ant heap against an other ant heap ..... I wanted to write to him: Many Chinese will die in such a war, what is the point. From a cosmic (if you want) perspective these wars are needed, it is part of evolution, may the best one win.
wrote in news:q0i10n$18ps$ snipped-for-privacy@gioia.aioe.org:
No, you cannot. A magnetic field is not directional. A magnetic pulse is not directional. The HEMP program specs alone should tell you that much.
I was once contracted to make a directional EMP pulsing device. It was to be for the green zone guys in Iraq some 15 years ago. They wanted to ignite explosives in vehicles as they progressed up the lane toward the green zone entry gate.
Simple truth... there are no directional mag pulsers.
So, if one wants to cause EMP based havoc, it needs to be an omnidirectional targeted device design goal and the deployment method would be to place them in pairs on the roadway in question and pulse them in pairs as a suspected vehicle (or all vehicles) approaches and as it passes. Set up several pairs and pulse them all over and over again.
The other way would be to ping all cell phones in an area every so many minutes. That way, even the idiots trying to set up the IEDs would get nailed.
A magnetically shielded case (mu metal, etc.) is not actually shielded, it merely redirects the mag flux, and by that action results in "attenuation" of the mag flux levels able to make it into the case interior. So we refer to it as being shielded.
The fact is that even our planet is unable to stop magnetic flux. That shit traverses entire galaxies!
The problem was that Ada counts lengths in bits, while VAX/VMS counts lengths in bytes. You can guess where this is going. My team was totally flummoxed by the resulting crashes when VMS wrote UDP messages into the undersized buffer. When I looked at memory around the buffer using an assembly-level debugger, the overflow was obvious. The fact that the visually-obvious stomped area was eight times the length of the buffer was the clue.
In practice, Ada was no better than other languages in the number and difficulty of bugs. In fact, it was harder to debug if one strayed away from the Pascal core.
All of the above is arguably true, but no longer matters.
C/C++ has become the default because it is adequate and has by far the most comprehensive support over platforms, tools, compilers, and everything else. This yields a huge increase in team productivity, by a factor. When I started in the 1970s, we were happy with 100 lines of code per month, soup to nuts. Now days, we do double or triple that.
language ecosystems combined. (Well, by existing lines of code, COBOL wins
Now days, if one wants to use other than C/C++, one must do a lot of justifying and proving. And language-war type arguments do not impress management, because experience is that programmer skill is far more important than choice of programming language.
The problem with the current generation computers and computing languages is that reliability wasn't designed in from the start, and it isn't a big part of the culture now either.
Writing reliable code, and especially writing exploit-hardened code, is so hard that few people do it.
Some day we'll have a fresh start, but too many people are enamored of and invested in the current mess that they don't even want to think about anything better. So it will probably happen bottom-up.
--
John Larkin Highland Technology, Inc
lunatic fringe electronics
To me, memory management means loading the page (or segment) attribute registers in a computer, which determine where things can go and what they can do.
Not all, but many.
I would like hostile exploits to be impossible. The concept seems to anger you. You have made no suggestions of how security could be improved.
We design complex algorithms into FPGAs that we are confident are bug-free, and have run them for millions of hours without seeing any bugs.
Non-trivial procedural software will probably always have bugs, but computer systems could be absolutely hard against hostile exploits. But first people would have to want that.
Some university should specialize in designing and teaching software design for reliability. I know a CS dean, and she's not interested in trivial problems like that.
--
John Larkin Highland Technology, Inc
lunatic fringe electronics
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.