5 ms·

The overall program flow in this case is: shell => CRT => main(argc, argv) => exit code => shell (to me, the CRT and C standard lib are not strictly separa

The overall program flow in this case is: shell => CRT => main(argc, argv) => exit code => shell (to me, the CRT and C standard lib are not strictly separate, although that's debatable of course)

vidarh 4y ago
Except none of these steps are dictated by the C standard library (some may be dictated by some libc's) EDIT: To expand on this: You can call the code from stuff other than a shell; I'm assuming you mean "C runtime" by CRT, and some libc's may have issues without them, though usually only access to argc/argv and atexit(), and you can certainly write C without linking with the initialisation code; and while you'll of course usually enter via main() you don't have to. You decide the control flow.
- pjmlp 4y ago
  CRT also does stuff like floating point emulation, loading dynamic libraries on demand instead of at load time (e.g on AIX and Windows), handling threads post C11, or runtime checks in hardened code.
  - vidarh 4y ago
    The point is all of that is optional. You can - and I have - write C to be executed on bare hardware with no initialisation code, and depending on your choice of libc you can still use it (though some functionality may not be available).
    - pjmlp 4y ago
      At which point it is no longer C, rather a programing language that vaguely resembles ISO C.
      - vidarh 4y ago
        Of course it is still C. You've just opted not to use some of the functionality. Nothing stops you from e.g. providing your own startup code which then calls the appropriate initialisation code either. The point being that there's no enforced inversion of control in the sense used by the article, and so calling it a framework in the sense described by the article is meaningless. Even if we postulated the inversion of control was there, the fact you can replace all parts of it still means it does not fit the article definition.
        pjmlp 4y ago
        Not from the point of view of ISO C and the expected semantics of the abstract C machine.
        vidarh 4y ago
        If you were to write a program that relies on those aspects of the abstract C machine and don't provide those aspects, then you might have an argument, in that in that case the observable behaviour would be different, but if you choose not to make use of that functionality, its presence is entirely irrelevant. This is also massively shifting goal posts. You first wrote "At which point it is no longer C". By your argument here, e.g. the Linux kernel is not written predominantly in C. But nobody uses the term that way. If you were to speak specifically about ISO C, maybe, but the person I replied to initially did not limit it to ISO C. As such this is also entirely irrelevant to the original argument.
        pjmlp 4y ago
        Everyone knows Linux is actually written in GCC C, and Google has burned lots of dollars making it work with clang, if it was proper C, that wouldn't never been an issue.
        vidarh 4y ago
        And yet almost everyone would still agree that "GCC C" is also C, so this is entirely irrelevant to what was being discussed.
- camgunz 4y ago
  The kernel loads your program, and schedules its execution. This is basically the same as using an async framework and sending the entry point to your application. If you're willing to extend a little, there are also signal handlers, or setting up callbacks in pthreads. Again this isn't to be reductive, but to say this is a super common method of encapsulating irrelevant stuff. It doesn't seem to be a significant differentiation between "I'm a library" and "I'm a framework".

The overall program flow in this case is: shell => CRT => main(argc, argv) => exit code => shell (to me, the CRT and C standard lib are not strictly separate, although that's debatable of course)

vidarh 4y ago

Except none of these steps are dictated by the C standard library (some may be dictated by some libc's) EDIT: To expand on this: You can call the code from stuff other than a shell; I'm assuming you mean "C runtime" by CRT, and some libc's may have issues without them, though usually only access to argc/argv and atexit(), and you can certainly write C without linking with the initialisation code; and while you'll of course usually enter via main() you don't have to. You decide the control flow.

pjmlp 4y ago
CRT also does stuff like floating point emulation, loading dynamic libraries on demand instead of at load time (e.g on AIX and Windows), handling threads post C11, or runtime checks in hardened code.
- vidarh 4y ago
  The point is all of that is optional. You can - and I have - write C to be executed on bare hardware with no initialisation code, and depending on your choice of libc you can still use it (though some functionality may not be available).
  - pjmlp 4y ago
    At which point it is no longer C, rather a programing language that vaguely resembles ISO C.
    - vidarh 4y ago
      Of course it is still C. You've just opted not to use some of the functionality. Nothing stops you from e.g. providing your own startup code which then calls the appropriate initialisation code either. The point being that there's no enforced inversion of control in the sense used by the article, and so calling it a framework in the sense described by the article is meaningless. Even if we postulated the inversion of control was there, the fact you can replace all parts of it still means it does not fit the article definition.
      - pjmlp 4y ago
        Not from the point of view of ISO C and the expected semantics of the abstract C machine.
        vidarh 4y ago
        If you were to write a program that relies on those aspects of the abstract C machine and don't provide those aspects, then you might have an argument, in that in that case the observable behaviour would be different, but if you choose not to make use of that functionality, its presence is entirely irrelevant. This is also massively shifting goal posts. You first wrote "At which point it is no longer C". By your argument here, e.g. the Linux kernel is not written predominantly in C. But nobody uses the term that way. If you were to speak specifically about ISO C, maybe, but the person I replied to initially did not limit it to ISO C. As such this is also entirely irrelevant to the original argument.
        pjmlp 4y ago
        Everyone knows Linux is actually written in GCC C, and Google has burned lots of dollars making it work with clang, if it was proper C, that wouldn't never been an issue.
        vidarh 4y ago
        And yet almost everyone would still agree that "GCC C" is also C, so this is entirely irrelevant to what was being discussed.
camgunz 4y ago
The kernel loads your program, and schedules its execution. This is basically the same as using an async framework and sending the entry point to your application. If you're willing to extend a little, there are also signal handlers, or setting up callbacks in pthreads. Again this isn't to be reductive, but to say this is a super common method of encapsulating irrelevant stuff. It doesn't seem to be a significant differentiation between "I'm a library" and "I'm a framework".