I guess I should have used:
    if (a_simple_boolean_expression_variable.that_is_automatic_scope.and_therefore_on_the_stack);
        yet_another_simple_integer_variable.that_is_automatic.and_likewise_on_the_stack = 5; // set value to five

Or, if you [yikes!] prefer camel hump notation:
    if (aSimpleBooleanExpressionVariable.thatIsAutomaticScope.andThereforeOnTheStack);
        yetAnotherSimpleIntegerVariable.thatIsAutomatic.andLikewiseOnTheStack = 5; // set Value To Five

I can be flexible when needed ...

Engineers' Guide to the Supreme Court: They're not smart ...

I prefer the warnings and use -Werror for my code.

However, adding -Werror to a library/whatever that the you don't [intend to] control/maintain that has lots of "benign" warnings just causes the headaches that you suggest. But, it leaves the code fragile/open to a bug that the compiler could help with.

But, it's the upstream developer's responsibility to fix the warnings which usually involve less hardship than not fixing them. You never know when it's trivial vs. uncovering a genuine bug. If all the trivial warnings are fixed, it allows more eyes on the problem. If I take over responsibility for a code base, the first thing I will do is fix the warnings [usually takes just a few hours]. By doing so, I've found genuine bugs. Otherwise, these get lost in the noise of the false positive warnings.

Case in point. I had some code that wasn't working. Built clean with gcc using -Wall. Couldn't see it visually despite several goings over. Finally recompiled with clang [thinking it might be an optimizer bug of some sort]. clang has some warnings that are default on with -Wall that gcc doesn't turn on. The code that was wrong, from several thousand lines, and trivial to see by inspection if you're zeroed in:

if (foo);
    bar = 5;

clang flagged this as an "empty if" clause. I've since added the explicit -W option for gcc builds.

Some workloads perform much better on an FPGA, notably, realtime encoding/compression of HD H.264 video. I know because I've worked on such a broadcast quality encoder [currently being used by some major distribution outlets]. While you're right that it's harder to program an FPGA [in particular, validate the design], the performance gains can be huge. In particular, calculating motion vectors gets a win.

Note that H.264 DCT's are integer ones. And, with Intel's hybrid/onchip implementation, the FPGA logic could have access to the CPU's SIMD FP hardware. With Intel's hafnium and trigate technologies, adding the FPGA won't consume that much additional power.

Also note the benefits for search in an article just published today: http://arstechnica.com/informa...

And the developer that created this bug in 1998 is the same one who created heartbleed. Some people get a lifetime ban for hacking. Do we need a lifetime ban for coding?

In another comment, I posted a link to the talk that the libreSSL people gave on what they're doing. It's not really true that what they come up with won't run on other platforms. They're just removing a ton of "#if defined(OPENVMS) && (! defined(WIN32))" in favor of assuming a POSIX compliant libc. Even WinX now has that.

They're taking the "shim" approach. For example, they have two BSD-only functions: explicit_bzero [will _not_ be optimized away by the compiler--just calls bzero] and arrayalloc [does what calloc does but does _not_ zero the memory].

The BSD calloc/arrayalloc do a precheck for overflow of nmemb * size.

These are easy [trivial] to implement for non BSD systems:
void
explicit_bzero(void *ptr,size_t len)
{
    memset(ptr,0,len);
}
void *
arrayalloc(size_t nmemb,size_t size)
{
    size_t totsize;
    void *ptr;

    totsize = nmemb * size;
    if (/* totsize overflowed*/) // blow up ...

    ptr = malloc(totsize);

    return ptr;
}

The OpenBSD folks forked OpenSSL into LibreSSL. In addition to checking security, they are doing general code cleanup, removing unnecessary/dead code. They did a talk recently about what they've accomplished: https://www.youtube.com/watch?...

IMO [as a programmer of 40+ years (30+ with C)], the programming style of the code is horrible. One of the functions that produced heartbleed is called dtls1_process_heartbeat. For starters, it has one of the worst indenting schemes I've seen and seems to violate most style/best practice guides I've read. It isn't surprising that a bug [security or not] would creep in.

Here's the original commit for the code:
http://git.openssl.org/gitweb/...

Here's the commit for the heartbleed fix:
http://git.openssl.org/gitweb/...

Well, consider that APL was originally based on an [alternate] mathematical notation developed by Kenneth E Iverson.

BTW, I was writing APL programs in 1972 [and I already knew Fortran] ... The real problem with APL, aside from needing an alternate keyboard, was that the equations were so dense that proper commenting was difficult. And, if you did proper commenting, it broke up the equations, defeating the purpose ...

The incentive the FCC should be providing is to adopt the European model for the "last mile" [cable]. If Comcast/Verizon can't keep up, any ISP could come in [into the CO literally] and connect directly to the consumer. Thus, ISP's are incentivized to provide good service or somebody else will [and the incumbents lose the customer].

If you look at NSA's TAO division [or some others], they specialize in looking for such zero days. They have used many zero days that are a lot harder to find/utilize than this one. They have 30,000 people working for them. Even if only 1,000 are looking for zero days full time, this is a lot of manpower to throw at the problem

Odds are pretty high that the NSA had, indeed, found the bug. But, they decided they had a shiny new toy for their arsenal. They didn't see the bigger picture that this vulnerability would become so widespread (e.g. not just servers, PC's, etc. but also routers, DSL modems, home routers, ...) that it would compromise systems we depend upon (e.g. secure banking, confidential medical records systems, to name but a few). Even if a few spies/terrorists got tripped up by this, the collateral damage count for this makes the "do not disclose" decision to be the wrong choice. With friends like the NSA, who needs saboteurs ...

Some of the FOSS is high quality indeed [I've even written some ;-)]. But, it's either Linux/BSD kernel, or where the code is contributed by paid employees of a given company (e.g. the Linux USB 3.0 driver is first rate, because it was written by a woman at Intel who is their point person for USB 3.0). Other FOSS is written by fresh grads who need/want street cred in order to get their first programming job. And some FOSS gets taken over by a small group with a "vision" [cult] that refuses to take suggestions/criticism, like Gnome 3, and gets train wrecked in the process.

YMMV ...

I don't expect all code to be bug free. I'm a programmer with 40+ years experience. I looked at the patch diffs, direct from the upstream repo. The bug was missing a simple bounds check on the length of a payload. Sorry to say, but, the original code, stylistically, was newbie quality. If I had been the reviewer, I would have required that it be cleaned up [not even looking for a vuln]. Doing so might have made the bug easier to see [and may have prevented the bloodshed].

Anybody [like the NSA] that looks for zero-days would/should have found it with a simple code inspection. Compared to a flaw in one of the math algorithms in SSL, this was low hanging fruit indeed.

And ... When the new feature was added, where was the unit test program for it? Consider that on CPAN, the average perl module has some 20-30 acceptance tests that run each time the module gets rebuilt. I add such tests to my code all the time.

Incompetent if they didn't find heartbleed [they are supposed to protect our infrastructure].

And massively irresponsible if they knew and didn't disclose it.

The overall damage is 1,000,000 times whatever the NSA might have gained as a penetration weapon in the arsenal. If they knew and didn't disclose, this is tantamount to doing more damage to U.S. [and world] interests than any cyber-criminal/terrorist/nation-state the NSA might hope to catch.

http://www.computerhistory.org...

You have to accept a license agreement and you will get to download msdos.zip

It's not BS.

The USPTO lowered its standards [at the behest of Congress] to lower its standards to reduce its backlog. If an application is denied, it can be refiled [many times]. The only way to truly clear it is to approve it [and toss it into the court system]:
http://www.techdirt.com/blog/i...

$10,000 times 20 is a trivial amount [on a corporate level] compared to an NRE budget for a legit R&D outfit. There seems to be plenty of [unscrupulous] VC money to back such refilings to get something that can be used to [patent] troll others. The first round funding for even a small startup [post angel round] is minimally $10M. This translates into 1,000 refilings.

(Also, isn't this really a question for superuser.com or similar?)

Possibly ;-)
http://superuser.com/questions...