7 ms·

First of all: You're wrong, the compatibility is the other way around: The old code will have to include <stdnoreturn.h> if they used the "noreturn" compiler-s

by phkamp 15y ago

First of all: You're wrong, the compatibility is the other way around: The old code will have to include <stdnoreturn.h> if they used the "noreturn" compiler-specific keyword, while waiting for the glacial ISO WG progress. Second: There are two kinds of compatibility: Forwards compatbility and backwards compatibilty. There is a finite number of existing programs whereas the number of future programs to be written is unbounded and very likely to be much higher over time. Therefore forwards compatibility is always, by definition, more important than backwards compatibility, and you should never penalize future programs and programmers for the misdeeds and sloppines of the past programs and programmers. Besides: I have yet to see a compiler that didn't have flags to make it compile to a slew of older dialects of C, so if C1X happens to break your old code, you set such an option, or you fix your source code. There, fixed it for you. The "Backwards compatibility, no matter the cost" mentaility is costing us dearly in the quality of the tools we have work with in the future, while providing us no relevant new benefits. Crap like <stdnoreturn.h> is just pointless ornamentation, cluttering our source code.

scott_s 15y ago
If you don't value backwards compatibility, then perhaps you should not use a 40-year-old language with a standards committee that does value it.
- dextorious 15y ago
  tl;dr: if you don't value backwards compatibility, bend over backwards.
- jasonwatkinspdx 15y ago
  I see no reason why he shouldn't express his opinion on the committee's goals re backward computability. Defending the status quo by saying "well duh, you should know better, take it or leave it" is just a way of rejecting someone's contentions without actually addressing them. In a reasoned debate that's indefensible. If he's wrong, tell him why rather than telling him to take his ball and go home.
  - scott_s 15y ago
    This is from the Rationale for an International Standard for C, in the intro where they state their guiding principles from 2003 (http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10...): Existing code is important, existing implementations are not. A large body of C code exists of considerable commercial value. Every attempt has been made to ensure that the bulk of this code will be acceptable to any implementation conforming to the Standard. The C89 Committee 20 did not want to force most programmers to modify their C programs just to have them accepted by a conforming translator. Note that this guiding principle was listed first. The author disagrees with one of their fundamental guiding principles. My point is that he then has a fundamental disagreement with the purpose of the standard, and for that reason, perhaps he is using the wrong tool. If someone has the guiding principle X, and someone else has the guiding principle !X, I contend that difference is irreconcilable.
- 4ad 15y ago
  Dennis Ritchie, C's creator, along with Ken Thompson, Unix' creator, and other Bell Labs people from the Computing Science Research Center thought the C standardization committee was wrong, so the Plan9 C compiler[1,2] is not ANSI compatible. Not only the standard library is nothing alike, the language itself is slightly changed in an incompatible way. [1] http://cm.bell-labs.com/sys/doc/comp.html http://cm.bell-labs.com/sys/doc/comp.html [2] http://cm.bell-labs.com/sys/doc/compiler.html http://cm.bell-labs.com/sys/doc/compiler.html
aliguori 15y ago
I don't agree with your assertion that backwards compatibility isn't important, but I would like to point out that the very fact that C compilers allow you to use identifiers that are in the form _Word means that they are breaking backwards compatibility by introducing new keywords. Many of the libraries on a typical Linux system (anything glib/gtk based, libxml2, etc.) use _Word extensively.
- breadbox 15y ago
  Initial underscore followed by a capital letter is a reserved "namespace" since 1990, as a previous commenter noted. (And for the record, identifiers that begin with two underscores are reserved for use by the implementation, and identifiers followed by a lowercase letter are guaranteed to be unreserved as long as they are file-scoped symbols, and not globally visible.)
  - aliguori 15y ago
    Yes, I realize this, but since it's only "reserved" in the specification and the compiler doesn't enforce this, there is a massive amount of code that does this today. The spec could contain, "don't add any bugs into your C programs" but that doesn't magically mean that everyone would write bug free code. Reserving a namespace and not having a mechanism to enforce it was a massive fail on the part of the standards committee.
    - plq 15y ago
      > Reserving a namespace and not having a mechanism to enforce it was a massive fail on the part of the standards committee. How do you expect the compiler to enforce the "identifiers that begin with two underscores are reserved for use by the implementation" rule? Some things just belong in the documentation.
      - aliguori 15y ago
        If the goal is to allow the introduction of new keywords, then it's fairly simple. Don't parse anything in the form __[a-z0-9$_] as anything but a keyword. Problem solved. Instead, they did something awkward by trying to carve out namespaces for the stdlib too but quite frequently don't adhere to their own rules.
angersock 15y ago
Therefore forwards compatibility is always, by definition, more important than backwards compatibility, and you should never penalize future programs and programmers for the misdeeds and sloppines of the past programs and programmers. Ha. You're adorable. While I do support the general "hey, let's fix old code and not be slaves to backwards compatibility", the fact of the matter is that legacy code / libraries / whatever in C aren't merely misdeeds/sloppiness--you might as well complain about having to use the same molecules of metal in your tools that our ancestors did building Rome instead of making your own from subatomic particles. There is a finite number of existing programs whereas the number of future programs to be written is unbounded and very likely to be much higher over time. But in the future, it's all Javascript/Ruby/CSS/HTML5! Why worry about writing more C code? ;)
- dextorious 15y ago
  """While I do support the general "hey, let's fix old code and not be slaves to backwards compatibility", the fact of the matter is that legacy code / libraries / whatever in C aren't merely misdeeds/sloppiness--you might as well complain about having to use the same molecules of metal in your tools that our ancestors did building Rome instead of making your own from subatomic particles."""" Only you have to use the same molecules of metal by the laws of physics, while compilers you can IMPROVE. Heck, we even produce new metal alloys and materials all the time. So, the analogy is 100% flawed.
  - angersock 15y ago
    I've got one involving cars if you prefer. :)
kmm 15y ago
No, you're wrong. The old code will have something like typedef char bool And thus compiling this code in C99 would not work if bool were a keyword of the language. That is why the boolean datatype is called _Bool, so it doesn't clash with old code. In new code, you can still use the bool datatype, but instead of defining it yourself with char or int, you should better use a typedef of the _Bool datatype in stdbool.h
- alexchamberlain 15y ago
  Your attitude is rediculous... Let code break! Make sure there is a __c1x macro and maintained projects will take 30 seconds to fix. Unmaintained projects will die, yay!
  - mcherm 15y ago
    I will never purchase a compiler made by you or someone who thinks like you. Sure, it will take 30 seconds to fix your puny 2000 line program that's contained in just a handful of files all of which you control and with no code generation engines or text transformation steps in its build chain. But it wouldn't be that easy for everyone.
- deleted 15y ago
  [deleted]
teyc 15y ago
The "Backwards compatibility, no matter the cost" mentaility is costing us dearly in the quality of the tools we have work with in the future, while providing us no relevant new benefits. That is only because you don't have a vested interest in old code bases. (Taking a rough guess here: you're under 30?)
- phkamp 15y ago
  You have absolutely no idea what, or rather: who, you are talking about: I'm the second most active committer to FreeBSDs kernel over the project lifetime and I'm the author of Varnish, I even have C-code running in ATC systems, heck when it comes to that: My code scrambles your password. It's exactly because I am responsible for so much old code that I say we should not cripple the future for it.
  - teyc 15y ago
    First off, I didn't realize. I'm sorry. I am responsible for so much old code that I say we should not cripple the future for it. I had to read that a few times. Are you advocating a clean break so that whatever that is future is clearly not called C or even purports to be backwards compatible with C? That would be difficult wouldn't it? It simply wouldn't get traction.
    - phkamp 15y ago
      I'm not sure I have a coherent proposal. Clearly ISO-C is a cul-de-sac by now, and will have to be ditched. What we should replace it with is not clear to me. It is a big problem that so many standards, requirements and tools (from EMACS to Coverity over lint) have their fingers in the C-syntax. The autocrap abomination is a further complication. So I guess a good place to start is to swear that we will never touch or use the botched ISO-C thread API, and beat some sense into the WG14, by whatever means are available.
      - teyc 15y ago
        Perhaps the only place for C to go is for a final consolidation specification, which will be frozen for 50 years. You might even remove some broken parts of previous specifications, but with 50 years of stability, it gives a lot of confidence that any work would be worthwhile. A long period of stability may also make it easy for C to interact with other languages. I'm out of my depth here. Some standard specifications for pinning memory from garbage collection, if Scheme could specify TCO, perhaps C-consolidation release could improve its toolability for things like Coverity; A better autoconf; Makefiles; Standard compilation error codes; Something that would clean up all the rough edges in supporting C compilers.
chipsy 15y ago
Maybe the ISO committee is conspiring to destroy C with mediocrity so that a shiny new systems language can take its place, correcting C's deeper warts in the process. That would be nice, if only I believed it.
- ajross 15y ago
  Exactly. I've long since lost track of which shiny new systems language we're supposed to be using.
  - politician 15y ago
    What do you think about D? ;)
    - anacrolix 15y ago
      No.
    - zem 15y ago
      D seems to be targeting C++ more than it does C.
comex 15y ago
> The old code will have to include <stdnoreturn.h> if they used the "noreturn" compiler-specific keyword, while waiting for the glacial ISO WG progress. Huh? stdnoreturn.h only makes sense with the new _Noreturn keyword. The old code can keep using __attribute__((noreturn)) or (if it was portable code) nothing at all, without including any headers. > Crap like <stdnoreturn.h> is just pointless ornamentation, cluttering our source code. I think C's "add seemingly randomly named include files to the top of your code to use different parts of the standard library" is pointless, and I'd like to see the whole standard library included by default (using some yet-to-be-invented more flexible PCH magic to ensure it doesn't slow down compilation). But in lieu of that, it's hardly a big jump from library to syntax - and if keeping backward compatibility isn't hard, why not do it?
- tptacek 15y ago
  I tend to agree with you about C include files, but observe that you can get more or less the same effect with a single "myproject.h" file included in your myproject-x source files.
- shadowfox 15y ago
  > C's "add seemingly randomly named include files to the top of your code to use different parts of the standard library" is pointless But doesn't most languages do this? Like java's imports (only a really small subset is included by default) or python. I would have thought that namespace separation is a good thing.
  - comex 15y ago
    I don't use Java, but Python has a reasonably large set of builtins, and the base modules like os and sys provide a lot more - C would require a longer list of includes. Still, I would like to be able to write something like "mmap::mmap" and have Python automatically figure out what to import, keeping the namespace separation but eliminating the redundancy of explicit imports. (maybe pick something other than double colons, heh.)
    - 15y ago

by phkamp 15y ago

scott_s 15y ago

If you don't value backwards compatibility, then perhaps you should not use a 40-year-old language with a standards committee that does value it.

dextorious 15y ago
tl;dr: if you don't value backwards compatibility, bend over backwards.
jasonwatkinspdx 15y ago
I see no reason why he shouldn't express his opinion on the committee's goals re backward computability. Defending the status quo by saying "well duh, you should know better, take it or leave it" is just a way of rejecting someone's contentions without actually addressing them. In a reasoned debate that's indefensible. If he's wrong, tell him why rather than telling him to take his ball and go home.
- scott_s 15y ago
  This is from the Rationale for an International Standard for C, in the intro where they state their guiding principles from 2003 (http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10...): Existing code is important, existing implementations are not. A large body of C code exists of considerable commercial value. Every attempt has been made to ensure that the bulk of this code will be acceptable to any implementation conforming to the Standard. The C89 Committee 20 did not want to force most programmers to modify their C programs just to have them accepted by a conforming translator. Note that this guiding principle was listed first. The author disagrees with one of their fundamental guiding principles. My point is that he then has a fundamental disagreement with the purpose of the standard, and for that reason, perhaps he is using the wrong tool. If someone has the guiding principle X, and someone else has the guiding principle !X, I contend that difference is irreconcilable.
4ad 15y ago
Dennis Ritchie, C's creator, along with Ken Thompson, Unix' creator, and other Bell Labs people from the Computing Science Research Center thought the C standardization committee was wrong, so the Plan9 C compiler[1,2] is not ANSI compatible. Not only the standard library is nothing alike, the language itself is slightly changed in an incompatible way. [1] http://cm.bell-labs.com/sys/doc/comp.html http://cm.bell-labs.com/sys/doc/comp.html [2] http://cm.bell-labs.com/sys/doc/compiler.html http://cm.bell-labs.com/sys/doc/compiler.html

aliguori 15y ago

I don't agree with your assertion that backwards compatibility isn't important, but I would like to point out that the very fact that C compilers allow you to use identifiers that are in the form _Word means that they are breaking backwards compatibility by introducing new keywords. Many of the libraries on a typical Linux system (anything glib/gtk based, libxml2, etc.) use _Word extensively.

breadbox 15y ago
Initial underscore followed by a capital letter is a reserved "namespace" since 1990, as a previous commenter noted. (And for the record, identifiers that begin with two underscores are reserved for use by the implementation, and identifiers followed by a lowercase letter are guaranteed to be unreserved as long as they are file-scoped symbols, and not globally visible.)
- aliguori 15y ago
  Yes, I realize this, but since it's only "reserved" in the specification and the compiler doesn't enforce this, there is a massive amount of code that does this today. The spec could contain, "don't add any bugs into your C programs" but that doesn't magically mean that everyone would write bug free code. Reserving a namespace and not having a mechanism to enforce it was a massive fail on the part of the standards committee.
  - plq 15y ago
    > Reserving a namespace and not having a mechanism to enforce it was a massive fail on the part of the standards committee. How do you expect the compiler to enforce the "identifiers that begin with two underscores are reserved for use by the implementation" rule? Some things just belong in the documentation.
    - aliguori 15y ago
      If the goal is to allow the introduction of new keywords, then it's fairly simple. Don't parse anything in the form __[a-z0-9$_] as anything but a keyword. Problem solved. Instead, they did something awkward by trying to carve out namespaces for the stdlib too but quite frequently don't adhere to their own rules.

angersock 15y ago

Therefore forwards compatibility is always, by definition, more important than backwards compatibility, and you should never penalize future programs and programmers for the misdeeds and sloppines of the past programs and programmers. Ha. You're adorable. While I do support the general "hey, let's fix old code and not be slaves to backwards compatibility", the fact of the matter is that legacy code / libraries / whatever in C aren't merely misdeeds/sloppiness--you might as well complain about having to use the same molecules of metal in your tools that our ancestors did building Rome instead of making your own from subatomic particles. There is a finite number of existing programs whereas the number of future programs to be written is unbounded and very likely to be much higher over time. But in the future, it's all Javascript/Ruby/CSS/HTML5! Why worry about writing more C code? ;)

dextorious 15y ago
"""While I do support the general "hey, let's fix old code and not be slaves to backwards compatibility", the fact of the matter is that legacy code / libraries / whatever in C aren't merely misdeeds/sloppiness--you might as well complain about having to use the same molecules of metal in your tools that our ancestors did building Rome instead of making your own from subatomic particles."""" Only you have to use the same molecules of metal by the laws of physics, while compilers you can IMPROVE. Heck, we even produce new metal alloys and materials all the time. So, the analogy is 100% flawed.
- angersock 15y ago
  I've got one involving cars if you prefer. :)

kmm 15y ago

No, you're wrong. The old code will have something like typedef char bool And thus compiling this code in C99 would not work if bool were a keyword of the language. That is why the boolean datatype is called _Bool, so it doesn't clash with old code. In new code, you can still use the bool datatype, but instead of defining it yourself with char or int, you should better use a typedef of the _Bool datatype in stdbool.h

alexchamberlain 15y ago
Your attitude is rediculous... Let code break! Make sure there is a __c1x macro and maintained projects will take 30 seconds to fix. Unmaintained projects will die, yay!
- mcherm 15y ago
  I will never purchase a compiler made by you or someone who thinks like you. Sure, it will take 30 seconds to fix your puny 2000 line program that's contained in just a handful of files all of which you control and with no code generation engines or text transformation steps in its build chain. But it wouldn't be that easy for everyone.
deleted 15y ago
[deleted]

teyc 15y ago

The "Backwards compatibility, no matter the cost" mentaility is costing us dearly in the quality of the tools we have work with in the future, while providing us no relevant new benefits. That is only because you don't have a vested interest in old code bases. (Taking a rough guess here: you're under 30?)

phkamp 15y ago
You have absolutely no idea what, or rather: who, you are talking about: I'm the second most active committer to FreeBSDs kernel over the project lifetime and I'm the author of Varnish, I even have C-code running in ATC systems, heck when it comes to that: My code scrambles your password. It's exactly because I am responsible for so much old code that I say we should not cripple the future for it.
- teyc 15y ago
  First off, I didn't realize. I'm sorry. I am responsible for so much old code that I say we should not cripple the future for it. I had to read that a few times. Are you advocating a clean break so that whatever that is future is clearly not called C or even purports to be backwards compatible with C? That would be difficult wouldn't it? It simply wouldn't get traction.
  - phkamp 15y ago
    I'm not sure I have a coherent proposal. Clearly ISO-C is a cul-de-sac by now, and will have to be ditched. What we should replace it with is not clear to me. It is a big problem that so many standards, requirements and tools (from EMACS to Coverity over lint) have their fingers in the C-syntax. The autocrap abomination is a further complication. So I guess a good place to start is to swear that we will never touch or use the botched ISO-C thread API, and beat some sense into the WG14, by whatever means are available.
    - teyc 15y ago
      Perhaps the only place for C to go is for a final consolidation specification, which will be frozen for 50 years. You might even remove some broken parts of previous specifications, but with 50 years of stability, it gives a lot of confidence that any work would be worthwhile. A long period of stability may also make it easy for C to interact with other languages. I'm out of my depth here. Some standard specifications for pinning memory from garbage collection, if Scheme could specify TCO, perhaps C-consolidation release could improve its toolability for things like Coverity; A better autoconf; Makefiles; Standard compilation error codes; Something that would clean up all the rough edges in supporting C compilers.

chipsy 15y ago

Maybe the ISO committee is conspiring to destroy C with mediocrity so that a shiny new systems language can take its place, correcting C's deeper warts in the process. That would be nice, if only I believed it.

ajross 15y ago
Exactly. I've long since lost track of which shiny new systems language we're supposed to be using.
- politician 15y ago
  What do you think about D? ;)
  - anacrolix 15y ago
    No.
  - zem 15y ago
    D seems to be targeting C++ more than it does C.

comex 15y ago

> The old code will have to include <stdnoreturn.h> if they used the "noreturn" compiler-specific keyword, while waiting for the glacial ISO WG progress. Huh? stdnoreturn.h only makes sense with the new _Noreturn keyword. The old code can keep using __attribute__((noreturn)) or (if it was portable code) nothing at all, without including any headers. > Crap like <stdnoreturn.h> is just pointless ornamentation, cluttering our source code. I think C's "add seemingly randomly named include files to the top of your code to use different parts of the standard library" is pointless, and I'd like to see the whole standard library included by default (using some yet-to-be-invented more flexible PCH magic to ensure it doesn't slow down compilation). But in lieu of that, it's hardly a big jump from library to syntax - and if keeping backward compatibility isn't hard, why not do it?

tptacek 15y ago
I tend to agree with you about C include files, but observe that you can get more or less the same effect with a single "myproject.h" file included in your myproject-x source files.
shadowfox 15y ago
> C's "add seemingly randomly named include files to the top of your code to use different parts of the standard library" is pointless But doesn't most languages do this? Like java's imports (only a really small subset is included by default) or python. I would have thought that namespace separation is a good thing.
- comex 15y ago
  I don't use Java, but Python has a reasonably large set of builtins, and the base modules like os and sys provide a lot more - C would require a longer list of includes. Still, I would like to be able to write something like "mmap::mmap" and have Python automatically figure out what to import, keeping the namespace separation but eliminating the redundancy of explicit imports. (maybe pick something other than double colons, heh.)
  - 15y ago