8 ms·

Driving Compilers (2023)

93 points by misonic 1y ago

lynx97 1y ago
Nitpick: Almost all Hello World C examples are wrong. printf is for when you need to use a format string. Hello World doesn't. Besides: > puts() writes the string s and a trailing newline to stdout. int main() { puts("Hello World!"); }
- PhilipRoman 1y ago
  Eh, it compiles down to the same thing with optimizations enabled: https://godbolt.org/z/zcqa4Txen https://godbolt.org/z/zcqa4Txen But I agree, using printf for constant strings is one step away from doing printf(x) which is a big no-no.
  - Joker_vD 1y ago
    Useless bit of compiler optimizations trivia: the "this printf() is equivalent to puts()" optimization seems to work by looking for the '%' in the format string, not by counting whether there is only one argument to printf(), e.g. if you add 42 as a second argument to the printf() — which is absolutely legal and required by the standard to Work as Intended™ — the resulting binary still uses puts().
- unwind 1y ago
  I agree, but I have to point out that if you're gonna be like that, then you should be explicit about your final return 0;
  - tavianator 1y ago
    The C standard (since C99) says that `main()` has an implicit `return 0`, you don't need to write it explicitly.
    - 01HNNWZ0MV43FF 1y ago
      Sure but are we teaching good habits to students, or are we golfing?
      - pjmlp 1y ago
        Given how many tutorials leave best practices out on how to do proper error handling, strings and arrays in C, doing analysis as part of the build, I would say golfing most of the time.
  - lynx97 1y ago
    Aww, of course, you're right.
- indigoabstract 1y ago
  The example is kind of pedantic, but I think a linter might be able to catch it.
- deleted 1y ago
  [deleted]
- Mbwagava 1y ago
  Eh, not a fan of puts. It doesn't add any value over write or printf and it should be named "printLine". But if you're still using raw libc in 2025 that's a problem you willingly opted into. I have zero sympathy.
- tom_ 1y ago
  But "Hello world\n" is a format string. The format strings with no % chars in them are the best type of format string! They're nearly impossible to get wrong!
- david2ndaccount 1y ago
  That’s not the point of hello world. It’s not to be as small a valid program as possible. It’s to be a small program that also exercises the needed functionality for using the tool usefully. All of the exercises following that hello world need formatted text, so introducing puts would just add confusion and wouldn’t verify that you have a working printf.
Timwi 1y ago
I share the frustration the author describes. When I started out programming as a child, I used Turbo Pascal, but I was aware of Turbo C and that more people used that than Pascal. Nevertheless, I couldn't really wrap my head around C at the time, and it was partly due to linker errors that I couldn't understand; and it seemed that Turbo Pascal just didn't use a linker, so it was easier to understand and tinker with at age 9. It's intriguing to think how different my experience could have been if educational material at the time had focused as much on full explanations of the compiler+linker process, including example error conditions, as it did on teaching the language. 30 years later, I like to claim that I have a reasonably workable understanding of how compilers work, but I'm still nebulous on how linkers do what they do. I'm much more comfortable with higher-level compilers such as C# that compile to a VM bytecode (IL) and don't worry about linkers.
- virgilp 1y ago
  Linkers pretty much map data sections to memory, and in doing so are able to replace symbolic names (like global variables, or goto targets) with numbers. They may also completely drop some things that are not needed (e.g. code/files in a library that is never referenced). I'm over-simplifying and also it's a bit incorrect, because there's also the loader that does a lot of the same work that linkers do, when loading the program in memory. So linkers don't actually produce the final image - but really, they're rather "simple" things (for some definition of "simple"). The hard-to-understand linker errors are typically caused by the compiler, not the linker (it's the compiler that speculatively chooses to use a symbol with a long and funny name, thinking that it'll later be provided by <somebody>, when in fact the linker later finds out that no library or object file actually provided said symbol; and then for the linker to give you a decent error message, it needs to have a pretty good understanding of what the compiler was actually trying to do - i.e. to know implementation details of the compiler that otherwise would not concern it at all).
  - tester756 1y ago
    >The hard-to-understand linker errors are typically caused by the compiler, not the linker (it's the compiler that speculatively chooses to use a symbol with a long and funny name, thinking that it'll later be provided by <somebody>, when in fact the linker later finds out that no library or object file actually provided said symbol; and then for the linker to give you a decent error message, it needs to have a pretty good understanding of what the compiler was actually trying to do - i.e. to know implementation details of the compiler that otherwise would not concern it at all). So... maybe let's avoid having linker as another/external tool and just let compiler perform linking
stef-13013 1y ago
Really nice, thanks !!

93 points by misonic 1y ago

Nitpick: Almost all Hello World C examples are wrong. printf is for when you need to use a format string. Hello World doesn't. Besides: > puts() writes the string s and a trailing newline to stdout. int main() { puts("Hello World!"); }

PhilipRoman 1y ago
Eh, it compiles down to the same thing with optimizations enabled: https://godbolt.org/z/zcqa4Txen https://godbolt.org/z/zcqa4Txen But I agree, using printf for constant strings is one step away from doing printf(x) which is a big no-no.
- Joker_vD 1y ago
  Useless bit of compiler optimizations trivia: the "this printf() is equivalent to puts()" optimization seems to work by looking for the '%' in the format string, not by counting whether there is only one argument to printf(), e.g. if you add 42 as a second argument to the printf() — which is absolutely legal and required by the standard to Work as Intended™ — the resulting binary still uses puts().
unwind 1y ago
I agree, but I have to point out that if you're gonna be like that, then you should be explicit about your final return 0;
- tavianator 1y ago
  The C standard (since C99) says that `main()` has an implicit `return 0`, you don't need to write it explicitly.
  - 01HNNWZ0MV43FF 1y ago
    Sure but are we teaching good habits to students, or are we golfing?
    - pjmlp 1y ago
      Given how many tutorials leave best practices out on how to do proper error handling, strings and arrays in C, doing analysis as part of the build, I would say golfing most of the time.
- lynx97 1y ago
  Aww, of course, you're right.
indigoabstract 1y ago
The example is kind of pedantic, but I think a linter might be able to catch it.
deleted 1y ago
[deleted]
Mbwagava 1y ago
Eh, not a fan of puts. It doesn't add any value over write or printf and it should be named "printLine". But if you're still using raw libc in 2025 that's a problem you willingly opted into. I have zero sympathy.
tom_ 1y ago
But "Hello world\n" is a format string. The format strings with no % chars in them are the best type of format string! They're nearly impossible to get wrong!
david2ndaccount 1y ago
That’s not the point of hello world. It’s not to be as small a valid program as possible. It’s to be a small program that also exercises the needed functionality for using the tool usefully. All of the exercises following that hello world need formatted text, so introducing puts would just add confusion and wouldn’t verify that you have a working printf.

Timwi 1y ago

I share the frustration the author describes. When I started out programming as a child, I used Turbo Pascal, but I was aware of Turbo C and that more people used that than Pascal. Nevertheless, I couldn't really wrap my head around C at the time, and it was partly due to linker errors that I couldn't understand; and it seemed that Turbo Pascal just didn't use a linker, so it was easier to understand and tinker with at age 9. It's intriguing to think how different my experience could have been if educational material at the time had focused as much on full explanations of the compiler+linker process, including example error conditions, as it did on teaching the language. 30 years later, I like to claim that I have a reasonably workable understanding of how compilers work, but I'm still nebulous on how linkers do what they do. I'm much more comfortable with higher-level compilers such as C# that compile to a VM bytecode (IL) and don't worry about linkers.

virgilp 1y ago
Linkers pretty much map data sections to memory, and in doing so are able to replace symbolic names (like global variables, or goto targets) with numbers. They may also completely drop some things that are not needed (e.g. code/files in a library that is never referenced). I'm over-simplifying and also it's a bit incorrect, because there's also the loader that does a lot of the same work that linkers do, when loading the program in memory. So linkers don't actually produce the final image - but really, they're rather "simple" things (for some definition of "simple"). The hard-to-understand linker errors are typically caused by the compiler, not the linker (it's the compiler that speculatively chooses to use a symbol with a long and funny name, thinking that it'll later be provided by <somebody>, when in fact the linker later finds out that no library or object file actually provided said symbol; and then for the linker to give you a decent error message, it needs to have a pretty good understanding of what the compiler was actually trying to do - i.e. to know implementation details of the compiler that otherwise would not concern it at all).
- tester756 1y ago
  >The hard-to-understand linker errors are typically caused by the compiler, not the linker (it's the compiler that speculatively chooses to use a symbol with a long and funny name, thinking that it'll later be provided by <somebody>, when in fact the linker later finds out that no library or object file actually provided said symbol; and then for the linker to give you a decent error message, it needs to have a pretty good understanding of what the compiler was actually trying to do - i.e. to know implementation details of the compiler that otherwise would not concern it at all). So... maybe let's avoid having linker as another/external tool and just let compiler perform linking

stef-13013 1y ago

Really nice, thanks !!