What "undefined" means here for most compilers is that it will make the best attempt it can under the C rules but the results may vary on different machines. Ie, it will use the underlying machine code for adding two registers, which may wrap around or possibly saturate instead, and the machine may not even be using tw's complement.
No, that would be implementation defined behavior.
Any flock of flying robots, autonomous or not, over my head or my property will encounter bags of nails, wires and other terrible obstacles designed to swat them.
Remember kids, what goes up must come down... in unrelated news, people who oppose drones can be recognized by the nails, wires, and other 'terrible obstacles' that embedded in their face.
They should take this site and give it a new name. Or get Malda to let them use "Chips & Dips".
Leave everything else intact, archives, user ID database, everything except the name.
Then use the Beta code and start a new site and give it the slashdot.org name, and they can have what they want without the embarrassment of having the current userbase escape from the basement or the attic and offend the sensibilities of the yuppies or hipsters or metrosexuals or whoever it is that they really want for an "audience"."
Oh my god that's so unreasonable, especially compared to the rest of Europe!
Not this compiler-inserted backdoor crap again... Look, an assembler could insert a backdoor as well. And any of the developers could insert a backdoor. Did you read the entire source code? Even if you did, do you think you could find a cleverly hidden backdoor?
Besides, all you need to do to get rid of the hidden compiler backdoor (assuming there is one) is write your own compiler, use it to compile the suspected compiler, then use the generated compiler to compile itself, and presto, the backdoor is gone. Writing an interpreter instead of a compiler is also an option. Since you only need to do this whole process once, your compiler doesn't need to do any smart optimization and it's acceptable for the whole process to take some time (a week? a month? who cares).
Most kids are going to have access to a normal computer anyway, which would include a monitor, keyboard, and mouse. They can use ssh access or some kind of remote desktop to control their RasPi. No extra support hardware required, apart from a power supply, a sd card (they're dirt cheap) and a UTP cable to connect it to a switch/router. Your 'well past $200' estimate is completely ridiculous.
Except that you could have used the exact same technique in java, recycling the same object.
> So if you code in Java there is no way to compile parts of it to get a needed speed boost.
Modern VMs already compile when you need a speed boost.
> The last time I coded a low latency system (in C++) we disabled timer interrupts to the Linux OS to prevent the process getting swapped out
Did that really make a meaningful difference? I imagine the interrupt handlers would have very little code and would never ever result in pages getting swapped out.
Yeah it's all rather disappointing really, but at least we know that gains in processor speed won't some day break our crypto (assuming it has no other weaknesses).
For some interesting numbers check out http://www.schneier.com/blog/archives/2009/09/the_doghouse_cr.html
What's your point? By the same logic you could build a tank that will ignore the puny bullets of smart guns and dumb guns alike. It won't be cheap, but you can do it.
> I was once a programer when i was in High School. Since then I've noticed and been told friend who are programers/coders that programming languages now are sloppy when it comes to memory.
Garbage-collection performs better when there is more memory available, and many modern languages use garbage-collection. Then we have JIT, which requires a bytecode-compiler and a bytecode-interpreter to be in memory (unless you compile the whole program on startup). Basically we're trading memory for things like safety, platform-independence, and performance (e.g. when caching data). Which usually makes a lot of sense and works very well for powerful systems with a lot of RAM, but not so much in other situations.
> I've heard also that old languages like Basic, C and other were better at keeping memory processing needs to a minimum.
What do you mean by 'memory processing needs'?
> Would a modern language using the smaller memory/processing requirement help things with ever need come with more efficient chip?
Sorry, I can't parse 'help things with ever need come with more efficient chip'.
If you're asking if a theoretical language that uses less memory and (magically) less processing power would remove the need for more efficient chips the answer is 'no'. The advantages of being more efficient are cumulative so until we arrive at the point where our phones have 100-year battery times having both would always be better than having one or none.