Quotes of the week

Quotes of the week

Posted Jun 2, 2021 13:59 UTC (Wed) by khim (subscriber, #9252)
In reply to: Quotes of the week by patha
Parent article: Quotes of the week

> Well, to turn something that is "unhandled" into "handled", I assume you need some sort of specification how to handle it.

What about the case where you turn something that was “handled” into “unhandled”? Let's consider concrete example. This code:

#include <stdio.h>
#include <stdlib.h>

int main() {
    int *p = (int*)malloc(sizeof(int));
    int *q = (int*)realloc(p, sizeof(int));
    if (p == q) {
        *p = 1;
        *q = 2;
        printf("%d %d\n", *p, *q);
    }
}

Note that C89 quite explicitly allows that code and says the only possible output is “2 2”. This is because realloc there does the following: The realloc function changes the size of the object pointed to by ptr to the size specified by size. It's still the same object, both pointers point to it, so why would they behave differently?

C99 changed that. Now realloc works differently: The realloc function deallocates the old object pointed to by ptr and returns a pointer to a new object that has the size specified by size.

Why would that be important? We compared pointers, thus they should behave identically, right? No. There is a decision of WG14 committee which says literally the following: after much discussion, the UK C Panel came to a number of conclusions as to what it would be desirable for the Standard to mean — and then short explanation of how standard should be changed to make that program illegal.

Note: they haven't said that standard actually means that today. Nope. Provenance insanity is not yet part of any standard. Not C99, not C18 and not even C++20! Yet compiler writers think they are entitled to apply these rules (which are, apparently, area of research because compiler writers still couldn't invent usable set of rules which you can use to write correct programs) to old, C89 programs.

Nice, huh?

> Well, a C compiler basically implements C.

Except today it's not true. C compiler writers implement basically whatever they want to implement and reserve the right to retroactively change rules of language. Without providing options which may bring back old behavior (-fno-builtin-realloc works today, but apparently there are no guarantee that it would work in the future).

> That would be an option, but I assume the smoothest path forward is to continue proposing "C language extensions/options", like -fno-strict-aliasing and -fno-strict-overflow to GCC, for specific instances of undefined ("unhandled") behavior in the C language. If considered useful enough to be the default option for the whole C community, it can then be brought up to the C committee.

I think at this point it's, basically, pointless. When I explicitly asked some clang developers about something like -fno-provenance option the answer was: provenance is something LLVM *violently* believes in, at the level of alloca, malloc, and similar intrinsics scribbling provenance information all over LLVM's internal representions. Even if you could turn it off, I doubt it would fix all of your miscompilations, since this is a fundamental building block of LLVM's IR. Like I said before: although provenance is not defined by either standard, it is a real and valid emergent property that every compiler vendor ever agrees on.

Note that not defined by either standard yet real and valid emergent property part. I think after answer like that… it's, essentially, pointless, to bring anything to a C committee. What's the point if said committee would pick something they like, not something that makes, you know, possible to write anything in that language?

We are more-or-less stuck with GCC extensions for the foreseeable future and I think it's good idea to adopt Linus stance. Essentially: “I couldn't forbid you to use clang but I don't consider “clang miscompiles that code” a valid reasoning for any change in any project”.

This is unfortunate because the only language which tries to address these issues in practically usable way, Rust, is basically, tied to LLVM currently. gccrs looks quite active novadays, though, thus there's hope. But C and C++… they should be declared “unfit for any purpose”, sadly. Certain specific implementations probably can be used, maybe, but there are zero hope of getting sane cross-compiler treatment. That ship have sailed.

---

to post comments

int *p = malloc(sizeof(int));
free(p);
int *q = malloc(sizeof(int));
if (p == q) {
  *p = 1;
  *q = 2;
  printf("%d %d\n", *p, *q);
}

int *p = malloc(sizeof(int));
free(p);
int *q = malloc(sizeof(int));
if (p == q) {
  *p = 1;
  *q = 2;
  printf("%d %d\n", *p, *q);
}

int *p = malloc(sizeof(int));
free(p);
int *q = malloc(sizeof(int));
if (memcmp(&p, &q, sizeof(p)) == 0) {
  *p = 1;
  *q = 2;
  printf("%d %d\n", *p, *q);
}