←back to thread

Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

(blog.exodusintel.com)
387 points pedro84 | 1 comments | 26 Jul 17 19:51 UTC | HN request time: 0.001s | source
Show context
Animats ◴[26 Jul 17 22:28 UTC] No.14860964[source]▶
C's lack of array size info strikes again:

    memcpy(current_wmm_ie, ie->data, ie->len);
where "ie" points to data obtained from the net.
replies(2): >>14861129 #>>14861284 #
corndoge ◴[26 Jul 17 23:23 UTC] No.14861284[source]▶
Programmer's mistake for not validating data, not the fault of C language mechanics. Yes it would be easier if <hll features>, still gotta be careful. I've made plenty of these mistakes but never blamed the language.
replies(5): >>14861427 #>>14861944 #>>14861961 #>>14866096 #>>14871609 #
loonattic ◴[28 Jul 17 03:02 UTC] No.14871609[source]▶
It's 2017. It's about time we had a better, well designed language (ie Rust, but I'm not sure if it's well designed enough, depends on what you want it for, too). There have been many advances in language research since the 70's that could be very useful for the kind of work C is used for. Saying we should stick to C because it's well established is like saying we should stick to assembly if it was well established. Except it's not portable, but close enough.
replies(1): >>14877927 #
1. throwaway47861 ◴[28 Jul 17 21:57 UTC] No.14877927[source]▶
I've noticed that C and C++ have pretty fanatical and very narrow-minded fanbase. And I am talking about people of ages 50+ as well -- I was acquainted with several of them (in the real physical world) as well.

So IMO it's absolutely pointless trying to argue with them in the first place. They are set in their ways and while a good chunk of them are pretty strict and excellent in what they do, they are not open to any changes.

I would be the first to agree that Go and Rust aren't ready to start replacing drivers but IMO people should start trying! (Or invest in LLVM some more?)

C/C++'s faults aren't ever going away. They're too convenient in their target area. I am against the overly-used "disruption" term -- I happen to believe the USA tech blogosphere bastardized the term long ago -- but IMO the systems programming area is very, VERY overdue for disruption.

It's time.