I am usually not one to appeal to authority, but I do find it amusing the number of people attempting to argue with somebody like phk over stylings of the C language. Most people on here would be overwhelmed with pride to have written a fraction of the important code he has.
ISO C is increasingly moronic
111–120 of 175 posts
Re: ISO C is increasingly moronic
#112Underscore-capital has been a reserved identifier prefix for many, many years. It's rather late to begin complaining about it. The side note about name-mangling on some platforms also using a leading underscore only shows that you can use a tool for years and still not understand it; that issue is completely orthogonal. I assure you, everyone on the committee is perfectly clear on the difference between name mangling and the reserved namespace.
The section on stack size is where it actually goes off the rails. C does not require that there be a stack. (Actually, the standard does not even contain the word "stack".) From that perspective, being able to control the "stack size" of a thread is nonsensical.
I'd be the first to agree that there have been some questionable additions to the C language, but this criticism comes off as half-baked at best. If you really care about this stuff, you should get involved with the standards process, or at least provide this feedback directly to the committee members--they are, for the most part, a very reasonable and thoughtful group of people.
Re: ISO C is increasingly moronic
#113Taking bets on when ISO C will acquire a form of templates, or taking it in even more generic direction - parametrized namespaces. Something like this (an illustrative example, don't knock me down for including val into list ): namespace(T) { struct list { T val; list * next; list * prev; }; void append(list * l, list * i) { ... } } Then list * foo, * bar; ... append(foo, bar); No need for namespace nesting, default…
[deleted]
Re: ISO C is increasingly moronic
#114Taking bets on when ISO C will acquire a form of templates, or taking it in even more generic direction - parametrized namespaces. Something like this (an illustrative example, don't knock me down for including val into list ): namespace(T) { struct list { T val; list * next; list * prev; }; void append(list * l, list * i) { ... } } Then list * foo, * bar; ... append(foo, bar); No need for namespace nesting, default…
Why not just use C++ without namespace nesting, default arguments, and other ++isms?
Re: ISO C is increasingly moronic
#115Earlier 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…
> The old code will have to include 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 is just pointless ornamentation, cluttering our source code. I think C's…
> 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.
Re: ISO C is increasingly moronic
#116Earlier quoted context omitted.
> Simple expressions like x.y++ could end up being much more expensive than expected. He's talking about pulling protocol packets off the wire - who increments values in a packet like that? Typically all you ever do is pull the relevant fields out into your own structure or pass them off as arguments to a function call. Which will always involve unaligned reads from buffer somewhere . The only real way I can see it b…
If you're just going to extract the values once, why not just write the code to actually do that instead of trying to play tricks with memcpy()? Those tricks won't even work in many cases where certain fields indicate the length of certain other fields (which is quite common). When I first started programming in C I also had this fantasy that I could parse network formats with memcpy(). Since then I've become convinc…
> If you're just going to extract the values once, why not just write the code to actually do that instead of trying to play tricks with memcpy()?
Because it's more expressive, doesn't cost performance, and is less error-prone than writing field extraction code manually. And because it's the type of processing people actually use C for.
> Those tricks won't even work in many cases where certain fields indicate the length of certain other fields (which is quite common).
... it's common for a field to specify the size of the data portion of a packet, not other header fields. The one exception I can think of is a version number, which indicates the layout of the rest of the packet, which isn't exactly rocket science to model using explicitly-packed structs.
> When I first started programming in C I also had this fantasy that I could parse network formats with memcpy().
Nobody here has such a fantasy, they're expressing a desire for this to be made possible.
> Since then I've become convinced that writing the actual parsing code is for the best.
Given a programming language grammar, would you prefer to use an LR parser generator, to write an LR grammar by hand, or to write a recursive-descent LL parser by hand?
Re: ISO C is increasingly moronic
#117Earlier quoted context omitted.
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.
Do you think a new language (Go, maybe?) will take C's place, given your distaste for ISO's handling of the standard?
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. But if you would feel compelled to complain, write a better one yourself first instead. :)
@phk: When was the last time you wrote inline asm in C to solve any problem on an non-embedded system? Mine was 1996.
Re: ISO C is increasingly moronic
#118Earlier quoted context omitted.
> The old code will have to include 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 is just pointless ornamentation, cluttering our source code. I think C's…
> 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.
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.)
Re: ISO C is increasingly moronic
#119Earlier quoted context omitted.
If you're just going to extract the values once, why not just write the code to actually do that instead of trying to play tricks with memcpy()? Those tricks won't even work in many cases where certain fields indicate the length of certain other fields (which is quite common). When I first started programming in C I also had this fantasy that I could parse network formats with memcpy(). Since then I've become convinc…
> If you're just going to extract the values once, why not just write the code to actually do that instead of trying to play tricks with memcpy()? Because it's more expressive, doesn't cost performance, and is less error-prone than writing field extraction code manually. And because it's the type of processing people actually use C for. > Those tricks won't even work in many cases where certain fields indicate the le…
It seems that the preferred implementation these days is to write an LL parser by hand, if most production compilers and interpreters are anything to go by.
Re: ISO C is increasingly moronic
#120Earlier quoted context omitted.
> 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.
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.
It's to allow use of any identifiers anywhere, not just keywords, without having to worry about conflicts with the including code.