On: Why Are There So Many Programming Languages? (2015)

[KMag]

Your assertion was that using (linking/calling) Boehm GC causes the C program to violate ISO C and thus in some sense stop being a GC'd C program. This is then a property of the interface of libgc. If you're relying on an implementation detail of a library that's not visible from outside the library to make an argument about the actual language of any program that calls into it, you're violating the library abstraction.

A C program doesn't stop being a C program because it calls into a BLAS library that happens to be implemented in Fortran or some low-level library implemented in assembly.

Again: what property of the interface of Boehm GC breaks any revision of the ISO C standard?

[kazinator → KMag]

My assertion was exactly this: "Boehm violates ISO C". A C program stops being an ISO C defined program when it calls into a translation unit that invokes ISO C undefined behavior, even if the call takes place through a good interface. If you call a library for loading a JPEG image, through a nice interface, but that library segfaults, your entire program has undefined behavior.

A C program also stops being an ISO C program when it calls a function that is not in the standard C library and that is written in Fortran. However, that Fortran code can be well-defined Fortran, and the call can be taking place through a C-Fortran calling mechanism documented by the compiler suite. So that even though we don't have a definition of behavior entirely coming from ISO C (so that the program is undefined as far as ISO C is concerned), we can piece together a definition of behavior from ISO C and additional sources, like the Fortran standard and the reference manual for the toolchain.

We don't have any such definition of behavior with Boehm GC. The behavior is empirically validated. No compiler document says that it's okay to scan memory looking for pointers, as a documented extension.