21 ms·

ISO C is increasingly moronic

283 points by phkamp 15y ago

C is a very robust language which is hard to ruin, but ISO surely is trying. The latest draft has a new mandatory one-macro #include file, and new incompatible and useless thread API, but still not compiler support for big-endian/little-endian variables or structure packing to match protocol specifications.

forgotusername 15y ago
Ignoring complaints about the introduction of a new style of _Identifier, the rant about pthreads seems myopic or just plain wrong. For a start as a vendor-neutral spec (the C standard itself), pthreads would never be adopted as-is. It simply couldn't happen for political reasons (without knowing a thing about the internals of the working group, I'm fairly confident of that). In the meantime it is still useful to define some uniform cross-platform API, even if most organizations continue to use pthreads in legacy code. Assuming "too dangerous" wasn't a direct quote: stack size is an implementation detail, something they probably intentionally left undefined. There are good reasons for this, not least baking assumptions about the underlying machine into the standard has never been a goal. Secondly, with advances like Go's dynamic stacks and its <5 assembly instruction overhead, why would you go and bake a feature akin to a modern sbrk(2) in when sexy alternatives that might see wider adoption are already seeing deployment. As for timed sleeps, providing absolute timestamps rather than intervals is important because it prevents drift: given any function manipulating time, or some timeout, calculating some perceptible end time in the function prologue is much more immune to stupid developers introducing drift (via loops), than expecting the average Joe to account for the latency/contention introduced by system calls, the scheduler, power management, etc. Fears regarding ntpd causing sudden jumps aren't well-founded (ntpd adjusts time very slowly, in sub-second intervals), although the general argument is fair (the sys admin, or other crazy external sources, can cause large time jumps).
- phkamp 15y ago
  This comment was filled with fail. Pthreads has been the standard for 20 years, either you do better than it does, or you are wasting everybodys time, including your own. "Too dangerous" is a direct quote from a WG14 member. Stacksize is not an implementation detail, it often is crucial resource management issue for each individual application, in particular in high performance computing and network service applications. The C1X thread API provides no way you can set it. With respect to timed sleeps: You can simulate wall-clock sleeps with duration-sleeps, but not the other way around. Just that simple fact should make it clear why the API, if it can only offer one kind of timeout, should offer duration-sleeps. NTPD will step your clock up to +/- 3599 seconds. I happen to know: I helped write it.
  - forgotusername 15y ago
    With respect to stack size, I still believe it is an implementation attribute independent of the abstract machine for which C is specified. There is no reason why some undefined external vendor-specific control (e.g. some glibc function) can't be provided by implementations, where required (however as in the example I gave, implementations are possible where such a control would be meaningless - its inclusion would be myopic). Following your argument, complex systems could not be designed without similar controls on memory allocator behaviour ("how can I allocate anything when I don't know if malloc() will introduce syscall latency for a size-32 allocation!?") or environment table size ("how can I possibly execute a subprocess if I can't be certain setenv() will always succeed!?"). The answer to both of course is that you don't design for the standard, you design (and measure) for a particular closed system. I can't see why stack size is any different from the two (of many) examples above. Re: absolute timeouts, the impossibility of emulating intervals reliably with wall-clock is a very good point.
    - phkamp 15y ago
      First: Why should the API for setting stack-size be implementation defined, when a stack mandated to implement the language ? Second: You seem to labour under the misunderstanding that all threads in a program have, and should have the same stack size ? That's simply not true, you can look in Varnish for a good example: We may have 10 "overhead" threads with big stacks and 100.000 worker threads with small stacks. Third: You cannot add "some glibc function" to set the stack-size of a thread you have not yet created, and setting it afterwards may be impossible (if you want it larger) or cause memory fragmentation (if you want it smaller). Fourth: What does malloc(3) have to do with thread stacks ??
      - forgotusername 15y ago
        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, paging, and even where we're 10 years away from "complex system" interconnects powerful enough to provide shared memory across 10k+ computers filling a football field, how much longer would setting the stack size have any practical meaning. It would be like insisting on a frewindtapedrive() library call, because your machine happens to have a tape drive (and aren't files stored on tapes eventually!). Thankfully you weren't on the committee in the 1980s. ;) Nowhere did I suggest all threads should have the same stack size - if anything by the Go example, I suggested they might have no specific 'size' at all. malloc(3) has nothing to do with thread stacks, it was just an example of yet something else that has very implementation-defined behaviour, for which any standardized tuning API would probably come up short.
- pantaloons 15y ago
  Do you mind elaborating on the supposed political quibbles that would prevent a pthreads-like API from being adopted? Are you are implying that vendors of competing API's would oppose anything pthread-like making its way into the standard?
  - kenjackson 15y ago
    If you read the minutes they borrow generously from PThreads. But I can imagine some major vendors, like Microsoft, may say, "We have a threading library where PThreads conflicts with how we do threading. Rather than just taking PThreads as a whole, lets look at these issues and come up with a solution that will work reasonably for everyone." Otherwise you end up with C1x coming out and MS just saying, "This is broken for Windows. Our compiler won't implement it." And just let gcc and Intel pick up the load. Which may be fine for some, but seems counterproductive.
    - phkamp 15y ago
      Yeah, that would have been neat, unfortunately they came up with a solution which will work for nobody...
      - kenjackson 15y ago
        Oddly, that might be the best place to be. If it worked for 50% of the group, there might not be enough votes to get it changed (the 50% can effectively block progress). If it works for nobody, then there's still a chance it can get changed. And then people wonder why I'm not the guy in the room who is generally not excited about standards.
    - wmobit 15y ago
      As if MS will implement C1X. They haven't caught up to the last C standard from 12 years ago
      - saurik 15y ago
        FWIW, Microsoft does not bother with C99 not because they are lazy, but because I honestly never remember C being "the focus" at all: they have been strong backers of C++ since before I started doing Windows development (which itself was back in 1994). They mostly seem to ship a C compiler only because it is often easy to dumb down their C++ compiler to do so (and even then, C++-isms sometimes slip into their C modes). """Thanks for submitting this suggestion. I've resolved it as Won't Fix, because we currently have no plans to implement C99 Core Language features. While we recognize that a few programmers are interested in those features, our finite development and testing resources force us to focus on implementing features that will have the greatest impact on the greatest number of programmers, which means C++.""" -- http://connect.microsoft.com/VisualStudio/feedback/details/531634/support-iso-c99-standard http://connect.microsoft.com/VisualStudio/feedback/details/5... """Unfortunately 1) There are many, many more users of the Microsoft C++ compiler than there are of the C compiler; 2) Anytime we do customers discussion and/or solicit feedback the overwhelming response is that we should focus on C++ (especially at the moment C++-0x); 3) We just don't have the resources to do everything we would like. So while we are slowly improving our C-99 support (and we are active in the C-1x discussions) I can't promise we'll add any of these features.""" -- http://connect.microsoft.com/VisualStudio/feedback/details/526116/c99-support http://connect.microsoft.com/VisualStudio/feedback/details/5...
- SpikeGronim 15y ago
  "stack size is an implementation detail" Thread stack size is an important performance tuning knob. If your app has 100,000 threads you really do care about running out of memory. If you have 10 threads you don't care. You should of course separate the choice of stack size from your application code. Your library still needs to support this. "providing absolute timestamps rather than intervals is important because it prevents drift" I don't know what you mean by "drift". When I put a timeout on a threaded operation (joining, acquiring a mutex, etc.) I am guarding against blocking forever 99% of the time. It is much cleaner to say "this should take no more than 5s" vs. "this should end at XYZ time UTC". Forcing the application to track elapsed time in the face of NTP etc. sucks. Letting the library handle those edge cases is good. It can use a CPU tick counter or similar. "Fears regarding ntpd causing sudden jumps aren't well-founded (ntpd adjusts time very slowly, in sub-second intervals)" What if I am sleeping in sub-second intervals? This goes to the general thrust of PHK's article. He is endorsing K&R C and pthreads because they give you minimal tools that can express a very wide range of programs. Building assumptions about how long people want to sleep for into an extremely widely deployed standard is a mistake.
  - scott_s 15y ago
    Your comments on thread stack size don't contradict the parent's point. Thread stack size is an implementation detail, and it's also an important performance tuning knob. That implies that it should be a knob that belongs to the system, not the C standard.
nyellin 15y ago
As ugly as it is, even the printf()/scanf() format strings could be improved, by offering a sensible plugin mechanism, which the compiler can understand and use to issue warnings. gcc allows this with the 'format' attribute: http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#F...
- phkamp 15y ago
  Yes, but gcc gives you no way to explain to the compiler that %Q takes a struct foobar* as argument, so either you don't use extensions, and have the seatbelts provided by -Wformat, or you use extensions and have no seatbelts at all.
kqr2 15y ago
Link to the current C1X draft which is mentioned in the article: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
angersock 15y ago
Absolutely wonderful quote from the article: My tool for writing Varnish is the C-language which in many ways is unique amongst all of the computer programming languages for having no ambitions. The C language was invented as a portable assembler language, it doesn't do objects and garbage-collection, it does numbers and pointers, just like your CPU. Compared to the high ambitions, then as now, of new programming languages, that was almost ridiculous unambitious. Other people were trying to make their programming languages provably correct, or safe for multiprogramming and quite an effort went into using natural languages as programming languages. But C was written to write programs, not to research computer science and that's exactly what made it useful and popular. This is a great thing to meditate on when trying to understand why the language is still used.
ajross 15y ago
Doesn't seem like the author really thought some of this through: FTA: "The <nostdreturn.h> 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 don't build in C++). The underscore-followed-by-capital convention happened to have been reserved by ISO C90, so that's what they picked. But they allow that this is ugly, so there's a new C1X header file you can include in new C1X code that makes the identifiers look like you expect they should. Obviously old code won't include this header and is insulated from the change. (I guess if you wanted to nit here, having a separate header for each new feature seems dumb to me. Why not a single <c1x.h> or the like?) Compatibility is important, especially for languages like C with staggeringly large bases of mature code. For an example of what happens when you break compatibility in the name of "progress" see Python3, which years on is still not installed by default anywhere, and probably never will be.
- aliguori 15y ago
  This is exactly how stdbool worked in C99 too. _Bool is the actual typename and stdbool.h includes a macro to normalize it.
- 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.
api 15y ago
Nothing good ever came from a committee.
- jemfinch 15y ago
  The constitutional convention of 1787 seems to have done a pretty decent job.
  - phkamp 15y ago
    You mean the job where the first 10 ammendments were necessary after just two years ? :-)
    - derobert 15y ago
      Amendments 1–10 and 27 were products of the same Philadelphia Convention that produced the US Constitution, and were proposed along with it. You could try Wikipedia: http://en.wikipedia.org/wiki/United_States_Bill_of_Rights#Philadelphia_Convention http://en.wikipedia.org/wiki/United_States_Bill_of_Rights#Ph...
      - jshen 15y ago
        Nothing you said negates his argument. Why didn't the committee ad them to the constitution itself when it was passed?
        mbell 15y ago
        They didn't agree about the inclusion of the articles and they wanted to get the constitution signed and proposed to the states for ratification ASAP. Thus those that wanted to get the Bill of Rights in there were promised "it would be coming soon" which appeased them enough to "sign off " on the constitution and those that had some issue with the articles were happy that they weren't initially included. Keep in mind that the "Bill of Rights" originally had 12 articles, only 10 passed initially, 1 finally passed in 1992 and 1 is still outstanding. Also consider that they Philadelphia Convention wasn't some magical aw-inspiring meeting of the minds as it is sometimes made out to be. Only 39 of 55 actually actually signed the constitution and several were so pissed off they just walked out. I'm sure lots of bargaining and negotiation was done and the 12 articles in the Bill of Rights was simply one of the bargaining chips.
deleted 15y ago
[deleted]
comex 15y ago
I don't see this as particularly monstrous - it's reasonably succinct, and in this case a macro implementation does the job just as well as a built-in linked list would, and with much more flexibility. #define VTAILQ_INSERT_BEFORE(listelm, elm, field) do { \ (elm)->field.vtqe_prev = (listelm)->field.vtqe_prev; \ VTAILQ_NEXT((elm), field) = (listelm); \ *(listelm)->field.vtqe_prev = (elm); \ (listelm)->field.vtqe_prev = &VTAILQ_NEXT((elm), field); \ } while (0) (I don't understand why it uses VTAILQ_NEXT((elm), field) instead of what it expands to, (elm)->field.vtqe_next - that would make it more obvious what's going on by paralleling the use of vtqe_prev - but that's the fault of the macro implementation.)
- aliguori 15y ago
  There are many things horrible about it. Its arguments are evaluated many times which is different than what you would expect. The fact that you have to pass field is just plain clumsy. C could benefit tremendously from a parameterized type mechanism.
  - comex 15y ago
    > Its arguments are evaluated many times which is different than what you would expect. True - I would like to see the GCC extension that allows this to be done safely standardized, or improved. > The fact that you have to pass field is just plain clumsy. Sort of. I think the C trick of having linked list pointers inside the struct rather than the usual external wrapper is quite nice: it has good performance (especially in cases with multiple lists, to the extent that Boost has Boost.Intrusive even though it's really gross in C++), and explicitly codifying "struct A is a member of exactly one A-list" makes things feel simpler to me. You could have some kind of magic object in the list head that defines which member field it uses, but I don't know if that's worth the downside of the implementation no longer being trivial (and thus easy to understand). I mean, there are lots of generally ugly points to C macros, but I have yet to see a better option for this kind of stuff that doesn't sacrifice either performance or simplicity - although the macro language itself could certainly be vastly improved.
- 15y ago
dextorious 15y ago
"""The <nostdreturn.h> file according to the standard shall have exactly this content: #define noreturn _Noreturn""" Damn, this standard is way past the point of no return!
scott_s 15y ago
I find this author's characterization of the history of C inaccurate. At the time, C was innovative. And its existence did enable computer science research, because with C, operating systems were finally portable. C itself was a worthwhile contribution to computer science research. Kernighan and Ritchie built upon prior languages, but they were able to distil what levels and kinds of abstraction were needed to implement portable systems programs. Many of the concepts in C existed in C's predecessors, but not in the same form we know them as. It's easy to under-estimate how novel that contribution is because so many of us think in C now. For a history of C from the source, Dennis Ritchie, read this: http://cm.bell-labs.com/who/dmr/chist.html http://cm.bell-labs.com/who/dmr/chist.html
- phkamp 15y ago
  You are rationalizing: C was not "novel", it was pretty much BCPL-light. There also were portable operating systems before UNIX, some of them were written in PL/1 and FORTRAN.
  - scott_s 15y ago
    BCPL had a single data type (the "word") and no structures. Ritchie's paper above covers the innovations in C quite well. See sections "The Problems of B", "Embryonic C" and "Neonatal C".
    - phkamp 15y ago
      And that's where C started out (as 'B'). Adding structures or for that matter pointers to a programming language was not "novel" in 1970. The sheer success of the UNIX and the myth it has built, has many contemporary programmers thinking that everybody else punched cards with flint tools around the bonfire. Even MULTICS, a very innovative and in many ways wonderful OS has gotten a bad rap because of the UNIX-fanboiz cult-building. Dennis, Ken & Brian broke ground, but very few people can correctly say what new ground they broke. (Hint: namespaces, file structure, what a file contains).
latitude 15y ago
Taking 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<int> * foo, * bar; ... append(foo, bar); No need for namespace nesting, default arguments and other ++isms. Just something to replace multi-line macro blocks.
- deleted 15y ago
  [deleted]
- koenigdavidmj 15y ago
  Why not just use C++ without namespace nesting, default arguments, and other ++isms?
jacques_chester 15y ago
The Sydney Opera House is a good example, actually. It's an iconic building. Australia is frequently represented by a picture of the opera house in front the the harbour bridge, possibly with Uluru in the middle distance (it's just outside Sydney, apparently). There's just one problem. It's not a very good opera house. The structural requirements make it impossible to have an ochestral pit for the musicians, and the shape of the building make it very difficult to have all the usual invisible magic that makes opera work smoothly. It's cramped and oddly shaped. The SOH is a perfect example of the triumph of style over substance. The New South Welsh who commissioned it are now facing a $1 billion dollar bill for maintenance over the coming decade. edit: decade, not 5 years.
- phkamp 15y ago
  Funny you should say that: I've always wondered how it worked in the inside. I'm not claiming it is a great opera house, but it is a very good example of using modern building tools. When Utzon died, one of our (Danish) newspapers explained that the required maintenance is now necessary because the architects original plan to cap the "top-seams" with metal was judged too expensive, and some plastic-sealant ("Caulk" ?) were filled into the seam instead, and that has allowed moisture to seep into the construction. I have no idea if this is true or not.
  - jacques_chester 15y ago
    Basically Utzon designed it to look awesome. And it does. As a work of sculpture it's really lovely, and the engineering to make it stand up is difficult and impressive. But as I said, Utzon and his offsiders obviously did not care about the actual purpose of the building, or whether their beautiful design would be at all practical. It's not. Even Frank Gehry, whose work I find to be obnoxious, has managed to design a semi-practical music hall. It's not really architecture, in a Vitruvian sense. It's walk-through sculpture.
    - onan_barbarian 15y ago
      Your remarks are superficially plausible and fit many people's pet theories about architects. The only flaw is that they don't have any relation to the reality of the construction of the actual Sydney Opera House. The internals of the building were not built to Utzon's design; they were redesigned and built after Utzon resigned in 1966.
antirez 15y ago
Well this sounds very messy, the fact you can't change the stack of the thread is a no go for many purposes, just an example, in Redis this must be done because otherwise lzw encryption will cause a stack overflow. Also the ISO C guys completely miss how important is to provide a better libc with data structures and so forth, very very very well designed. About the epic quote of C being a language without ambitions, one of the reasons if D or Go, or other languages are going to hardly replace C is that they are indeed, too ambitious. No one is trying to fixing C with minimal but important changes.
bhurt 15y ago
The C standards committee has been broken since C99 introduced long long, thus silently breaking conforming code. How do you print out a size_t, portably, without losing information? The standard says size_t is an unsigned integer type, but doesn't say way size. However, the C89 spec explicitly stated that there are no integers sizes longer than long- so the conforming way to do this is to explicitly cast the size_t to unsigned long (which, while it may add bits, is guaranteed not to lose them), and print the unsigned long. In an attempt to save all the broken, non-conforming code that assumed that sizeof(int) == sizeof(long), C99 introduced the long long type. And, among other things, allowed size_t to now be unsigned long long. Which meant the conforming C89 code that wants to print out a size_t is now wrong. Worse yet, it's silently broken- because the type cast is explicit, the compiler has to assume it's correct. They added a new way to print size_t's, granted- but this is no help for the legacy code (or code that needs to continue to support C89-only compilers). Of course, the punchline here is that I have yet to see code that assumed sizeof(int) == sizeof(long) that didn't also assume sizeof(void *) == sizeof(int). So all that broken non-conforming code they were trying to save? It still needed to get fixed for 64-bit.
- phkamp 15y ago
  You overlook the %z printf specifier which attempts, but not quite solves the problem, because size_t comes in both a signed (ssize_t) and unsigned (size_t) variant. I usually end up doing printf("%j", (intmax_t)foo);
  - haberman 15y ago
    > because size_t comes in both a signed (ssize_t) and unsigned (size_t) variant. ssize_t is not ISO C. Also, %z is a modifier, not a specifier, so you can print size_t with %zu, or ssize_t with %zd.
  - to3m 15y ago
    Won't "%zu" vs "%zd" do the trick? `z' is a modifier, like `l'. (That said, I've only ever used %zu myself... don't think I've ever used ssize_t. I'm pretty sure it's non-ISO.)
tedunangst 15y ago
The deal with underscores isn't anything new, that was there in C99 for sure. Maybe C89 but I don't know. In any case, I think getting upset about a more than decade old change is a little late and detracts from the main point.
haberman 15y ago
> Now, don't get me wrong: There are lot of ways to improve the C language that would make sense: Bitmaps, defined structure packing (think: communication protocol packets), big/little endian variables (data sharing), sensible handling of linked lists etc. > As ugly as it is, even the printf()/scanf() format strings could be improved, by offering a sensible plugin mechanism, which the compiler can understand and use to issue warnings. > Heck, even a simple basic object facility would be good addition, now that C++ have become this huge bloated monster language. As a C user, I would not want to see any of these things in C. C++ was originally named "C with Classes," and it didn't start out as a monstrosity. Adding "simple" classes to C because C++ is too complicated makes no sense. C++ got complicated because of all of the things that users end up wanting if you walk that path. There's no reason to think that "simple" classes added to C would stay simple. Plugins for printf()/scanf()?? Not even remotely the kind of thing that needs to be in the core language libraries. I don't think defined structure packing would really add much; if the idea is to memcpy() the raw data into your structure, then you're just making the actual data processing part more expensive because the compiler has to store the structure in a sub-optimal way (ie. with non-native endianness). Simple expressions like x.y++ could end up being much more expensive than expected.
- tptacek 15y ago
  For the past 10 years or so, I've been using an alternative to printf() that I lifted out of Hanson's _C Interfaces and Implementations_; in my tree, it's "fmt.c", and includes the family of fmt_<star> functions. They're just string processing code, and so are trivially portable to WinAPI, OS X, Linux, and FreeBSD. This is so much of a win that I don't understand why everyone doesn't do it: * Cross-platform counted/allocated/concatenated string semantics that with no annoying nits from one platform to another. * "Native" support for printing IP addresses (%i), which gets rid of inet_ntoa and ilk, and binary. * A registration system for adding new format codes, which is like being able to create Object#inspect functions in C code. All of which is a roundabout way of saying I agree that we don't need to improve printf/scanf; we need to burn them with fire. I'm going to tend to believe PHK if he thinks explicit structure packing is a win, noting at the same time how unlikely it is that any implementation of it is going to be a performance bottleneck compared with I/O.
caf 15y ago
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.
- phkamp 15y ago
  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.
- Someone 15y ago
  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> 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.
  - caf 15y ago
16s 15y ago
Some of the comments here seem rather harsh and certainly after the fact. There are a lot of knowledgeable, well-intended people on the committee and the standard was ratified by nation states. So it is finished. The time to take issue with it (draft/formal comment period) has passed.
po 15y ago
In case you missed it, this article is part of the 'Poul-Hennings random outbursts' section which is a nice collection of thoughts from a very talented programmer. I have always enjoyed reading these: https://www.varnish-cache.org/docs/trunk/phk/index.html https://www.varnish-cache.org/docs/trunk/phk/index.html
mberning 15y ago
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.
stephencanon 15y ago
Underscore-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.
billrobertson42 15y ago
I wonder if he's looked at golang.
swaits 15y ago
phk is one of my personal heroes!
leoc 15y ago
> Concrete has been known since antiquity, but steel-reinforced concrete and massive numerical calculations of stress-distribution, is the tools that makes the difference between using concrete as a filler material between stones, and as gravity-defying curved but perfectly safe load-bearing wall. Ahem. http://www.google.ie/imgres?imgurl=http://romanconcrete.com/graphics/pantheon_dome.jpg&imgrefurl=http://romanconcrete.com/about.htm&h=900&w=600&sz=91&tbnid=XqbRatDd5am7uM:&tbnh=90&tbnw=60&prev=/search%3Fq%3Dpantheon%2Bdome%26tbm%3Disch%26tbo%3Du&zoom=1&q=pantheon+dome&docid=0KpRyueAMS9WzM&sa=X&ei=_4TxTq2nF5SyhAfK-N2zAQ&ved=0CD0Q9QEwAw&dur=2401 http://www.google.ie/imgres?imgurl=http://romanconcrete.com/...
Aissen 15y ago
For instance, neither pthreads nor C1X-threads offer a "assert I'm holding this mutex locked" facility. I will posit that you cannot successfully develop real-world threaded programs and APIs without that, or without wasting a lot of time debugging silly mistakes. It's funny, Alan Cox thinks the same: https://plus.google.com/111104121194250082892/posts/jWjJ9897skU https://plus.google.com/111104121194250082892/posts/jWjJ9897...
pwaring 15y ago
I'm not a C expert by any means, but is there a need for another new version? Last time I checked, some compilers hadn't even got round to implementing C99 (e.g. Visual C++ doesn't support variable length arrays). Even gcc hasn't got everything: http://gcc.gnu.org/c99status.html http://gcc.gnu.org/c99status.html

283 points by phkamp 15y ago

forgotusername 15y ago

Ignoring complaints about the introduction of a new style of _Identifier, the rant about pthreads seems myopic or just plain wrong. For a start as a vendor-neutral spec (the C standard itself), pthreads would never be adopted as-is. It simply couldn't happen for political reasons (without knowing a thing about the internals of the working group, I'm fairly confident of that). In the meantime it is still useful to define some uniform cross-platform API, even if most organizations continue to use pthreads in legacy code. Assuming "too dangerous" wasn't a direct quote: stack size is an implementation detail, something they probably intentionally left undefined. There are good reasons for this, not least baking assumptions about the underlying machine into the standard has never been a goal. Secondly, with advances like Go's dynamic stacks and its <5 assembly instruction overhead, why would you go and bake a feature akin to a modern sbrk(2) in when sexy alternatives that might see wider adoption are already seeing deployment. As for timed sleeps, providing absolute timestamps rather than intervals is important because it prevents drift: given any function manipulating time, or some timeout, calculating some perceptible end time in the function prologue is much more immune to stupid developers introducing drift (via loops), than expecting the average Joe to account for the latency/contention introduced by system calls, the scheduler, power management, etc. Fears regarding ntpd causing sudden jumps aren't well-founded (ntpd adjusts time very slowly, in sub-second intervals), although the general argument is fair (the sys admin, or other crazy external sources, can cause large time jumps).

phkamp 15y ago
This comment was filled with fail. Pthreads has been the standard for 20 years, either you do better than it does, or you are wasting everybodys time, including your own. "Too dangerous" is a direct quote from a WG14 member. Stacksize is not an implementation detail, it often is crucial resource management issue for each individual application, in particular in high performance computing and network service applications. The C1X thread API provides no way you can set it. With respect to timed sleeps: You can simulate wall-clock sleeps with duration-sleeps, but not the other way around. Just that simple fact should make it clear why the API, if it can only offer one kind of timeout, should offer duration-sleeps. NTPD will step your clock up to +/- 3599 seconds. I happen to know: I helped write it.
- forgotusername 15y ago
  With respect to stack size, I still believe it is an implementation attribute independent of the abstract machine for which C is specified. There is no reason why some undefined external vendor-specific control (e.g. some glibc function) can't be provided by implementations, where required (however as in the example I gave, implementations are possible where such a control would be meaningless - its inclusion would be myopic). Following your argument, complex systems could not be designed without similar controls on memory allocator behaviour ("how can I allocate anything when I don't know if malloc() will introduce syscall latency for a size-32 allocation!?") or environment table size ("how can I possibly execute a subprocess if I can't be certain setenv() will always succeed!?"). The answer to both of course is that you don't design for the standard, you design (and measure) for a particular closed system. I can't see why stack size is any different from the two (of many) examples above. Re: absolute timeouts, the impossibility of emulating intervals reliably with wall-clock is a very good point.
  - phkamp 15y ago
    First: Why should the API for setting stack-size be implementation defined, when a stack mandated to implement the language ? Second: You seem to labour under the misunderstanding that all threads in a program have, and should have the same stack size ? That's simply not true, you can look in Varnish for a good example: We may have 10 "overhead" threads with big stacks and 100.000 worker threads with small stacks. Third: You cannot add "some glibc function" to set the stack-size of a thread you have not yet created, and setting it afterwards may be impossible (if you want it larger) or cause memory fragmentation (if you want it smaller). Fourth: What does malloc(3) have to do with thread stacks ??
    - forgotusername 15y ago
      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, paging, and even where we're 10 years away from "complex system" interconnects powerful enough to provide shared memory across 10k+ computers filling a football field, how much longer would setting the stack size have any practical meaning. It would be like insisting on a frewindtapedrive() library call, because your machine happens to have a tape drive (and aren't files stored on tapes eventually!). Thankfully you weren't on the committee in the 1980s. ;) Nowhere did I suggest all threads should have the same stack size - if anything by the Go example, I suggested they might have no specific 'size' at all. malloc(3) has nothing to do with thread stacks, it was just an example of yet something else that has very implementation-defined behaviour, for which any standardized tuning API would probably come up short.
pantaloons 15y ago
Do you mind elaborating on the supposed political quibbles that would prevent a pthreads-like API from being adopted? Are you are implying that vendors of competing API's would oppose anything pthread-like making its way into the standard?
- kenjackson 15y ago
  If you read the minutes they borrow generously from PThreads. But I can imagine some major vendors, like Microsoft, may say, "We have a threading library where PThreads conflicts with how we do threading. Rather than just taking PThreads as a whole, lets look at these issues and come up with a solution that will work reasonably for everyone." Otherwise you end up with C1x coming out and MS just saying, "This is broken for Windows. Our compiler won't implement it." And just let gcc and Intel pick up the load. Which may be fine for some, but seems counterproductive.
  - phkamp 15y ago
    Yeah, that would have been neat, unfortunately they came up with a solution which will work for nobody...
    - kenjackson 15y ago
      Oddly, that might be the best place to be. If it worked for 50% of the group, there might not be enough votes to get it changed (the 50% can effectively block progress). If it works for nobody, then there's still a chance it can get changed. And then people wonder why I'm not the guy in the room who is generally not excited about standards.
  - wmobit 15y ago
    As if MS will implement C1X. They haven't caught up to the last C standard from 12 years ago
    - saurik 15y ago
      FWIW, Microsoft does not bother with C99 not because they are lazy, but because I honestly never remember C being "the focus" at all: they have been strong backers of C++ since before I started doing Windows development (which itself was back in 1994). They mostly seem to ship a C compiler only because it is often easy to dumb down their C++ compiler to do so (and even then, C++-isms sometimes slip into their C modes). """Thanks for submitting this suggestion. I've resolved it as Won't Fix, because we currently have no plans to implement C99 Core Language features. While we recognize that a few programmers are interested in those features, our finite development and testing resources force us to focus on implementing features that will have the greatest impact on the greatest number of programmers, which means C++.""" -- http://connect.microsoft.com/VisualStudio/feedback/details/531634/support-iso-c99-standard http://connect.microsoft.com/VisualStudio/feedback/details/5... """Unfortunately 1) There are many, many more users of the Microsoft C++ compiler than there are of the C compiler; 2) Anytime we do customers discussion and/or solicit feedback the overwhelming response is that we should focus on C++ (especially at the moment C++-0x); 3) We just don't have the resources to do everything we would like. So while we are slowly improving our C-99 support (and we are active in the C-1x discussions) I can't promise we'll add any of these features.""" -- http://connect.microsoft.com/VisualStudio/feedback/details/526116/c99-support http://connect.microsoft.com/VisualStudio/feedback/details/5...
SpikeGronim 15y ago
"stack size is an implementation detail" Thread stack size is an important performance tuning knob. If your app has 100,000 threads you really do care about running out of memory. If you have 10 threads you don't care. You should of course separate the choice of stack size from your application code. Your library still needs to support this. "providing absolute timestamps rather than intervals is important because it prevents drift" I don't know what you mean by "drift". When I put a timeout on a threaded operation (joining, acquiring a mutex, etc.) I am guarding against blocking forever 99% of the time. It is much cleaner to say "this should take no more than 5s" vs. "this should end at XYZ time UTC". Forcing the application to track elapsed time in the face of NTP etc. sucks. Letting the library handle those edge cases is good. It can use a CPU tick counter or similar. "Fears regarding ntpd causing sudden jumps aren't well-founded (ntpd adjusts time very slowly, in sub-second intervals)" What if I am sleeping in sub-second intervals? This goes to the general thrust of PHK's article. He is endorsing K&R C and pthreads because they give you minimal tools that can express a very wide range of programs. Building assumptions about how long people want to sleep for into an extremely widely deployed standard is a mistake.
- scott_s 15y ago
  Your comments on thread stack size don't contradict the parent's point. Thread stack size is an implementation detail, and it's also an important performance tuning knob. That implies that it should be a knob that belongs to the system, not the C standard.

nyellin 15y ago

As ugly as it is, even the printf()/scanf() format strings could be improved, by offering a sensible plugin mechanism, which the compiler can understand and use to issue warnings. gcc allows this with the 'format' attribute: http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#F...

phkamp 15y ago
Yes, but gcc gives you no way to explain to the compiler that %Q takes a struct foobar* as argument, so either you don't use extensions, and have the seatbelts provided by -Wformat, or you use extensions and have no seatbelts at all.

kqr2 15y ago

Link to the current C1X draft which is mentioned in the article: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

angersock 15y ago

Absolutely wonderful quote from the article: My tool for writing Varnish is the C-language which in many ways is unique amongst all of the computer programming languages for having no ambitions. The C language was invented as a portable assembler language, it doesn't do objects and garbage-collection, it does numbers and pointers, just like your CPU. Compared to the high ambitions, then as now, of new programming languages, that was almost ridiculous unambitious. Other people were trying to make their programming languages provably correct, or safe for multiprogramming and quite an effort went into using natural languages as programming languages. But C was written to write programs, not to research computer science and that's exactly what made it useful and popular. This is a great thing to meditate on when trying to understand why the language is still used.

ajross 15y ago

Doesn't seem like the author really thought some of this through: FTA: "The <nostdreturn.h> 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 don't build in C++). The underscore-followed-by-capital convention happened to have been reserved by ISO C90, so that's what they picked. But they allow that this is ugly, so there's a new C1X header file you can include in new C1X code that makes the identifiers look like you expect they should. Obviously old code won't include this header and is insulated from the change. (I guess if you wanted to nit here, having a separate header for each new feature seems dumb to me. Why not a single <c1x.h> or the like?) Compatibility is important, especially for languages like C with staggeringly large bases of mature code. For an example of what happens when you break compatibility in the name of "progress" see Python3, which years on is still not installed by default anywhere, and probably never will be.

aliguori 15y ago
This is exactly how stdbool worked in C99 too. _Bool is the actual typename and stdbool.h includes a macro to normalize it.
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.

api 15y ago

Nothing good ever came from a committee.

jemfinch 15y ago
The constitutional convention of 1787 seems to have done a pretty decent job.
- phkamp 15y ago
  You mean the job where the first 10 ammendments were necessary after just two years ? :-)
  - derobert 15y ago
    Amendments 1–10 and 27 were products of the same Philadelphia Convention that produced the US Constitution, and were proposed along with it. You could try Wikipedia: http://en.wikipedia.org/wiki/United_States_Bill_of_Rights#Philadelphia_Convention http://en.wikipedia.org/wiki/United_States_Bill_of_Rights#Ph...
    - jshen 15y ago
      Nothing you said negates his argument. Why didn't the committee ad them to the constitution itself when it was passed?
      - mbell 15y ago
        They didn't agree about the inclusion of the articles and they wanted to get the constitution signed and proposed to the states for ratification ASAP. Thus those that wanted to get the Bill of Rights in there were promised "it would be coming soon" which appeased them enough to "sign off " on the constitution and those that had some issue with the articles were happy that they weren't initially included. Keep in mind that the "Bill of Rights" originally had 12 articles, only 10 passed initially, 1 finally passed in 1992 and 1 is still outstanding. Also consider that they Philadelphia Convention wasn't some magical aw-inspiring meeting of the minds as it is sometimes made out to be. Only 39 of 55 actually actually signed the constitution and several were so pissed off they just walked out. I'm sure lots of bargaining and negotiation was done and the 12 articles in the Bill of Rights was simply one of the bargaining chips.

deleted 15y ago

[deleted]

comex 15y ago

I don't see this as particularly monstrous - it's reasonably succinct, and in this case a macro implementation does the job just as well as a built-in linked list would, and with much more flexibility. #define VTAILQ_INSERT_BEFORE(listelm, elm, field) do { \ (elm)->field.vtqe_prev = (listelm)->field.vtqe_prev; \ VTAILQ_NEXT((elm), field) = (listelm); \ *(listelm)->field.vtqe_prev = (elm); \ (listelm)->field.vtqe_prev = &VTAILQ_NEXT((elm), field); \ } while (0) (I don't understand why it uses VTAILQ_NEXT((elm), field) instead of what it expands to, (elm)->field.vtqe_next - that would make it more obvious what's going on by paralleling the use of vtqe_prev - but that's the fault of the macro implementation.)

aliguori 15y ago
There are many things horrible about it. Its arguments are evaluated many times which is different than what you would expect. The fact that you have to pass field is just plain clumsy. C could benefit tremendously from a parameterized type mechanism.
- comex 15y ago
  > Its arguments are evaluated many times which is different than what you would expect. True - I would like to see the GCC extension that allows this to be done safely standardized, or improved. > The fact that you have to pass field is just plain clumsy. Sort of. I think the C trick of having linked list pointers inside the struct rather than the usual external wrapper is quite nice: it has good performance (especially in cases with multiple lists, to the extent that Boost has Boost.Intrusive even though it's really gross in C++), and explicitly codifying "struct A is a member of exactly one A-list" makes things feel simpler to me. You could have some kind of magic object in the list head that defines which member field it uses, but I don't know if that's worth the downside of the implementation no longer being trivial (and thus easy to understand). I mean, there are lots of generally ugly points to C macros, but I have yet to see a better option for this kind of stuff that doesn't sacrifice either performance or simplicity - although the macro language itself could certainly be vastly improved.
15y ago

dextorious 15y ago

"""The <nostdreturn.h> file according to the standard shall have exactly this content: #define noreturn _Noreturn""" Damn, this standard is way past the point of no return!

scott_s 15y ago

I find this author's characterization of the history of C inaccurate. At the time, C was innovative. And its existence did enable computer science research, because with C, operating systems were finally portable. C itself was a worthwhile contribution to computer science research. Kernighan and Ritchie built upon prior languages, but they were able to distil what levels and kinds of abstraction were needed to implement portable systems programs. Many of the concepts in C existed in C's predecessors, but not in the same form we know them as. It's easy to under-estimate how novel that contribution is because so many of us think in C now. For a history of C from the source, Dennis Ritchie, read this: http://cm.bell-labs.com/who/dmr/chist.html http://cm.bell-labs.com/who/dmr/chist.html

phkamp 15y ago
You are rationalizing: C was not "novel", it was pretty much BCPL-light. There also were portable operating systems before UNIX, some of them were written in PL/1 and FORTRAN.
- scott_s 15y ago
  BCPL had a single data type (the "word") and no structures. Ritchie's paper above covers the innovations in C quite well. See sections "The Problems of B", "Embryonic C" and "Neonatal C".
  - phkamp 15y ago
    And that's where C started out (as 'B'). Adding structures or for that matter pointers to a programming language was not "novel" in 1970. The sheer success of the UNIX and the myth it has built, has many contemporary programmers thinking that everybody else punched cards with flint tools around the bonfire. Even MULTICS, a very innovative and in many ways wonderful OS has gotten a bad rap because of the UNIX-fanboiz cult-building. Dennis, Ken & Brian broke ground, but very few people can correctly say what new ground they broke. (Hint: namespaces, file structure, what a file contains).

latitude 15y ago

Taking 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<int> * foo, * bar; ... append(foo, bar); No need for namespace nesting, default arguments and other ++isms. Just something to replace multi-line macro blocks.

deleted 15y ago
[deleted]
koenigdavidmj 15y ago
Why not just use C++ without namespace nesting, default arguments, and other ++isms?

jacques_chester 15y ago

The Sydney Opera House is a good example, actually. It's an iconic building. Australia is frequently represented by a picture of the opera house in front the the harbour bridge, possibly with Uluru in the middle distance (it's just outside Sydney, apparently). There's just one problem. It's not a very good opera house. The structural requirements make it impossible to have an ochestral pit for the musicians, and the shape of the building make it very difficult to have all the usual invisible magic that makes opera work smoothly. It's cramped and oddly shaped. The SOH is a perfect example of the triumph of style over substance. The New South Welsh who commissioned it are now facing a $1 billion dollar bill for maintenance over the coming decade. edit: decade, not 5 years.

phkamp 15y ago
Funny you should say that: I've always wondered how it worked in the inside. I'm not claiming it is a great opera house, but it is a very good example of using modern building tools. When Utzon died, one of our (Danish) newspapers explained that the required maintenance is now necessary because the architects original plan to cap the "top-seams" with metal was judged too expensive, and some plastic-sealant ("Caulk" ?) were filled into the seam instead, and that has allowed moisture to seep into the construction. I have no idea if this is true or not.
- jacques_chester 15y ago
  Basically Utzon designed it to look awesome. And it does. As a work of sculpture it's really lovely, and the engineering to make it stand up is difficult and impressive. But as I said, Utzon and his offsiders obviously did not care about the actual purpose of the building, or whether their beautiful design would be at all practical. It's not. Even Frank Gehry, whose work I find to be obnoxious, has managed to design a semi-practical music hall. It's not really architecture, in a Vitruvian sense. It's walk-through sculpture.
  - onan_barbarian 15y ago
    Your remarks are superficially plausible and fit many people's pet theories about architects. The only flaw is that they don't have any relation to the reality of the construction of the actual Sydney Opera House. The internals of the building were not built to Utzon's design; they were redesigned and built after Utzon resigned in 1966.

antirez 15y ago

Well this sounds very messy, the fact you can't change the stack of the thread is a no go for many purposes, just an example, in Redis this must be done because otherwise lzw encryption will cause a stack overflow. Also the ISO C guys completely miss how important is to provide a better libc with data structures and so forth, very very very well designed. About the epic quote of C being a language without ambitions, one of the reasons if D or Go, or other languages are going to hardly replace C is that they are indeed, too ambitious. No one is trying to fixing C with minimal but important changes.

bhurt 15y ago

The C standards committee has been broken since C99 introduced long long, thus silently breaking conforming code. How do you print out a size_t, portably, without losing information? The standard says size_t is an unsigned integer type, but doesn't say way size. However, the C89 spec explicitly stated that there are no integers sizes longer than long- so the conforming way to do this is to explicitly cast the size_t to unsigned long (which, while it may add bits, is guaranteed not to lose them), and print the unsigned long. In an attempt to save all the broken, non-conforming code that assumed that sizeof(int) == sizeof(long), C99 introduced the long long type. And, among other things, allowed size_t to now be unsigned long long. Which meant the conforming C89 code that wants to print out a size_t is now wrong. Worse yet, it's silently broken- because the type cast is explicit, the compiler has to assume it's correct. They added a new way to print size_t's, granted- but this is no help for the legacy code (or code that needs to continue to support C89-only compilers). Of course, the punchline here is that I have yet to see code that assumed sizeof(int) == sizeof(long) that didn't also assume sizeof(void *) == sizeof(int). So all that broken non-conforming code they were trying to save? It still needed to get fixed for 64-bit.

phkamp 15y ago
You overlook the %z printf specifier which attempts, but not quite solves the problem, because size_t comes in both a signed (ssize_t) and unsigned (size_t) variant. I usually end up doing printf("%j", (intmax_t)foo);
- haberman 15y ago
  > because size_t comes in both a signed (ssize_t) and unsigned (size_t) variant. ssize_t is not ISO C. Also, %z is a modifier, not a specifier, so you can print size_t with %zu, or ssize_t with %zd.
- to3m 15y ago
  Won't "%zu" vs "%zd" do the trick? `z' is a modifier, like `l'. (That said, I've only ever used %zu myself... don't think I've ever used ssize_t. I'm pretty sure it's non-ISO.)

tedunangst 15y ago

The deal with underscores isn't anything new, that was there in C99 for sure. Maybe C89 but I don't know. In any case, I think getting upset about a more than decade old change is a little late and detracts from the main point.

haberman 15y ago

> Now, don't get me wrong: There are lot of ways to improve the C language that would make sense: Bitmaps, defined structure packing (think: communication protocol packets), big/little endian variables (data sharing), sensible handling of linked lists etc. > As ugly as it is, even the printf()/scanf() format strings could be improved, by offering a sensible plugin mechanism, which the compiler can understand and use to issue warnings. > Heck, even a simple basic object facility would be good addition, now that C++ have become this huge bloated monster language. As a C user, I would not want to see any of these things in C. C++ was originally named "C with Classes," and it didn't start out as a monstrosity. Adding "simple" classes to C because C++ is too complicated makes no sense. C++ got complicated because of all of the things that users end up wanting if you walk that path. There's no reason to think that "simple" classes added to C would stay simple. Plugins for printf()/scanf()?? Not even remotely the kind of thing that needs to be in the core language libraries. I don't think defined structure packing would really add much; if the idea is to memcpy() the raw data into your structure, then you're just making the actual data processing part more expensive because the compiler has to store the structure in a sub-optimal way (ie. with non-native endianness). Simple expressions like x.y++ could end up being much more expensive than expected.

tptacek 15y ago
For the past 10 years or so, I've been using an alternative to printf() that I lifted out of Hanson's _C Interfaces and Implementations_; in my tree, it's "fmt.c", and includes the family of fmt_<star> functions. They're just string processing code, and so are trivially portable to WinAPI, OS X, Linux, and FreeBSD. This is so much of a win that I don't understand why everyone doesn't do it: * Cross-platform counted/allocated/concatenated string semantics that with no annoying nits from one platform to another. * "Native" support for printing IP addresses (%i), which gets rid of inet_ntoa and ilk, and binary. * A registration system for adding new format codes, which is like being able to create Object#inspect functions in C code. All of which is a roundabout way of saying I agree that we don't need to improve printf/scanf; we need to burn them with fire. I'm going to tend to believe PHK if he thinks explicit structure packing is a win, noting at the same time how unlikely it is that any implementation of it is going to be a performance bottleneck compared with I/O.

caf 15y ago

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.

phkamp 15y ago
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.
Someone 15y ago
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> 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.
- caf 15y ago

16s 15y ago

Some of the comments here seem rather harsh and certainly after the fact. There are a lot of knowledgeable, well-intended people on the committee and the standard was ratified by nation states. So it is finished. The time to take issue with it (draft/formal comment period) has passed.

po 15y ago

In case you missed it, this article is part of the 'Poul-Hennings random outbursts' section which is a nice collection of thoughts from a very talented programmer. I have always enjoyed reading these: https://www.varnish-cache.org/docs/trunk/phk/index.html https://www.varnish-cache.org/docs/trunk/phk/index.html

mberning 15y ago

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.

stephencanon 15y ago

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

billrobertson42 15y ago

I wonder if he's looked at golang.

swaits 15y ago

phk is one of my personal heroes!

leoc 15y ago

> Concrete has been known since antiquity, but steel-reinforced concrete and massive numerical calculations of stress-distribution, is the tools that makes the difference between using concrete as a filler material between stones, and as gravity-defying curved but perfectly safe load-bearing wall. Ahem. http://www.google.ie/imgres?imgurl=http://romanconcrete.com/graphics/pantheon_dome.jpg&imgrefurl=http://romanconcrete.com/about.htm&h=900&w=600&sz=91&tbnid=XqbRatDd5am7uM:&tbnh=90&tbnw=60&prev=/search%3Fq%3Dpantheon%2Bdome%26tbm%3Disch%26tbo%3Du&zoom=1&q=pantheon+dome&docid=0KpRyueAMS9WzM&sa=X&ei=_4TxTq2nF5SyhAfK-N2zAQ&ved=0CD0Q9QEwAw&dur=2401 http://www.google.ie/imgres?imgurl=http://romanconcrete.com/...

Aissen 15y ago

For instance, neither pthreads nor C1X-threads offer a "assert I'm holding this mutex locked" facility. I will posit that you cannot successfully develop real-world threaded programs and APIs without that, or without wasting a lot of time debugging silly mistakes. It's funny, Alan Cox thinks the same: https://plus.google.com/111104121194250082892/posts/jWjJ9897skU https://plus.google.com/111104121194250082892/posts/jWjJ9897...

pwaring 15y ago

I'm not a C expert by any means, but is there a need for another new version? Last time I checked, some compilers hadn't even got round to implementing C99 (e.g. Visual C++ doesn't support variable length arrays). Even gcc hasn't got everything: http://gcc.gnu.org/c99status.html http://gcc.gnu.org/c99status.html