4 ms·

In the 90s, most seriouc C programmers knew about these books. They were the core books most devs relied on and referred to. They're all good. I disagree with

In the 90s, most seriouc C programmers knew about these books. They were the core books most devs relied on and referred to. They're all good. I disagree with this comment: "No website is as good as a good book. And no good book is as good as a disassembly output." There are many websites today that are excellent. And there are many websites that cover obscure topics not found in books. Finally, I think it's important to move past C89 to at least C99. I realize in 2011 (the date of this post), that was less feasible. But today, there is little reason for most projects not use the advances found in C99.

imron 7y ago
> But today, there is little reason for most projects not use the advances found in C99. Does visual studio support c99 yet? Last I heard MS wasn’t interested in supporting it.
- hazeii 7y ago
  Really? No longer an MS user but occasionally my code gets ported to Windows so would like to know more.
  - dfox 7y ago
    MSVC in C mode is essentially C89 plus extensions needed to compile C++/C99-isms present in Windows SDK and DDK headers. And Microsoft seems to be mostly interested in whether the compiler is able to build NT kernel and drivers and nothing much else.
    - nwellnhof 7y ago
      That's not true for quite some time. Visual Studio 2013 added many C99 features that aren't in C++ like compound literals or designated initializers.
  - flohofwoe 7y ago
    The only notable C99 features not supported on the MSVC C compiler are: (a) VLAs, and (b) type-generic macros. The distinction between the MSVC C and C++ compiler is important though. The MSVC C++ compiler doesn't support any C99 features.
- zelly 7y ago
  You can use clang on VS
- xeeeeeeeeeeenu 7y ago
  It supports most of it. Useless stuff like VLA is still uninmplemented though.
  - polyphonicist 7y ago
    Why is VLA useless? Why was it added to C99?
    - flohofwoe 7y ago
      Because even C isn't free from the occasional misfeature slipping into the standard. VLAs come with a lot of caveats (e.g. available stack size being limited and opaque, no sizeof() support, etc). VLAs were made optional in C11, so it's better not to use them at all for portable code.
hazeii 7y ago
Personally (3 decades+ journeyman C), I find lot of the advances are often about trying to get people out of bad practices (e.g. stdint.h in C99 to fix portability issues between 32 and 64 bit).
- VonChair 7y ago
  I think it's important to push forward with getting people out of bad habits. In a lot of cases, the only way to do that is to force it. I don't often agree with things Apple does, but their forcing people to use x64 is similar to this I think.
- xscott 7y ago
  The names in stdint.h are ok, but the way they play with library functions like printf() and scanf() is not so great. Given an int64_t value x, each of these works on some platforms and is wrong on another: printf("here's your int64_t: %ld\n", x); printf("here's your int64_t: %lld\n", x); And the portable way using inttypes.h is really ugly: printf("portably int64_t: %" PRId64 "\n", x); There's another religious argument to be had over size_t vs ssize_t, but that can wait :-)
  - madmax96 7y ago
    Then there’s the perennial problem of missing format specifiers for POSIX types like pid_t. Although you could argue that POSIX should mandate macros to appropriately handle them, the root problem is the same. The default integer types have not aged well...
    - xscott 7y ago
      > missing format specifiers for POSIX types like pid_t This bothers me less because I can always cast it up: fprintf(logfile, "pid: %lld", (long long)pid); Technically not portable, but find a platform with PIDs where this breaks. You can count on long long being at least 64 bits, and I think it'll be a while before we need 128 bit process IDs. :-) > The default integer types have not aged well... To me, the real pisser is that every compiler copped out and decided to leave int at 32 bits when the architecture advanced to 64 bits. Part of the reason for compilers exploiting "signed can't overflow" is so they can work around for loops with 32 bit int variables, and this has ugly consequences because most of the conversion rules in C are defined with respect to int. And honestly, Microsoft should burn for leaving long at 32 bits.
fao_ 7y ago
> And there are many websites that cover obscure topics not found in books. Yup. Are there any books covering the same content that ctyme does? (http://www.ctyme.com/intr/int.htm http://www.ctyme.com/intr/int.htm)
- pansa2 7y ago
  Ah, the famous “Ralph Brown’s Interrupt List”. It was actually published as a book: https://www.amazon.com/PC-Interrupts-Programmers-Reference-Third-Party/dp/0201624850/ref=dp_ob_title_bk https://www.amazon.com/PC-Interrupts-Programmers-Reference-T...
  - markus_zhang 7y ago
    just curious. this is not relevant nowadays right?
    - fao_ 7y ago
      It's relevant for any computer with a BIOS, it's relevant for the coreboot project (although these days in diminishing value).
      - markus_zhang 7y ago
        Agreed. I need to get some time-off/tech resort to study the fundamentals.
anonsivalley652 7y ago
Nuance is needed. Multiple sources form the overall picture. I found that doing hard things in an embedded or conventional shipped product team is the best way to learn, and that working with effective people who used a particular language reasonably defensively and obviously for maintainability contributed the most code value. For example, I taught myself Pascal, C, C++, assembly and Java (badly) before attending undergrad. The good thing about the ugrad program I had was that there were SGI, HP-UX, Solaris and Linux boxes such that writing portable C was essential.. you couldn't turn in a project if make didn't work on every platform because they wouldn't say which one they would use ahead-of-time. Then, I had an embedded internship at GPS manufacturer to work on 900 Mhz and 2.4 GHz radio firmware where a C++ subset was used on a codebase that spanned about 100 products. Also, lots of refactoring test/flashing tools was required because of commented-out code remnants were checked-in and 2000-line megafunctions because interns just banged-out code without any enforced coding standards.

imron 7y ago

> But today, there is little reason for most projects not use the advances found in C99. Does visual studio support c99 yet? Last I heard MS wasn’t interested in supporting it.

hazeii 7y ago
Really? No longer an MS user but occasionally my code gets ported to Windows so would like to know more.
- dfox 7y ago
  MSVC in C mode is essentially C89 plus extensions needed to compile C++/C99-isms present in Windows SDK and DDK headers. And Microsoft seems to be mostly interested in whether the compiler is able to build NT kernel and drivers and nothing much else.
  - nwellnhof 7y ago
    That's not true for quite some time. Visual Studio 2013 added many C99 features that aren't in C++ like compound literals or designated initializers.
- flohofwoe 7y ago
  The only notable C99 features not supported on the MSVC C compiler are: (a) VLAs, and (b) type-generic macros. The distinction between the MSVC C and C++ compiler is important though. The MSVC C++ compiler doesn't support any C99 features.
zelly 7y ago
You can use clang on VS
xeeeeeeeeeeenu 7y ago
It supports most of it. Useless stuff like VLA is still uninmplemented though.
- polyphonicist 7y ago
  Why is VLA useless? Why was it added to C99?
  - flohofwoe 7y ago
    Because even C isn't free from the occasional misfeature slipping into the standard. VLAs come with a lot of caveats (e.g. available stack size being limited and opaque, no sizeof() support, etc). VLAs were made optional in C11, so it's better not to use them at all for portable code.

hazeii 7y ago

Personally (3 decades+ journeyman C), I find lot of the advances are often about trying to get people out of bad practices (e.g. stdint.h in C99 to fix portability issues between 32 and 64 bit).

VonChair 7y ago
I think it's important to push forward with getting people out of bad habits. In a lot of cases, the only way to do that is to force it. I don't often agree with things Apple does, but their forcing people to use x64 is similar to this I think.
xscott 7y ago
The names in stdint.h are ok, but the way they play with library functions like printf() and scanf() is not so great. Given an int64_t value x, each of these works on some platforms and is wrong on another: printf("here's your int64_t: %ld\n", x); printf("here's your int64_t: %lld\n", x); And the portable way using inttypes.h is really ugly: printf("portably int64_t: %" PRId64 "\n", x); There's another religious argument to be had over size_t vs ssize_t, but that can wait :-)
- madmax96 7y ago
  Then there’s the perennial problem of missing format specifiers for POSIX types like pid_t. Although you could argue that POSIX should mandate macros to appropriately handle them, the root problem is the same. The default integer types have not aged well...
  - xscott 7y ago
    > missing format specifiers for POSIX types like pid_t This bothers me less because I can always cast it up: fprintf(logfile, "pid: %lld", (long long)pid); Technically not portable, but find a platform with PIDs where this breaks. You can count on long long being at least 64 bits, and I think it'll be a while before we need 128 bit process IDs. :-) > The default integer types have not aged well... To me, the real pisser is that every compiler copped out and decided to leave int at 32 bits when the architecture advanced to 64 bits. Part of the reason for compilers exploiting "signed can't overflow" is so they can work around for loops with 32 bit int variables, and this has ugly consequences because most of the conversion rules in C are defined with respect to int. And honestly, Microsoft should burn for leaving long at 32 bits.

fao_ 7y ago

> And there are many websites that cover obscure topics not found in books. Yup. Are there any books covering the same content that ctyme does? (http://www.ctyme.com/intr/int.htm http://www.ctyme.com/intr/int.htm)

pansa2 7y ago
Ah, the famous “Ralph Brown’s Interrupt List”. It was actually published as a book: https://www.amazon.com/PC-Interrupts-Programmers-Reference-Third-Party/dp/0201624850/ref=dp_ob_title_bk https://www.amazon.com/PC-Interrupts-Programmers-Reference-T...
- markus_zhang 7y ago
  just curious. this is not relevant nowadays right?
  - fao_ 7y ago
    It's relevant for any computer with a BIOS, it's relevant for the coreboot project (although these days in diminishing value).
    - markus_zhang 7y ago
      Agreed. I need to get some time-off/tech resort to study the fundamentals.

anonsivalley652 7y ago

Nuance is needed. Multiple sources form the overall picture. I found that doing hard things in an embedded or conventional shipped product team is the best way to learn, and that working with effective people who used a particular language reasonably defensively and obviously for maintainability contributed the most code value. For example, I taught myself Pascal, C, C++, assembly and Java (badly) before attending undergrad. The good thing about the ugrad program I had was that there were SGI, HP-UX, Solaris and Linux boxes such that writing portable C was essential.. you couldn't turn in a project if make didn't work on every platform because they wouldn't say which one they would use ahead-of-time. Then, I had an embedded internship at GPS manufacturer to work on 900 Mhz and 2.4 GHz radio firmware where a C++ subset was used on a codebase that spanned about 100 products. Also, lots of refactoring test/flashing tools was required because of commented-out code remnants were checked-in and 2000-line megafunctions because interns just banged-out code without any enforced coding standards.