Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ISO C is increasingly moronic

varnish-cache.org

Post reply on HN
Print view View original

161–170 of 175 posts

Re: ISO C is increasingly moronic

#161

Post by ArbitraryLimits »

jedbrown wrote: post #97
forgotusername wrote: post #33

Earlier quoted context omitted.

For the third time, the API for setting stack size should be implementation defined because there are perfectly practical implementations for which any specification would be meaningless. Another reason is that almost all prevailing contemporary environments use virtual memory, and the prevailing embedded architecture (ARM) is about to go 64 bit (the desktop/server world already has). In a world with virtual memory,…

> almost all prevailing contemporary environments use virtual memory IBM's Compute Node Kernel (Blue Gene) uses offset-mapped memory (no TLB). This is great for reproducible performance (much less than 1% variability on thousands of cores, compare to 30% or more on Cray). Admittedly, most jobs running on CNK will use constant stack sizes across all threads, but not all. The C standard does not specify that the langua…

If they don't specify the use of a stack, why is there alloca() vs malloc()?

Re: ISO C is increasingly moronic

#162

Post by jasonwatkinspdx »

scott_s wrote: post #24
phkamp wrote: post #17

Earlier quoted context omitted.

First of all: You're wrong, the compatibility is the other way around: The old code will have to include 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 ve…

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.

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.

Re: ISO C is increasingly moronic

#163

Post by ajross »

gcr wrote: post #129
ajross wrote: post #9

Doesn't seem like the author really thought some of this through: FTA: " The file according to the standard shall have exactly this content: "#define noreturn _Noreturn" Are you crying or laughing yet ? " It's a compatibility constraint. They can't simply add new reserved words to the language because it will break preexisting code (c.f. all the old C headers with idenfiers like "bool" or "class" or "virtual" that do…

I know this is orthoganal to your point, but Arch Linux ships with python3 installed by default. Of course, python 2.7 is in the repositories, but you have to say /usr/bin/python2 to get to it. That breaks all those stupid build scripts that expect python 2.x to be installed in /usr/bin/python and nowhere else.

Wait... it's stupid to write a script that uses /usr/bin/python (or really "/bin/env python" per the convention in that community)? When those scripts were written, there was no "python2". It's certainly not their fault that "python" changed to be an interpreter for a different language.

This is exactly the problem. Distros (c.f. Red Hat, SUSE, Ubuntu) with large installed bases simply cannot ever ship a /usr/bin/python as anything but python 2 for exactly the same reason that the kernel cannot change syscall numbers. It will break their customer's software. Arch Linux doesn't really have "customers" in this sense, so they're free to play. The serious distros aren't.

Just mark my words: python 3 will never be a default "python". We're entering year 4 of the python3 era. You really think anyone's going to jump now if they haven't already?

Re: ISO C is increasingly moronic

#164

Post by Someone »

caf wrote: post #92

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 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 st…

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
or

  #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.

Re: ISO C is increasingly moronic

#165

Post by luser001 »

phkamp wrote: post #135
nitrogen wrote: post #117

Earlier quoted context omitted.

Dead post from ballard: ballard 3 hours ago | link [dead] Java was an over-reaction to C. Go was a reaction to Java back to almost center. C is close to hardware, which is important for things like game engine cores, video drivers, varnish and the list of use-cases goes on and on. Finally, people tend to complain about their tools even when those tools work. Be thankful if you didn't have to write the tool yourself.…

Last time I wrote inline ASM was 2 days ago. I'm a kernel programmer, remember ?

Just curious: what was it for? Link to public commit etc would also be ok. Thx. I was the impression that all the asm code was abstracted away in rarely-changing header file macros?

Re: ISO C is increasingly moronic

#166

Post by KaeseEs »

ArbitraryLimits wrote: post #161
jedbrown wrote: post #97

Earlier quoted context omitted.

> almost all prevailing contemporary environments use virtual memory IBM's Compute Node Kernel (Blue Gene) uses offset-mapped memory (no TLB). This is great for reproducible performance (much less than 1% variability on thousands of cores, compare to 30% or more on Cray). Admittedly, most jobs running on CNK will use constant stack sizes across all threads, but not all. The C standard does not specify that the langua…

If they don't specify the use of a stack, why is there alloca() vs malloc()?

alloca(3) isn't in ISO C (or even in POSIX).

Re: ISO C is increasingly moronic

#167

Post by JoshTriplett »

gsg wrote: post #156
JoshTriplett wrote: post #146

Earlier quoted context omitted.

System headers could use a #pragma _SystemIdentifiers, much like TeX's "makeatletter" and "makeatother" that allow packages to use @ in the name of internal symbols to avoid conflicts. I do think compilers ought to have warnings for using identifiers in the reserved namespace. Most projects probably wouldn't trip over the ^_[A-Z] reserved space; however, numerous projects would trip over the reservation of any identi…

That would require changing every single existing header that currently contains reserved identifiers. Do you have any idea how much work that is? Even if you could somehow magically enumerate and alter them all - and test them, since the necessary renaming of identifiers in non-system headers might introduce a bug - legacy versions would be floating around for years. Conceptually a warning is a nice idea, but it jus…

Not necessarily. GCC, at least, avoids showing warnings in system headers unless explicitly requested. So, normally you'd only see warnings about the use of reserved identifiers in your own code.

Re: ISO C is increasingly moronic

#168

Post by tedunangst »

Confusion wrote: post #134
tedunangst wrote: post #81

Earlier quoted context omitted.

phk under 30? hahaha. Does freebsd count as an old code base? If you direct your remarks at what's being said instead of who (you think) is saying it, you wouldn't miss so wildly.

I don't think that's entirely fair. Sometimes who someone is, is a decisive factor in what arguments they present. It can give them a valuable jolt of insight to point out that they present those arguments because they are missing part of the view. Of course you should also explain why the arguments in themselves are wrong, but the main argument may be "you've never experienced X; those that have tend to argue Y, bec…

It's very easy to make those arguments just by saying "From my experience doing X, you're wrong because..." without speculating about what the other person hasn't done.

Re: ISO C is increasingly moronic

#169

Post by scott_s »

jasonwatkinspdx wrote: post #162
scott_s wrote: post #24

Earlier quoted context omitted.

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.

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.

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...):

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.

Re: ISO C is increasingly moronic

#170

Post by caf »

Someone wrote: post #164
caf wrote: post #92

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 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 st…

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 or #define _C_SOURCE 20110101 Now, program P accidentally gets processed while noreturn is a keyword. I do not see how to fix this…

For precisely this reason, third-party libraries should not be including 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
Post reply on HN