4 ms·

Citation needed The interface to Boehm GC is that you call GC_INIT(), then you get some pointers from GC_MALLOC() and GC_REALLOC(). Nothing in ISO C requires

by KMag 6y ago

Citation needed The interface to Boehm GC is that you call GC_INIT(), then you get some pointers from GC_MALLOC() and GC_REALLOC(). Nothing in ISO C requires that a function returning a pointer must guarantee that pointer remains valid forever. Which section number of any of the ISO C standards do you think Boehm GC violates? The implementation details of the Boehm GC certainly exploit implementation-defined behavior and there's likely some undefined behavior there, too. However, those are implementation details of the library itself. If Boehm GC were written in assembly, then it could function exactly the same and ISO C would be irrelevant to its implementation.

kazinator 6y ago
> those are implementation details of the library itself. By this reasoning, though, any behavior is defined as long as we box it off into a library. (By "defined" here, I mean "ISO C defined" not "declared to be working, and maintained in that order by a library vendor"). > If Boehm GC were written in assembly Every instance of undefined behavior that doesn't prevent translation results in machine code. We can infer its behavior from the instruction manual, and write assembly source which produces the same code. Therefore, there is no such thing as undefined behavior.
- KMag 6y ago
  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 6y ago
    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.

by KMag 6y ago

kazinator 6y ago

> those are implementation details of the library itself. By this reasoning, though, any behavior is defined as long as we box it off into a library. (By "defined" here, I mean "ISO C defined" not "declared to be working, and maintained in that order by a library vendor"). > If Boehm GC were written in assembly Every instance of undefined behavior that doesn't prevent translation results in machine code. We can infer its behavior from the instruction manual, and write assembly source which produces the same code. Therefore, there is no such thing as undefined behavior.

KMag 6y ago
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 6y ago
  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.