5 ms·

So only 22 years ago :) Are C programmers still using C89 and C90?

by LAC-Tech 5y ago

_3u10 5y ago
Yes, Linux uses gnu89
- kazinator 5y ago
  .. and that allows plenty of silently accepted extensions, including variable-length arrays, which were in GNU C long before C99. It seems that only GCC 4.3 added the -Wvla option to unbundle the diagnosis of the presence of VLA's from -pedantic. Now you can write in gnu89, while banishing VLA's from your code base, if you're so inclined.
opencl 5y ago
There are a lot of C compilers out there, and many of them have not implemented all of C99. Microsoft started to add C99 features in MSVC2013 and still doesn't support the whole spec. The C compilers supplied by microcontroller vendors in particular are often, to put it charitably, not great at conforming with the latest standards.
- jlarocco 5y ago
  IIRC, Microsoft has publicly stated that they only plan to implement the parts of C99 required by the C++ standards. EDIT: Fact checking myself, I found [1], so apparently they've decided to start adding C11 and C17. C99 support isn't entirely clear, though. [1] https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/ https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-...
  - jcranmer 5y ago
    C99 added some (mandatory) features that had some issues with implementation, most notably variable-length arrays; C11 made those features optional instead. MSVC is unlikely to ever support VLAs (as noted in the blog post you linked). A parallel can be drawn to `export template` in C++98, which is a feature that was only ever implemented by a single compiler (whose engineers, when asked for recommendations to others attempting to implement, offered "don't"). As a result, it was dropped from later versions of the standard, and so almost every compiler doesn't actually support C++98 100%, but no one cares because the things that it doesn't implement doesn't matter. VLAs aren't quite as universally maligned as `export template`, but given that it's dropped to optional in later versions, it's not totally unreasonable to claim implementation of all of C99 that matters while not supporting VLAs.
    - pjmlp 5y ago
      VLAs are considered a huge mistake in security coding, to the point that Google sponsored the work to clean the Linux kernel of them.
      - rascul 5y ago
        HN discussion about it from 2018 (100 comments): https://news.ycombinator.com/item?id=18323938 https://news.ycombinator.com/item?id=18323938
      - kazinator 5y ago
        How recent is the -Wwla warning in GCC? Because it seems that would easily find them for you, and -Werror=vla prevent them from creeping in. Answering my own question: by doing a binary search on the online GCC documentation, I discovered that it's not documented up to 4.2.4. The next version up for which online documentation is hosted is 4.3.6, and that has -Wvla.
        pjmlp 5y ago
        Assuming all source code is available, the code is never migrated to other compilers, and every company in the world would actually bother to use such warnings when using GCC. Naturally removing them from ISO C was the saner option.
        kazinator 5y ago
        But they are forever in C99, which GCC supports. VLA's crept in to the kernel, which is what this thread is about. With -Wvla, you can learn about where all the VLA's are being declared in the code base. Also, don't forget that VLA's are a GCC extension which existed before C99. They are available in the -stdc=gnu89 mode, and -ansi (without -pedantic). They are available in -ansi mode (diagnosed if you use -pedantic). They were not "removed" from ISO C; they are optional. If you implement VLA's, there is an ISO-C-conforming way to do that. $ cat vla.c int fun(int x, int a[x]) { return 0; } int main(void) { return 0; } $ gcc -ansi vla.c $ gcc -std=gnu89 vla.c $ gcc -ansi -pedantic vla.c vla.c:1:1: warning: ISO C90 forbids variable length array ‘a’ [-Wvla] int fun(int x, int a[x]) { return 0; } ^~~ $ gcc -std=gnu89 -pedantic vla.c vla.c:1:1: warning: ISO C90 forbids variable length array ‘a’ [-Wvla] int fun(int x, int a[x]) { return 0; } ^~~ This warning is now linked to [-Wvla] rather than just [-pedantic], so you can have -pedantic on, yet allow VLA's without a diagnostic. $ gcc -std=gnu89 -pedantic -Wno-vla vla.c $ gcc -ansi -pedantic -Wno-vla vla.c Likewise you need -Wvla to police your code against VLA's creeping in, even if you're compiling in -ansi/-std=c90 mode. Traditionally, -pedantic will do it, but it's too strong; it rejects other things you might want. For instance, in the gnu89 dialect, you can initialize local structs and arrays with non-load-time computable expressions, which is complained about with -pedantic. Dynamic allocation from the stack is something that is quite essential in some situations, and a more efficient approach compared to other alternatives in some other situations. alloca never goes away, and VLA's are better than alloca in many ways.
__s 5y ago
Yes Postgres only updated to C99 with PG12 https://www.postgresql.org/docs/11/source-conventions.html https://www.postgresql.org/docs/11/source-conventions.html https://www.postgresql.org/docs/12/source-conventions.html https://www.postgresql.org/docs/12/source-conventions.html Some blame to be had by MSVC, which is called out in PEP7: https://www.python.org/dev/peps/pep-0007/#c-dialect https://www.python.org/dev/peps/pep-0007/#c-dialect
- deleted 5y ago
  [deleted]
- LAC-Tech 5y ago
  There are C99 (and beyond)_ compliant compilers for windows, aren't there? Why insist on MSVC when it's not one of them? (Genuine question. I remember python was c89 for similar reasons).
  - NavinF 5y ago
    It’s only recently (as in the last decade) that a drop-in replacement for MSVC’s cl.exe came along that’s ABI compatible and accepts the same CLI arguments: https://clang.llvm.org/docs/MSVCCompatibility.html https://clang.llvm.org/docs/MSVCCompatibility.html Incidentally, that’s around the same time MSVC started getting updates and became bearable.
    - LAC-Tech 5y ago
      I still don't get it. Why is a drop in replacement for MSVC needed? There were c99 compilers for windows before clang IIRC correctly. So why weren't they used, MSVC be damned? Full disclaimer, I've only ever used C in linux systems.
      - NavinF 5y ago
        Oh there were lots of other compilers. Hardly anyone used them because they didn't work with any existing tooling and IIRC most of them didn't even let you to link the system's UI libraries due to ABI issues and unsupported __stuff in headers. Sure you could work without tooling like a caveman and you could print text to stdout using only the libc you brought with you, but most programs need to do a bit more than that.
deleted 5y ago
[deleted]

So only 22 years ago :) Are C programmers still using C89 and C90?

_3u10 5y ago

Yes, Linux uses gnu89

kazinator 5y ago
.. and that allows plenty of silently accepted extensions, including variable-length arrays, which were in GNU C long before C99. It seems that only GCC 4.3 added the -Wvla option to unbundle the diagnosis of the presence of VLA's from -pedantic. Now you can write in gnu89, while banishing VLA's from your code base, if you're so inclined.

opencl 5y ago

There are a lot of C compilers out there, and many of them have not implemented all of C99. Microsoft started to add C99 features in MSVC2013 and still doesn't support the whole spec. The C compilers supplied by microcontroller vendors in particular are often, to put it charitably, not great at conforming with the latest standards.

jlarocco 5y ago
IIRC, Microsoft has publicly stated that they only plan to implement the parts of C99 required by the C++ standards. EDIT: Fact checking myself, I found [1], so apparently they've decided to start adding C11 and C17. C99 support isn't entirely clear, though. [1] https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/ https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-...
- jcranmer 5y ago
  C99 added some (mandatory) features that had some issues with implementation, most notably variable-length arrays; C11 made those features optional instead. MSVC is unlikely to ever support VLAs (as noted in the blog post you linked). A parallel can be drawn to `export template` in C++98, which is a feature that was only ever implemented by a single compiler (whose engineers, when asked for recommendations to others attempting to implement, offered "don't"). As a result, it was dropped from later versions of the standard, and so almost every compiler doesn't actually support C++98 100%, but no one cares because the things that it doesn't implement doesn't matter. VLAs aren't quite as universally maligned as `export template`, but given that it's dropped to optional in later versions, it's not totally unreasonable to claim implementation of all of C99 that matters while not supporting VLAs.
  - pjmlp 5y ago
    VLAs are considered a huge mistake in security coding, to the point that Google sponsored the work to clean the Linux kernel of them.
    - rascul 5y ago
      HN discussion about it from 2018 (100 comments): https://news.ycombinator.com/item?id=18323938 https://news.ycombinator.com/item?id=18323938
    - kazinator 5y ago
      How recent is the -Wwla warning in GCC? Because it seems that would easily find them for you, and -Werror=vla prevent them from creeping in. Answering my own question: by doing a binary search on the online GCC documentation, I discovered that it's not documented up to 4.2.4. The next version up for which online documentation is hosted is 4.3.6, and that has -Wvla.
      - pjmlp 5y ago
        Assuming all source code is available, the code is never migrated to other compilers, and every company in the world would actually bother to use such warnings when using GCC. Naturally removing them from ISO C was the saner option.
        kazinator 5y ago
        But they are forever in C99, which GCC supports. VLA's crept in to the kernel, which is what this thread is about. With -Wvla, you can learn about where all the VLA's are being declared in the code base. Also, don't forget that VLA's are a GCC extension which existed before C99. They are available in the -stdc=gnu89 mode, and -ansi (without -pedantic). They are available in -ansi mode (diagnosed if you use -pedantic). They were not "removed" from ISO C; they are optional. If you implement VLA's, there is an ISO-C-conforming way to do that. $ cat vla.c int fun(int x, int a[x]) { return 0; } int main(void) { return 0; } $ gcc -ansi vla.c $ gcc -std=gnu89 vla.c $ gcc -ansi -pedantic vla.c vla.c:1:1: warning: ISO C90 forbids variable length array ‘a’ [-Wvla] int fun(int x, int a[x]) { return 0; } ^~~ $ gcc -std=gnu89 -pedantic vla.c vla.c:1:1: warning: ISO C90 forbids variable length array ‘a’ [-Wvla] int fun(int x, int a[x]) { return 0; } ^~~ This warning is now linked to [-Wvla] rather than just [-pedantic], so you can have -pedantic on, yet allow VLA's without a diagnostic. $ gcc -std=gnu89 -pedantic -Wno-vla vla.c $ gcc -ansi -pedantic -Wno-vla vla.c Likewise you need -Wvla to police your code against VLA's creeping in, even if you're compiling in -ansi/-std=c90 mode. Traditionally, -pedantic will do it, but it's too strong; it rejects other things you might want. For instance, in the gnu89 dialect, you can initialize local structs and arrays with non-load-time computable expressions, which is complained about with -pedantic. Dynamic allocation from the stack is something that is quite essential in some situations, and a more efficient approach compared to other alternatives in some other situations. alloca never goes away, and VLA's are better than alloca in many ways.

__s 5y ago

Yes Postgres only updated to C99 with PG12 https://www.postgresql.org/docs/11/source-conventions.html https://www.postgresql.org/docs/11/source-conventions.html https://www.postgresql.org/docs/12/source-conventions.html https://www.postgresql.org/docs/12/source-conventions.html Some blame to be had by MSVC, which is called out in PEP7: https://www.python.org/dev/peps/pep-0007/#c-dialect https://www.python.org/dev/peps/pep-0007/#c-dialect

deleted 5y ago
[deleted]
LAC-Tech 5y ago
There are C99 (and beyond)_ compliant compilers for windows, aren't there? Why insist on MSVC when it's not one of them? (Genuine question. I remember python was c89 for similar reasons).
- NavinF 5y ago
  It’s only recently (as in the last decade) that a drop-in replacement for MSVC’s cl.exe came along that’s ABI compatible and accepts the same CLI arguments: https://clang.llvm.org/docs/MSVCCompatibility.html https://clang.llvm.org/docs/MSVCCompatibility.html Incidentally, that’s around the same time MSVC started getting updates and became bearable.
  - LAC-Tech 5y ago
    I still don't get it. Why is a drop in replacement for MSVC needed? There were c99 compilers for windows before clang IIRC correctly. So why weren't they used, MSVC be damned? Full disclaimer, I've only ever used C in linux systems.
    - NavinF 5y ago
      Oh there were lots of other compilers. Hardly anyone used them because they didn't work with any existing tooling and IIRC most of them didn't even let you to link the system's UI libraries due to ABI issues and unsupported __stuff in headers. Sure you could work without tooling like a caveman and you could print text to stdout using only the libc you brought with you, but most programs need to do a bit more than that.

deleted 5y ago

[deleted]