January/February 2019 issue of acmqueue The January/February 2019 issue of acmqueue is out now

Subscribers and ACM Professional members login here

Programming Languages

  Download PDF version of this article PDF

Error 526 Ray ID: 4cd0f6361ec521f2 • 2019-04-25 14:21:09 UTC

Invalid SSL certificate








What happened?

The origin web server does not have a valid SSL certificate.

What can I do?

If you're a visitor of this website:

Please try again in a few minutes.

If you're the owner of this website:

The SSL certificate presented by the server did not pass validation. This could indicate an expired SSL certificate or a certificate that does not include the requested domain name. Please contact your hosting provider to ensure that an up-to-date and valid SSL certificate issued by a Certificate Authority is configured for this domain name on the origin server. Additional troubleshooting information here.


Originally published in Queue vol. 16, no. 2
see this item in the ACM Digital Library



Ulan Degenbaev, Michael Lippautz, Hannes Payer - Garbage Collection as a Joint Venture
A collaborative approach to reclaiming memory in heterogeneous software systems

Tobias Lauinger, Abdelberi Chaabane, Christo Wilson - Thou Shalt Not Depend on Me
A look at JavaScript libraries in the wild

Robert C. Seacord - Uninitialized Reads
Understanding the proposed revisions to the C language

Carlos Baquero, Nuno Preguiça - Why Logical Clocks are Easy
Sometimes all you need is the right language.


(newest first)

Displaying 10 most recent comments. Read the full list here

CodeLurker | Sat, 22 Dec 2018 17:30:15 UTC

OK. "C" is not a low-level language. Why is it that, in the now defunct Game of Benchmarks site, C++ programs were usually the fastest; with FORTRAN beating C++ in only occasional number-crunching tasks? I'll admit that a language with cheaper parallelism, cache management primitives, and parallelism cues would in principle be faster than C++. I'd bet you real money, that in the real world, such a language would share with C++: 1) that it is not using garbage collection in most benchmarks (unless they are run in an way not to incur its performance disadvantages), and 2) it is not interpretive. Take that, you academician know-it-alls!

Juneyoung Lee | Sat, 27 Oct 2018 17:01:43 UTC

For the unspecified value thing - you may want to add PLDI'17 to your reference? :) (https://dl.acm.org/citation.cfm?id=3062343 )

For the provenance thing - this OOPSLA'18 exactly is about the issue! (https://sf.snu.ac.kr/llvmtwin/ )

Roberto Maurizzi | Tue, 16 Oct 2018 02:33:17 UTC

C doesn't guarantee anything about memory protection: the CPU (or better its MMU) does, as anyone that wrote C programs on MMU-less processors can tell you. On those systems (typically single-task but not always, see Commodore Amiga) a program had full access (read and write) to the full address space of the processor and a 'lost pointer' could easily fill all the memory with garbage and crash the OS. What Intel and friends did is even worse actually: for the sake of compatibility they hid the real internal structure of the processor from the 'external' assembly language and architecture, then they didn't emulate this memory protection architecture probably for the sake of speeding up things. They allow things that would be illegal for the processor they're emulating because they wanted speed AND backward compatibility, because Microsoft back in the day was refusing to even think about porting Windows to different architectures.

Tom Sobota | Thu, 12 Jul 2018 13:51:16 UTC

Years ago I programmed a lot on the PDP-11, be it in assembler, Fortran or C. So I find that the author is right when he says that C is a low-level language on those machines. It is, or better, it was. When I started to program for the X86 architecture, back in the eighties, I also couldn't but notice that the code generated by C was not so low-level anymore, since the PDP-11 instructions like pre- or post- increment weren't there, and the address modes were different.

I have nothing against C/C++, I still use them frequently. But I wonder if some new language than could give us that sensation of control over the program execution wouldn't be welcome. Ditto for a processor architecture with execution parallelism controllable from the language. RISC-V or something?

Blue | Fri, 06 Jul 2018 11:37:57 UTC

The author simply assumes the x86 platform then ? A good part of C code in existence isn't written for desktop and server applications anyways, but for sequentially working MCU's which are a lot closer to the original 8086 chip. Also; "For example, in C, processing a large amount of data means writing a loop that processes each element sequentially." isn't always true, depending on the use case (For example Binary search or jump search don't need to iterate through each element of ordered data).

Anon | Thu, 24 May 2018 03:22:29 UTC

I can only assume the author is a big fan of Intels EPIC efforts?

mlwmohawk | Mon, 14 May 2018 21:36:07 UTC

This is an excellent troll and strawman argument. The "C" programming language enforces nothing in the way of memory model or threads or processor layout. The language itself can be applied to almost any hypothetical processor system. All that is required is some sort of sane operational characteristic that can be programmed. I will grant that most developers and generic libraries assume thing like malloc, stacks, cache, serial execution but not C. C takes an expression and translate it to a set of instructions, nothing less and nothing more.

What would be really interesting is if you could describe a programming model that would be better than C *and* not be implemented in C.

Eric S. Raymond | Thu, 10 May 2018 14:22:21 UTC

I have blogged a detailed response at


In brief, I think Chisnall's critique is thought-provoking but his prescription mistaken; there are simply too many key algorithms that are what I call SICK ("Serial, Intrinsically; Cope, Kiddo") for his ideas about pocessor design to play well with real workloads.

John Payson | Wed, 09 May 2018 20:58:19 UTC

Perhaps the simplest rebuttal to the author's primary point is to quote from the introdution to the published rationale for C99:

"C code can be non-portable. Although it strove to give programmers the opportunity to write truly portable programs, the C89 Committee did not want to force programmers into writing portably, to preclude the use of C as a high-level assembler: the ability to write machine-specific code is one of the strengths of C. It is this principle which largely motivates drawing the distinction between strictly conforming program and conforming program."

To be sure, the C Standard does not require that implementations be suitable for low-level program. On the other hand, it does not require that they be suitable for *any* particular purpose. The C89 Rationale notes, in, "While a deficient implementation could probably contrive a program that meets this requirement, yet still succeed in being useless, the Committee felt that such ingenuity would probably require more work than making something useful."

While the C Standard itself makes no reference to "quality", except with regard to the "randomness" produced by rand() and random(), the rationale uses the phrase "quality of implementation" a fair number of times. From Seciton 3 of the C99 Rationale: "The goal of adopting this categorization is to allow a certain variety among implementations which permits quality of implementation to be an active force in the marketplace as well as to allow certain popular extensions, without removing the cachet of conformance to the Standard."

For some reason, it has become fashionable to view the "ingenuity" alluded to in of the C89 Rationale as a good thing, but the text makes it clear it isn't. The only reason the authors didn't explicitly discourage it is that they thought the effort required would be adequate deterrent. Alas, they were mistaken.

Anon | Sun, 06 May 2018 10:33:54 UTC

Holy mother of god. Lets put all the blame of C of all things and just pardon incompetence on all sides.

Displaying 10 most recent comments. Read the full list here
Leave this field empty

Post a Comment:

© 2018 ACM, Inc. All Rights Reserved.