I recently worked on a project where two weeks of development time was followed by 4 months of testing.
Although 3 and a half months of those 4 was waiting for environments to be built and paperwork to go through
With seeds?
They should safeguard them from heat-seeking drones flown by Monsanto.
Pretty much every Honda in the last 10 years.
How many homeless volunteers took off with the camera and sold it to buy booze?
"none, because someone might find out I've made the code worse, not better"
The more things are isolated from each other, across lots of levels (in a fractal dimension sense, perhaps) the better things are likely to be.
Language has a lot to do with that.
If your project is written in a managed language, allocated memory is always initialised first, there is no pointers arithmetic and array bounds are always checked, so it's impossible to read random data from memory.
If your project is written in C, all code has access to all memory.
Resource leak in Java = DoS, as mentioned already
Resource leak in C = Heartbleed.
Personally, I'd rather my application crash than expose my private keys and other data that was supposed to be encrypted.
bugs, like DRM?
This is actually tangentially related to heartbleed - if the memory had been zeroed when freed, the scope of the exploit would have been greatly reduced, as only currently allocated blocks would have been vulnerable
The blocks holding the certificate private key are always allocated, so always vulnerable.
This is completely incorrect. Until it is freed (or realloc'ed), the address returned by malloc will point to the same data, regardless of whether it is in the L1 cache, RAM, or paged to disk. Were this not the case, each program would need to implement its own MMU.
So virtual memory is completely useless, because paging to disk doesn't free up the physical RAM or other processes?
Perhaps you should have read the article linked in the article you linked. http://www.viva64.com/en/k/004...
There is SecureZeroMemory() function in the depths of Win32 API. Its description is rather concise and reads that this function overwrites a memory region with zeroes and is designed in such way that the compiler never eliminates a call of this function during code optimization.
So don't use memset to zero memory.
There is still the risk that another process reads data from RAM that another process was using, unless the OS zeros out the memory before allocating it.
That's something you can't get around in application code because you don't control the other applications.
If the thermoelectrics are significantly more efficient that than internal combustion engine, removing it completely would save a lot of weight and may result in a more efficient system.
I could buy the house I currently own in less than two years. What's your point again?
... or toxic waste from the oil industry?
This won't stop the car industry.
I can't easily replace the navigation system in my car, because it controls the air-con.
The whole system is integrated in to the dash, the steering wheel controls, the trip computer and air conditioning.
There are aftermarket options on ebay, but the risk it won't work is high - The car is made in Japan with several options for air con (single/dual zone) and is visibly identical to other models made in USA which may or may not be wired the same. Added to the fact the model name of the Japanese car is the same as a completely different USA model and the one that's physically the same as a different name.
Apple didn't choose clang, they developed it. Therefore all the reasons for its existence are the reasons Apple use it.
But the program performs functionally the same.
That's the rule followed when doing compiler optimisations.
memset has nothing to do with Heartbleed by the way, nor does any compiler optimisation.
You also don't guarantee the original data is overwritten. If your application is paged out of RAM before the call to memset, when it gets loaded back in to RAM it can be pointing to a different physical memory location. You're now overwriting.... something completely different.
"Ninety percent of baseball is half mental." -- Yogi Berra
