Programming in C must be banned

http://arstechnica.com/security/2016/08/code-dumped-online-came-from-omnipotent-nsa-tied-hacking-group/
https://xorcatt.wordpress.com/2016/08/16/equationgroup-tool-leak-extrabacon-demo/
Once again, a buffer overflow has lead to new vulnerabilities in C land. This time all pre-2013 Cisco routers are affected.

It does indeed feel there is a gaping hole in our software stack as these buffer overflows are only increasing in rapidity. It is time we take a serious look at the epidemic of exploits in C land, and begin to implement real solutions; they are out there.

It’s hard to deny that easy access to stack, especially unpriveleged access, plays a serious role in creating computer crime. How many buffer overflows happen in languages with access checks on stacks? How many buffer overflows are discovered in the Ada each year? None. How many in Haskell? None. How many in Java? None. The list could go on. And yet, mass exploitation in the C-land continue to increase. There is certainly a correlation. But there are other important causes at play as well: the language is an ill-designed clusterfuck of hacks upon hacks.

Of course, mass buffer overflows are only one indication of the security nightmare that plagues the language — the whole language is built on unsafe and insecure code. In the C-land, memory rules are much more lax than that of other popular languages, on par with the assembly and lacking even basic safety features: unless explictly requested by the programmer.

Nearly 70% pre-2013 routers are Cisco and are vulnerable to being hacked during the %CurrentYear%.
https://gigaom.com/2013/02/27/chart-cisco-owns-the-switching-and-routing-world/

These are a only a few of the indicators of what may feed into the hopelessness and despair that causes so much distrust in C and its derivatives. The bugs cost real money and real work-hours to be wasted on correcting and debugging the garbage that was compiled by compilers which don't value anything but speed and memory use..

>>39
(lik(e t(h(is))))

>>41
is it really a C replacement? when I started learning lithp, I asked here for help with basic networking tasks and I was told to just use FFI and write wrappers over C libs. I like the language but how can it replace C if it needs C libraries to do practical stuff.

>>43
That has nothing to do with the language, it has 100% to do with how much time people in smaller communities spend reimplementing wheels from other languages.

Plus, you must have started learning lithp 20 years ago, because networking is well supported in every major Common Lisp implementation.

_{(this space left behaving undefinedly)}

>>43
then how do you find MX records for a given domain name? I've asked on /prog/ some time ago and the best answers I got were about FFI (there was also some bullshit about how network-related stuff is for codemonkeys and a true lithper just doesn't do that)

>>45
I'd place the "basic" in "basic networking task" more along the lines of "common case", instead of lower level. That's something that isn't on many people's radar, hence isn't on many people's radar for "let's replicate functionality for X in my language".

And that has nothing to do with Lisp, really. How many non-topN languages expose DNS calls? This is explicitly a "call the OS for this particular thing" functionality, not something built on other commonly interfaced tools (memory management, threads, function calls, socket & file I/O).

>>43
Why are you talking to yourself?

>>39

What does your C replacement look like?

Free Pascal

http://wiki.freepascal.org/Operating_Systems_written_in_FPC

>>32

"C is close to the hardware."

Nice misquoting me. I never even said anything remotely similar.

So you agree with me?
I guess we're done here.

>>50
Well, it could certainly be closer to hardware. But you can also think about it this way: it is closer (or rather: can be closer to HW but doesn't have to be -- isn't there this 'safe' C that's like 50x slower than 'normal' C?!? Anyway...) to HW than other langs, including a lot of these that want to be C replacements. So, looking from ASM, it's somewhat far from HW. Looking from JS, it's close to HW.
I'm obviously a C nerd but I also miss overflow checks and the likes from time to time. The point is that C isn't perfect but instead of actually trying to fix it, hipsters try to fix it by replacing it with {lang-of-the-day}.

>>51
The only things ``close to hardware'' about C are the ability to read and write memory at an arbitrary address (like Ada, PL/I, GHC Haskell, and several dialects of Pascal and BASIC) and having hardware-efficient (on binary untagged architectures with flat address spaces) primitive types (in that sense, C is as ``close to hardware'' as JavaScript and Haskell).

Reading and writing memory at an arbitrary address is implementation-defined behavior in C.

>>51
Well ideally this would be the job of the Standard, but given the track record things are looking very depressing.
- No way to zero a buffer until C11 (http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html)
- Still no threading model (Maybe this decade?)
- Still no module system (Manually prefixing all your variables? Even the Java people are laughing at you.)

>>52
I don't know jack about Haskell but I'm pretty sure you can't convert an expression in JS to native instructions as straightforward as in C, especially when you want to have it optimized. Also, try to run such JS expressions on an 8-Bit Atmel. I'll be waiting here (literally).

Reading and writing memory at an arbitrary address is implementation-defined behavior in C.

It's usually pointless and dangerous in any language and in the end up to the OS (even CPU nowadays: NX Bit etc.) if it's legally possible at all.

>>53

- No way to zero a buffer until C11

You could use a third party lib (like Microsoft's (Secure)ZeroMemory) which doesn't get optimized away.

- Still no module system

static

- No way to zero a buffer until C11 (http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html)

Unrelated link.

- Still no threading model (Maybe this decade?)

C11

>>54

but I'm pretty sure you can't convert an expression in JS to native instructions as straightforward as in C, especially when you want to have it optimized.

What in the fuck do you think the transparent optimizing JIT compiler is, you niggercunt? You don't have to do a god damned thing to have JS convert to optimized native instructions. Can't get more "straightforward" than that.

and I even hate JS, but your post is just bullshit

>>54

I don't know jack about Haskell but I'm pretty sure you can't convert an expression in JS to native instructions as straightforward as in C, especially when you want to have it optimized. Also, try to run such JS expressions on an 8-Bit Atmel. I'll be waiting here (literally).

That's really up to the implementation. The reason JS is considered low performance is because it's canonical implementation is a interpreter, which are generally slow. But there's no reason why you couldn't have a compiler that takes Javascript code, and generates efficient machine code from it. After all, both JS and C have a lot of constructs that are semantically similar - a for loop in JS does the same thing as a for loop in C, so there's no reason why it should be such an issue. Javascript on embedded systems basically doesn't exist, but that's mainly because C is already adequate in that role - there's no need to create a highly optimizing Javascript compiler for such environments, since JS doesn't provide enough of an advantage over C. It could be done, there's just no incentive for it.

It would be a bit more difficult to compile and optimise JS due to stuff like dynamic typing or eval. However it would not be impossible or anything like that.

>>56
>>57
Consider for example some of the examples in this article: http://www.html5rocks.com/en/tutorials/speed/v8/
JS requires that numbers be 64 bit floats (by standard). In order to improve performance on real life hardware, the V8 engine (arguably one of the most sophisticated JS engines) uses tagging and dynamic dispatch mechanisms at runtime to speed up the execution. C doesn't need this because the programmer can say unsigned short when s/he knows that s/he doesn't need more at this point. Type is resolved at compile time instead of execution time and the program runs faster because the programmer was able to describe more precisely what s/he wants from the machine. Unless you compare C vs JS on a machine that only offers 64-bit-float-registers (because thats what JS runs on, although this machine probably doesn't exist in reality), C will most likely be faster because it maps better to real hardware, making it 'closer to HW'.

>>59
You do realize that you linked to a 4 year old page on a totally shit site, right? You don't even know what the fuck the compiler is doing, and what situations it actually does compile down to integer register machine code ops, right? Fuck off, you ignorant cunt.

>>59

C doesn't need this because the programmer can say unsigned short when s/he knows that s/he doesn't need more at this point.

Being able to use data types of different sizes is typical for statically typed languages. There's nothing special about C here. For example, there's Word16 in Haskell.

C will most likely be faster because it maps better to real hardware, making it 'closer to HW'.

How does C map better to the hardware? It doesn't let me choose the layout of my data structures. That kind of thing is important when you want to interface with memory-mapped hardware devices. Most things in C that appear to be close to the hardware are undefined behavior.

>>57
no
javascript implementations would be nearly as fast as C if this were true, considering the massive amount of work people have put into it

>>62
C is only fast because you take the hit in compile time (often 30 seconds for even small programs), that's the cost of optimization. If Javascript was distributed as binary files, you could get away with compiling it once, but since it's distributed as source code, having to wait half a minute for it to compile before you can run it is unacceptable. So instead, implementations are interpreters or non-optimizing JIT compilers, which produce code that executes slower, but overall it's faster than C source once you factor in the compilation/optimization overhead.

JavaShit

When [] == "", you must have a fuckhuge pile of machinery constantly running in all cases. This is why JavaShit is slow and no one in computer science takes it seriously.

>>63

implementations are interpreters or non-optimizing JIT compilers

that's completely false though. all major js implements use combinations of interpreters and/or compilers but all of them include an optimizing JIT compiler.

and nobody writes JS interpreters anymore, since it's easy to grab the existing mature JIT engines. Unless you're on some fuckoff weird platform it doesn't support.

When [] == "", you must have a fuckhuge pile of machinery constantly running in all cases

The mystery disappears when you see its comparing string vs non-string, the first thing it converts [] to a string
([]).toString()=="", both now simplify to ""==""

>>63
Again: JS may require multiple dispatch even for something as simple as an addition, while C permits the compiler to just emit an addl.
JS describes a specific abstract machine; C describes a very unspecific abstract machine that 'just so happens' to map well to a lot of real hardware.

>>68
add.
But why the fuck are we discussing JS anyway? Most people can see from far that it's unsuitable for most of the jobs C was originally designed for.

And if Haskell can be so low-level as you (or others) describe it then write me some low-level application and prove it worthy as a C replacement.
Hint (concerning both JS and Haskell): if I need to install a 400MB runtime in order to run your application you've already lost.

>>65
A JIT compiler can't optimize to the degree a regular one does, since the speed of compilation is important.

>>68
Bullshit. The JS compiler can emit an unchecked addl as well, if it's adding integers. Fucking ignorant retards.

>>70
Speed of optimized compilation is irrelevant if done threaded. Fast path detection and heuristic collection isn't fast anyway.

>>72
Threading can only do so much when for execution speed. Each processor core can only run one thread at a time, beyond that limit, additional gains in speed only occur if one of the active thread must wait for some reason, allowing another thread to get some work done in the meantime.

>>73
Did you even read what I said? It doesn't matter how slow optimization is, because it can be threaded out.

>>74
Threading isn't magic. A CPU can only work so fast.

>>75
Kill yourself, you backwards fuckhead. But I think your flying off into random tangents will send you into orbit anyway. Enjoy asphyxiation in a vacuum, idiot.

>>76
Check em!!!!!!!!!!!!!!!!!!!!!!!!!!!

_{(this space left intentionally background threaded)}

>>76,78
epic meme dude !

Computers have been fast enough for years, it's time we start demanding security.

I used to have a computer that took 1m30s to boot, now it only takes 10s, but it's still buggy and insecure. I'd rather have a computer that once again takes 1m to boot, but that I know cannot be subverted by state actors.

We need languages in which strict security is a feature. C is way too liberal.

oh and >>17, you have gone off the deep end. 'Insecurity is freedom' ?? You have been smoking shit. >>19 is right on the money. Besides, I don't believe you ever really "hacked" anything, poser piece of shit.