ISO C is increasingly moronic

https://www.varnish-cache.org/docs/trunk/phk/thetoolsweworkwith.html

by phkamp • 15 years ago

283 167 15 years 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.

forgotusername4• 15 years 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).

phkamp19• 15 years 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.

forgotusername4• 15 years 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.

pantaloons• 15 years 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?

kenjackson2• 15 years 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.

SpikeGronim• 15 years 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_s8• 15 years 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• 15 years 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#F...

phkamp19• 15 years 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• 15 years 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

angersock3• 15 years 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.

ajross4• 15 years 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.

aliguori6• 15 years ago

This is exactly how stdbool worked in C99 too. _Bool is the actual typename and stdbool.h includes a macro to normalize it.

phkamp19• 15 years ago

First of all: You're wrong, the compatibility is the other way around: The old code will have to include <stdnoreturn.h> if they used the "noreturn" compiler-specific keyword, while waiting for the glacial ISO WG progress.

Second: There are two kinds of compatibility: Forwards compatbility and backwards compatibilty.

There is a finite number of existing programs whereas the number of future programs to be written is unbounded and very likely to be much higher over time.

Therefore forwards compatibility is always, by definition, more important than backwards compatibility, and you should never penalize future programs and programmers for the misdeeds and sloppines of the past programs and programmers.

Besides: I have yet to see a compiler that didn't have flags to make it compile to a slew of older dialects of C, so if C1X happens to break your old code, you set such an option, or you fix your source code.

There, fixed it for you.

The "Backwards compatibility, no matter the cost" mentaility is costing us dearly in the quality of the tools we have work with in the future, while providing us no relevant new benefits.

Crap like <stdnoreturn.h> is just pointless ornamentation, cluttering our source code.

scott_s8• 15 years ago

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

aliguori6• 15 years ago

I don't agree with your assertion that backwards compatibility isn't important, but I would like to point out that the very fact that C compilers allow you to use identifiers that are in the form _Word means that they are breaking backwards compatibility by introducing new keywords.

Many of the libraries on a typical Linux system (anything glib/gtk based, libxml2, etc.) use _Word extensively.

angersock3• 15 years ago

Ha. You're adorable.

While I do support the general "hey, let's fix old code and not be slaves to backwards compatibility", the fact of the matter is that legacy code / libraries / whatever in C aren't merely misdeeds/sloppiness--you might as well complain about having to use the same molecules of metal in your tools that our ancestors did building Rome instead of making your own from subatomic particles.

There is a finite number of existing programs whereas the number of future programs to be written is unbounded and very likely to be much higher over time.

But in the future, it's all Javascript/Ruby/CSS/HTML5! Why worry about writing more C code? ;)

kmm• 15 years ago

No, you're wrong. The old code will have something like

typedef char bool

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

teyc4• 15 years ago

  The "Backwards compatibility, no matter the cost" 
  mentaility is costing us dearly in the quality of
  the tools we have work with in the future, while
  providing us no relevant new benefits.

That is only because you don't have a vested interest in old code bases. (Taking a rough guess here: you're under 30?)

chipsy• 15 years ago

Maybe the ISO committee is conspiring to destroy C with mediocrity so that a shiny new systems language can take its place, correcting C's deeper warts in the process.

That would be nice, if only I believed it.

comex4• 15 years ago

> The old code will have to include <stdnoreturn.h> if they used the "noreturn" compiler-specific keyword, while waiting for the glacial ISO WG progress.

Huh? stdnoreturn.h only makes sense with the new _Noreturn keyword. The old code can keep using __attribute__((noreturn)) or (if it was portable code) nothing at all, without including any headers.

> Crap like <stdnoreturn.h> is just pointless ornamentation, cluttering our source code.

I think C's "add seemingly randomly named include files to the top of your code to use different parts of the standard library" is pointless, and I'd like to see the whole standard library included by default (using some yet-to-be-invented more flexible PCH magic to ensure it doesn't slow down compilation). But in lieu of that, it's hardly a big jump from library to syntax - and if keeping backward compatibility isn't hard, why not do it?

breadbox2• 15 years ago

Indeed. As a general rule, if you think the ISO committee has done something pointlessly moronic, there's a pretty good chance that there's more going on than you know about.

reacweb2• 15 years ago

breakage of pre-existing code is really a poor excuse for such craziness. Seriously do you prefer an error message during compilation that is easy to understand and not so difficult to fix or a language so tricky that nobody can read the huge reference manual. I fully agree with the author. Seek and hang the culprits !

ajross4• 15 years ago

That's not what C1X is for. It's a straightforward evolution of ISO C99 which adds features without breaking anything. If you want a similar low level language which is not compatible with legacy C you don't have to look far: history is littered with their carcasses.

alexis-d• 15 years ago

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

Python 3 is the default on some Linux distros (e.g. Arch Linux)...

gcr• 15 years ago

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.

ajross4• 15 years ago

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?

SomeOtherGuy• 15 years ago

>Doesn't seem like the author really thought some of this through

Yeah, he says the same thing at the bottom:

>Poul-Henning

I guess it would be nice if he warned you up front, but at least he does include the warning.

api• 15 years ago

Nothing good ever came from a committee.

jemfinch• 15 years ago

The constitutional convention of 1787 seems to have done a pretty decent job.

phkamp19• 15 years ago

You mean the job where the first 10 ammendments were necessary after just two years ? :-)

aliguori6• 15 years ago

Minus the 3/5ths compromise of course...

http://en.wikipedia.org/wiki/Three-Fifths_Compromise

Committees are all about compromise and compromises are usually a worse solution in everyone's eyes. I'm not saying C14 threads are as bad as slavery, but they are a compromise that I'm sure no one will prefer to their native thread library.

I'm a bit surprise that ISO is even attempting to do generic threads. Who is this really a problem for? We have oodles of libraries that provide cross platform thread libraries. I don't see why we need the C standard to specify one.

zb• 15 years ago

Actually I think C emerged from its original ANSI standardisation process in much better shape than when it went it. You don't see too much K&R C being written these days for good reason.

phkamp19• 15 years ago

You're probably right about that, ANSI did a couple of good things, but I'm not sure I think they came out in the black in the end.

ISO on the other hand, seems like a total disaster.

aidenn0• 15 years ago

Most of the K&R isms were already gone before C89, ANSI just standardized those. I learned C from a pre-ANSI book and it definitely wasn't that K&Rish

comex4• 15 years 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.)

aliguori6• 15 years 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.

comex4• 15 years 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.

tkahn62• 15 years ago

Can anyone explain why this needs to be a macro? What does this get you over a plain function?

jedbrown2• 15 years ago

It's intended to be used with lists with different payloads, all "inheriting" fields from a standard list structure (usually another macro expansion).

saurik2• 15 years ago

The "field" argument cannot be passed as an argument to a normal function in C. FWIW, you could pass it as an argument in C++ (which supports pointers to members), but in C++ there are numerous better ways of implementing this.

tptacek6• 15 years ago

The idiomatic way you'd express a generic tailq in C with functions is with void-stars, which cost 4-8 bytes and incur the costs of indirecting through another memory address and, probably, of allocating lots of fiddly little structs at random times.

The macro version expresses the same generalized logic but embeds the link pointers in the structure you're queueing.

dextorious3• 15 years 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_s8• 15 years 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

phkamp19• 15 years 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_s8• 15 years 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".

latitude• 15 years 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.

koenigdavidmj• 15 years ago

Why not just use C++ without namespace nesting, default arguments, and other ++isms?

jacques_chester4• 15 years 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.

phkamp19• 15 years 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_chester4• 15 years 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.

antirez• 15 years 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• 15 years 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.

phkamp19• 15 years 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);

to3m2• 15 years 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.)

haberman5• 15 years 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.

tedunangst3• 15 years 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.

haberman5• 15 years 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.

tptacek6• 15 years 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.

haberman5• 15 years ago

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

I've spent a lot of my life writing parsers for various network formats, and one thing that I can say with authority is that at both my current company (Google) and at my previous company (Amazon) the CPU cost of parsing bytes off the network was noticeable enough to spend significant resources optimizing.

I haven't done benchmarks myself about eg. bitvectors, but I'm pretty sure I've heard that the performance of packed bitvectors is noticeably slower than non-packed. I also think the cost would be comparable to 64-bit math on 32-bit processors (ie. an overhead of 3-5 instructions per operation), which is a non-trivial cost.

mark_h• 15 years ago

+1 for Hanson's book in general (which I think I might have initially read on your recommendation anyway!). I don't do a huge amount of C programming these days, but it was a huge eye-opener.

jetsnoc• 15 years ago

Thank you for the excellent book suggestion. I've only been writing in C for a few years now. I've been grappling for a better way to manage and abstract some of our utilities in our poorly written legacy application. Every linked list is custom, and every array malloced and freed on the fly -- it's so fragile that sometimes I feel paralyzed. It's been terribly wrong for a long time but I've personally lacked the experience and formal training to make it better through libraries and wrappers. About a year ago I picked up "Mastering Algorithms with C" and it was very helpful at teaching complex algorithms but never really helped me abstract our code base in to something portable and reusable.

I'm certain this book will help me tremendously. :P

phkamp19• 15 years ago

The reason why struct packing would be a win is probably not performance, but code readability and less bugs.

Making be/le/native conversion a job for the programmer is not only error-prone and a waste of time.

The compiler could safely optimize the byte-swizzles away on non-arithmetic operations, whereas most programmers tend to covert everything before they start working on it.

adgar3• 15 years ago

> 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 being misused in a way that results in poor performance is if you read data into an explicitly-packed struct and then pass a reference to it around everywhere, reading from it willy-nilly instead of extracting the values once.

haberman5• 15 years ago

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 convinced that writing the actual parsing code is for the best.

techdmn• 15 years ago

Sometimes I wonder if C++ deserves more credit for /saving/ C, by absorbing all the crap that might otherwise have been added. :)

jronkone• 15 years ago

> Plugins for printf()/scanf()?? Not even remotely the kind of thing that needs to be in the core language libraries.

Where then? As far as I can tell, there's no sensible way to extend the functionality of printf()/scanf(), and compilers special-case their format-strings.

caf3• 15 years 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.

phkamp19• 15 years 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• 15 years 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>

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

caf3• 15 years ago

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

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

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

16s• 15 years 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• 15 years 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

mberning• 15 years 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• 15 years 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• 15 years ago

I wonder if he's looked at golang.

swaits• 15 years ago

phk is one of my personal heroes!

leoc• 15 years 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/...

Aissen• 15 years 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/jWjJ9897...

pwaring• 15 years 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

ISO C is increasingly moronic

Related Stories