ISO C is increasingly moronic

Re:ISO C is increasingly moronic by caf on Tuesday December 20, 2011 @07:22PM (#3375829)

As noted elsewhere, the _Noreturn spelling is used precisely because such identifiers have been reserved since the first ISO C standard, so existing conforming code shouldn't use them and hence shouldn't break.

However, rather than introducing <stdnoreturn.h> to create the pretty spelling, it would perhaps have been better if the standard specified that if you define a macro like _C_SOURCE to a suitable value before including any standard headers then you get that define.

That would mean old conforming code would continue to work, and new code would just have to start out with

  #define _C_SOURCE 20110101

(or whatever the actual date specified is) to declare its allegience. This kind of thing would also allow older-standard compilers to detect and reject code that requires the newer standard.

[ Parent | on HN ]

Re:ISO C is increasingly moronic by Someone on Wednesday December 21, 2011 @01:12PM (#3378442)

Neither approach would allow one to mix the two versions. Consider the following use case: program P uses two third party libraries L and M, so it uses:

  #include "L.h"
  #include "M.h"

Program P gets updated by downloading improved versions of L and M. The new version of L.h does a

  #include <stdnoreturn.h>

  #define _C_SOURCE 20110101

Now, program P accidentally gets processed while noreturn is a keyword.

I do not see how to fix this (you could #undef every macro that the new C standard introduces before including M.h, but M.h might have a noreturn macro of its own that is not the ISO C version). It is just as if 'old C' and 'new C' are two different languages that happen to look similar, and that can be compiled by a single compiler.

[ Parent | on HN ]

Re:ISO C is increasingly moronic by caf on Wednesday December 21, 2011 @05:44PM (#3379461)

For precisely this reason, third-party libraries should not be including <stdnoreturn.h> in their external headers unless they are specifically intended to work only on C1x.

Under the _C_SOURCE scheme they certainly shouldn't be defining that macro, since the program which is including them has likely already defined it and you cannot have a duplicate macro definition. If they care, they should instead be testing its current value with #if, not changing it - ie, if a library requires C11x then it would use something like:

  #if _C_SOURCE < 20110101
      #error C11x or better required for this library
  #endif

[ Parent | on HN ]

Re:ISO C is increasingly moronic by phkamp on Wednesday December 21, 2011 @02:22AM (#3376700)

Provided you were prevented from linking objects together which were compiled with different C versions, that would be both better and safer.

The problem with ISO-C's approach is that the chances of having both "#include <stdbool.h>" and "#define bool char" in a codebase of a few million lines are almost unity, and causes bugs which are near-impossible to find, unless you happen to know the intricacies of hacks like this.

In general, optional features in a standard are a bad thing. ISO-C seems to think they are the solution to everything they cannot agree to do properly.

[ Parent | on HN ]