As someone who loves and enjoys writing Plan 9 c, all I can say is "standard c", whatever that means these days, is a mess. Too many things to name ranging from the only two oss compilers being bloated monsters, post c99 additions being pointless, in-line asm ruining portability*, and POSIX can die in a fire (along with typewriter terminals.)
I have a friend who is currently on the C committee and is likely going to leave because of all the bad ideas which have both been implemented and going to be implemented.
* No, spamming a million ugly #ifdefs all over the source files is gross and hard to read. Split up the code dammit.
A library function written in what? Atomics also come along with memory ordering which isn’t otherwise expressible in the language, as in, there was no standard way to do a “load acquire” before, for example.
> You can do it all with library functions that just take regular int* (and so on).
It's not just about atomics, but you might still find Hans Boehm's 2005 paper "Threads Cannot Be Implemented As a Library" [0] interesting. It describes (among other things) correctness and performance issues that can arise if the compiler and/or language don't know about thread/atomic semantics.
Yeah, it's all fun and games until you realize that you compiler may invent writes in order to eliminate a branch. Which is rather nonsensical, when you stop to think about it — surely an additional store to global can't be faster than a mispredicted branch?
Branch mispredictions on deep machines can be devastating, whereas a store can hit in your L1. Storing can definitely be faster than a mispredicted branch if you think you'll hit in your L1/L2
It seems like the guy analyzes how Pthreads are formally defined and declares that "Threads cannot be implemented as a library". Maybe if the title was changed to "Pthreads cannot be implemented as a library" it'd be true. Pthreads are fucking abysmal.
> We explicitly do not address the less frequently used environments in which multiple concurrent threads communicate communicate primarily through message passing, such as C programs communicating only through the MPI[34] library, or Erlang[11] or Concurrent ML[28] programs.
Nothing to do with pthreads. As long as you want to use shared memory to communicate with concurrent processes, you need a memory model with compiler support. Even if you exclusively use mutexes.
> As long as you want to use shared memory to communicate with concurrent processes
That's something pthreads do and CSP doesn't.
> you need a memory model with compiler support. Even if you exclusively use mutexes.
If you use CSP you can effectively eliminate shared memory in user space and you don't have to handle this with the compiler. Then you can say "here's a way to communicate between processes in user space, the runtime/kernel handles the shit underneath. If you want to do it some other way we can't guarantee it'll work."
Not sure what CSP is supposed to mean, but if you eliminate shared memory and have the kernel copy data between threads, you're leaving a ton of performance on the table.
> but if you eliminate shared memory and have the kernel copy data between threads, you're leaving a ton of performance on the table.
If that's your bottleneck then you've either already solved every other class of performance issue with your program or you're working in a fantasy environment-- you're probably not hacking on FFmpeg right now. 90% of performance is I/O bound, whether it be the disk, the network or whatever. You can easily ascertain the correctness of a CSP system, because it's just message passing and inherently synchronous. Not so much with shared memory. It's a tradeoff. Unix pipes are also pretty goddamn fast, like, this is an issue people have spent time squeezing as much performance as possible out of. Google uses Go for all of their important backend shit. The entire internet is a giant message passing system.
> 90% of performance is I/O bound, whether it be the disk, the network or whatever
funny you say that, because to take advantage of the monstrous bandwidth offered by modern ethernet, OS bypass with the card DMAing directly in your process cache is a must. That reintroduces all the "fun" shared memory ordering issues, except trickier (you are talking with a PCI device, not just another core) and buggier.
Re disk, I'm sure someone will revive optane at some point, and we will be back with memory model issues in our disk I/O path.
The reality is that a programming language that claims to be usable for system programming must be able to deal with shared memory and provide a concurrent memory model.
> to take advantage of the monstrous bandwidth offered by modern ethernet, OS bypass with the card DMAing directly in your process cache is a must.
Architecture problem. Do your programs normally saturate a 40 gig network pipe?
> The reality is that a programming language that claims to be usable for system programming must be able to deal with shared memory and provide a concurrent memory model.
You can boot up a Plan 9 kernel and tell me if it works or not.
For better or worse, our current hardware architectures present a shared memory interface for intercore communication. So if you want a non-toy CSP programing language you have to implement with a programming language that support shared memory concurrency (for the OS at the very least).
And of course any sufficiently complicated message passing program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of shared memory and coherency[1].
Compilers have, for several decades now, stopped viewing optimization in terms of optimizing the instructions of a function and instead viewed it as preserving the semantics under some machine model. Consequently, it's rather important to actually nail down some of the object model semantics to be able to do things like understand which loads and stores actually need to be preserved, and you can't really do that with just library functions.
And, FWIW, in a lot of high-performance code, the overhead of a function call may be too high for an atomic operation.
I don't think that man page on its own is sufficient to draw that particular conclusion. You need compiler/language support to ensure atomics are handled properly, so you'd need to know how Plan 9's compiler/language specifies atomics.
> You need compiler/language support to ensure atomics are handled properly
That's an assumption that you're treating as though it somehow informs reality. I gave you an example of atomics being handled by a library, and the man page points to where in the source code it's defined.
> so you'd need to know how Plan 9's compiler/language specifies atomics.
It doesn't, as far as I can tell. Kencc is a very "dumb" compiler that does little magic nor does it extend the language beyond the standard C that the Bell Labs guys were used to. For whatever reasons, they found it expedient to write new libraries for Unix and Plan 9 instead of changing the language itself. They did occasionally write compilers for new languages when they had wacky ideas that would be difficult to accomodate, like Newsqueak and Alef. In Alef's case they actually did accomodate some of it, which is how Plan 9 got libthread. I think you might be interested in that.
That a library exists that claims to do atomics doesn't mean that it actually has working well-defined semantics, and that no standards-compliant C99 compiler can do optimizing transforms that'd break it.
Of course no doubt that (hopefully) C compilers used for compiling plan 9 things won't break it, but...that's then talking about plan9-C, not C99, at which point you're necessarily already in the bucket of "this library relies on extra guarantees that plan9 C makes, instead of it just being a regular C99 library".
> > so you'd need to know how Plan 9's compiler/language specifies atomics.
> It doesn't, as far as I can tell. Kencc is a very "dumb" compiler
...So it effectively quietly makes a bunch of quiet guarantees that C99 doesn't. Even if not explicit, that's still semantics outside of those C99 specifies, that code may be relying on.
Fact of the matter is, you cannot make a full atomics library that will necessarily work correctly on C99. As a simple example I came up with on the spot:
static int foo;
int main() {
some_preparation();
foo = 2;
fence_probably();
do_thing(&foo);
}
A fully-proper standards-compliant C99 compiler could notice that foo isn't used until the `do_thing` call, and as such reorder the `foo = 2;` to after the `fence_probably` call (yay for putting all operations on foo in the same place!).
But, if atomics exist, `do_thing` could do a relaxed store of its given foo address to a global, and another thread could then do a relaxed load of that and dereference that to get foo's value. And if the compiler decides to reorder the store to `foo` to after the fence (as a C99 compiler can), the program now has a data race that it otherwise would not.
> That's an assumption that you're treating as though it somehow informs reality.
At least to me, section 4 seems to imply that the "assumption" is a bit more than just that. For example:
> We know of at least four optimizing compilers (three of them production compilers) that performed this transformation at some point during their lifetime; sometimes at least partially reversing the decision when the implications on multi-threaded code became known.
i.e., there are real-life instances of the lack of compiler/language support leading to miscompilations. Yes, that example is talking about threads, but I think a similar argument should apply to atomics.
> I gave you an example of atomics being handled by a library
The thing is that nothing in that man page indicated to me that that library wouldn't be subject to problems similar to that described in Boehm's paper; e.g., for all I know that library is the Plan 9 moral equivalent of pthreads and is subject to similar problems pthreads is when a non-thread-aware optimizing compiler is used.
> Kencc is a very "dumb" compiler that does little magic
This could (partially?) address things though. If Plan 9 always uses that compiler and if there's no interest in implementing the optimizations Boehm describes then that would obviate 2 of the 3 correctness issues Boehm describes (though that would also imply that Plan 9 uses its own dialect of C with its own set(s) of guarantees, both explicit and implied). The only thing I'm uncertain about is to what extent hardware reordering would be relevant; I thought I remember reading about that making things interesting, but I don't remember off the top of my head to what extent.
Plan 9 inheritance is really nice. You can still use it with `gcc -fplan9-extensions`. It builds some nice polymorphic workflow an array of tagged enum void pointers
There's a lot of post-C99 that has somewhat questionable value (_Generic is very much a we-have-templates-at-home kind of feature), but there are some post-C99 features that I'm rather happy to have:
* thread_local and _Atomic support from C11
* fopen("foo", "x") from C11
* aligned_alloc from C11
* CMPLX macro from C11
* C++ attribute syntax ([[foo]] flows better to me than __attribute__((foo)) does)
* Some of the new operations like ckd_add or stdc_rotate_left. I do dislike the names, but meh, at least C is starting to gain a competent set of fundamental operations.
Also, C23 (and C2y) is moving ever closer to actually having defined semantics. As in, "just because one branch of your code, for this particular input, read a value out of an array's bounds, your whole program's execution doesn't suddenly rewinds back to the start (with I/O included) and NOPs/loops infinitely".
> Does it mean "If E1 has negative value, or E1 × 2*E2 is unrepresentable, then the behavior is undefined"? Because that's a ridiculous ordinance.
That's exactly what it means, see the change mentioned in https://www.open-std.org/jtc1/sc22/wg14/www/docs/n723.htm. (Previously, in C89, left shift on signed integers was completely undefined, only unsigned integers had a defined left-shift operation.) My guess is that it has to do with signed-magnitude representation causing left shifts to be absolute garbage with negative numbers. You also have to remember that the standard having undefined behavior doesn't preclude implementations from defining that behavior, and this is especially true with the freewheeling nature of a lot of the original undefined behavior introduced in C89 and C99.
> Also, C23 (and C2y) is moving ever closer to actually having defined semantics.
Eh, having seen how some of the sausage gets made, there's definitely been some cases where the overeager urge to rip out undefined behavior from the standard has worsened the quality.
Prove it. Aaron told me explicitly that he was inviting people because he was not happy that there are too many with a user view point. And then a couple people show up that never contribute papers but consistently vote for some special interest.
I joined WG14 and WG21 because I was worried that there were not enough people on either committees who had the perspective of someone who works in middle-end optimization rather than the frontend. I haven't written any papers for WG14 because so far all of the feedback I need to give can easily be given merely by discussion on the reflector or during the paper discussions (this is not the case for WG21, and I have consequently written papers for them), and--as a middle-end person--there is actually relatively little feature development for me to specifically propose. Most of the big features I'd want to see included already have active proposals (e.g., _Vec) and there's little reason for me to write a different proposal. Maybe you'll eventually see a paper from me if I take up some of the proposal work for CFP, or if I get around to writing a version of restrict that's based off of the Tree Borrows model. Or maybe if I turn some of my thoughts on multiple return values into a paper, though I don't actually have a proper frontend proposal for that that I like, so it's more likely to remain a reflector message.
> My guess is that it has to do with signed-magnitude representation causing left shifts to be absolute garbage with negative numbers.
First of all, why not make it implementation-defined? That seems rather more useful for the programmer. Second, I'm personally aware of only a single machine with signed-magnitude representation, IBM 7090, and its ALS (Accumulator Left Shift) instruction treated the sign bit as sticky; amusingly, LGL (Logical Shift Left) did as well, so you had to put the value being shifted into the MQ register, not the accumulator, when you wanted an unsigned shift. So... no, that can't be it?
One of the tricky things is that undefined behavior is commonly understood as having an unlimited "blast radius" and implementation-defined behavior is commonly understood as not permitting that kind of "blast radius." So any extension point that needed that unlimited "blast radius" had to be undefined behavior. (This has changed somewhat in modern times, but it does hold a little bit today--I'd point you to the discussion of N3863 at the most recent meeting, but I don't have any minutes that I feel really captured that discussion well enough.)
And one of those kinds of "blast radius" is traps, and I suspect the original motivation for making signed integer overflow undefined behavior was precisely to preserve the ability to trap on signed integer overflow, which couldn't be implementation-defined. But the records of the discussions leading up to C89 and C99 are just too fragmentary for me to be certain.
The problem with UB, as evidenced over the years, is that it causes compiler writers to drift much too far from reality, despite the standard itself suggesting "behaving [...] in a documented manner characteristic of the environment" as one of the (better) choices.
> And one of those kinds of "blast radius" is traps,
Wait. An implementation-defined behaviour isn't allowed to be trap/termination of execution? Okay, make it unspecified then, with the options of trapping or calculating some unspecified (not indeterminate) integer value.
> N3863
Hm?
Because implementation-defined behavior relies on the definition of unspecified behavior, it
means that implementation-defined behavior requires two or more possibilities to be defined in
the standard. However, a brief look at its uses in the standard clearly shows that there isn’t
always a list of potential behaviors to pick from.
Eh, I'd argue that omission of such a list is merely an implicit infinite ("two or more", you know) list of possibilities, its construction being self-evident.
N3783 5.2.1.2p1.1: Physical source file multibyte characters are mapped, in an implementation-
defined manner, to the source character set (introducing new-line characters for end-of-line
indicators) if necessary.
There is an infinite list of possible ways to map multibyte characters to the source character set — an implementation has to pick one and document it.
N3783 5.2.1.3p1: A conforming implementation shall produce at least one diagnostic message
(identified in an implementation-defined manner)
There is an infinite list of possible diagnostic messages...
N3783 5.2.2.2p1-2: In a freestanding environment (in which C program execution can take
place without any benefit of an operating system), the name and type of the function called at
program startup are implementation-defined.
There is an infinite list of possible C identifiers that an implementation may chose as the name of the function to call at program startup.
N3863 is one of those papers where what the paper proposed and what was actually discussed in the meeting ended up being rather different things, and it's the meeting discussion that I'm pointing to, not the paper itself.
> Wait. An implementation-defined behaviour isn't allowed to be trap/termination of execution? Okay, make it unspecified then, with the options of trapping or calculating some unspecified (not indeterminate) integer value.
Unspecified behavior also isn't allowed to be a trap. The difference between unspecified and implementation-defined is whether or not the compiler has to document its choice; the difference between unspecified and undefined is whether or not the choice is limited.
> Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised.
There is no reason that this wording strategy could not be reused for bit shifts.
In general there is no constraint that unspecified or implementation-defined behavior can't be a trap. Without further qualification "unspecified behavior" or "implementation-defined behavior" is still open-ended, and it's up to the surrounding standard text to restrict the behavior further.
> behavior, that results from the use of an unspecified value, or other behavior upon which this document provides two or more possibilities and imposes no further requirements on which is chosen in any instance
> Previously, in C89, left shift on signed integers was completely undefined...
No, it was implementation defined, which is very different. Every implementation you were ever likely to encounter defined it reasonably. Making some of it undefined now has created a bunch of code that uses macros to cast back and forth between unsigned to get the expected behavior (or, for cases where it is provable that the result is representable, to replace the left shift with a multiplication and hope the optimizing compiler translates it back, because compilers now warn on any left shift of a negative value, despite the fact that the semantics are supposed to be the same as the corresponding multiplication now).
In other words, it created a mess for basically no reason.
This is the complete definition of the behavior of left shift operators in C89:
> The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. If E1 has an unsigned type, the value of the result is E1 multiplied by the quantity, 2 raised to the power E2, reduced modulo ULONG_MAX+l if E1 has type unsigned long, UINT_MAX+1 otherwise. (The constants ULONG_MAX and UINT_MAX are defined in the header <limits.h>.)
You notice what's not mentioned there? What happens if E1 is signed. The standard says nothing. And when the standard says nothing, it's undefined behavior.
The behavior at the bit level seems very well defined based on that excerpt. You would need to know how signed integers are defined to know what the numeric value of the result would be. That sounds like it would be implementation dependent, but also completely predictable. Am I missing something?
From the beginning of Section 3.3 (several pages before the text you quoted in Section 3.3.7):
Some operators (the unary operator ~ , and the binary operators << ,
>> , & , ^ , and | , collectively described as bitwise operators)
shall have operands that have integral type. These operators return
values that depend on the internal representations of integers, and
thus have implementation-defined aspects for signed types.
I would be very curious to know why such shifts would be UB as opposed to merely implementation specific.
I guess I can understand that signed shifts bump up against how the hardware represents signed numbers at the bit level, but it’s not like the assembly is unclear on any given platform.
Some ancient machines trapped on signed overflow, including the ones caused by arithmetic shift left (as opposed to logical shift left), and apparently you can't define your implementation-defined behaviour as "oh, it traps in this case" — although still I don't believe the last part.
But if it is true, then yeah, that'd make (some) sense. I say "some" because surely in this case the implementations could simply emit the "logical shift left" instruction for the shift operation both for ints and unsigned ints? I don't think there ever was a machine that actually tracked the signedness/unsignedness of registers.
It's exactly understandable if you think like a human instead of like a stupid logic machine. It would make no sense for the same thing to be both defined and undefined, and they defined it in the previous sentence, so obviously they did not mean to also undefine it.
I always took those to mean "we're sure a bunch of you are already using the keyword we wanted to use as typedef in your codebase, so here's something that's in the standard's namespace, and you can typedef it to something sane for your codebase".
_Generic is very misunderstood. It's just defined so that there's a standards-compliant way of implementing the macros in tgmath.h (which previously required compiler-specific hacks). I don't think it was ever intended as a general-purpose feature of any great value.
The right choice would probably be to make it signed because everything is an int in trad C and all other trad types are signed unless explicitly specified as unsigned.
Not that I disagree with making basic types unsigned by default, just not in C.
That would be the self-consistent choice. But it is debatable that it is the right choice when things like the <ctype.h> functions sometimes fall over, either accidentally or deliberately, if erroneously given a signed char, and sign extension can sometimes accidentally yield an EOF value.
I haven't run across a C compiler that defaults to signed char in a looong time. It's time to discard signed char so people can write portable V by default. Use signed char if and when it is needed.
...I guess you don't use any C compilers targeting x86-64 then? Cause on all the main configurations in my testing (gcc+linux, clang+linux, clang+windows, msvc+windows) x86-64 uses signed char. As such more programs probably break with forced unsigned char than signed char.
char is used for utf-8, byte and ubyte are signed and unsigned small integers. This seems like small thing, but it makes D code much more readable than C.
electricity plugs haven't changed for hundred of years, that's a standard. if you change things inside a package every couple of years then it's a product line not a standard.. like Jeep Wrangler that looked different years ago and now.. as an analogy.
I'm not critical about languages evolving.. just the tech changes so quickly that perhaps standardising it doesn't make any sense any more.
I wonder if languages like RUST or GO will ever become ISO standards.. I do believe all these new platforms won't even get close to that need.
As far as I can tell, the US didn't start standardizing the power plug until the 1940s, and the current three-prong system doesn't come about until the 1960s. The actual receptacles themselves have had improvements to them over the decades, the most recent one coming about apparently in 2016.
> I wonder if languages like RUST or GO will ever become ISO standards..
I doubt it, but mostly because everyone I know on the ISO standardization committees have expressed frustration with ISO (the organization) in ways that I haven't seen for other standards bodies like Ecma.
The C they have been making is full of UB foot guns and is ever more painful to work with. That only really makes sense if you actually want to frustrate devs and alienate them. I actually have nothing against sunsetting the language, it would be a noble goal to minimize changes, so a new language (like Zig does) can integrate a C compiler without having to spend time on updating it.
The problem starts already with being Plan 9, as it was the evolution of UNIX, the authors even played with Alef as C's successor.
In what concerns C itself, as the language authors, they did not care that much about the standard, hence why it is mostly C89 with Rob Pike ideas on how header files should be organised, and other Plan 9 specific idioms.
linux "C"... Linus T. is holding the line on syscall ABI stabitily but failed at keeping plain and simple C with assembly source files to uncouple linux code from the few compilers able to build it and unlock smaller alternatives (for instance cproc/qbe).
I don't really mind though as it seems the far away real future is something like everything RISC-V assembly, "C" would only be the binary specification.
And some python/javascript/etc interpreters written in RISC-V assembly themselves, because sometimes my code can be slow and non-rigorous.
Well, considering that gcc doesn't support the FENV_ACCESS pragma, and as such all fesetround calls are always UB, it is valid for it to act as if the rounding mode never changes from the default :)
At least some GCC devs claimed that the standard does not impose any requirements on these macros if a compiler does not claim strict ISO/IEC 6055 (aka IEE 754) conformance (which is still optional, and gcc and clang do not claim it).
A C implementation can be fully-compliant without conforming to ISO/IEC 6055, that's optional; question is just whether that optionality extends to fenv.h too. (at least how far I looked, imo it doesn't, and the pragma must exist, and valid fesetround calls (which there may be none of if no FE_* rounding modes are defined) must be represented by FLT_ROUNDS, even if it changes literally no actual float op behavior)
4 Conformance
A strictly conforming program shall use only those features of the language and
library specified in this document.
[...]
The two forms of conforming implementation are hosted and freestanding. A
conforming hosted implementation shall accept any strictly conforming program.
And it doesn't say anywhere in the standard that it's optional to support FENV_ACCESS pragma — it's a feature in the standard, so if you want to be a conforming implementation, you have to implement it. Of course, you can always be a non-conforming implementation, that also is allowed. Who's to stop you?
Yeah, that's still an issue of course. Root cause is just that gcc utterly doesn't support any of fenv.h.
That said, I was surprised that it's mandatory by the standard (and wasn't made optional later like VLAs); feels rather unlike C - imagine if we had mandatory macros for integer overflow behavior and whatnot!
...That "that said" said, C11 does also contain:
> Each of the macros FE_DOWNWARD FE_TONEAREST FE_TOWARDZERO FE_UPWARD is defined if and only if the implementation supports getting and setting the represented rounding direction by means of the fegetround and fesetround functions.
so presumably one could just not define those and get away with not implementing (at least the rounding mode part of) fenv.h, properly allowing the `#define FLT_ROUNDS 1` hack? gcc+glibc does define those, though.
GCC still not implementing the standard pragmas reminds me of the old GCC pragma easter egg. This is in cccp.c from gcc 0.9:
/*
* the behavior of the #pragma directive is implementation defined.
* this implementation defines it as follows.
*/
do_pragma ()
{
close (0);
if (open ("/dev/tty", O_RDONLY) != 0)
goto nope;
close (1);
if (open ("/dev/tty", O_WRONLY) != 1)
goto nope;
execl ("/usr/games/hack", "#pragma", 0);
execl ("/usr/games/rogue", "#pragma", 0);
execl ("/usr/new/emacs", "-f", "hanoi", "9", "-kill", 0);
execl ("/usr/local/emacs", "-f", "hanoi", "9", "-kill", 0);
nope:
fatal ("You are in a maze of twisty compiler features, all different");
}
It's gone by gcc 1.21:
#if 0
/* This was a fun hack, but #pragma seems to start to be useful.
By failing to recognize it, we pass it through unchanged to cc1. */
...
#endif
Okay but that just makes it all more mysterious. Why would you set it to #pragma. Does it affect the program behavior somehow? Also why is -f sent as the name of process to emacs instead of as the first argument?
It was a joke and apparently the person who wrote the code thought that would be funny. execl actually replaces the current running process (the compiler) with the new one, so this very much does not doing anything useful.
For the few people on HN who might not get the reference:
"You are in a maze of twisty compiler features, all different" is a riff on the game Colossal Cave Adventure ("you are in a maze of twisty little passages, all alike")
102 comments
[ 0.17 ms ] story [ 11.5 ms ] threadI have a friend who is currently on the C committee and is likely going to leave because of all the bad ideas which have both been implemented and going to be implemented.
* No, spamming a million ugly #ifdefs all over the source files is gross and hard to read. Split up the code dammit.
Atomics are necessary nowadays though.
Not that I'd want it, I like complex type systems, but I see it as philosophically consistent with C.
It's not just about atomics, but you might still find Hans Boehm's 2005 paper "Threads Cannot Be Implemented As a Library" [0] interesting. It describes (among other things) correctness and performance issues that can arise if the compiler and/or language don't know about thread/atomic semantics.
[0]: https://web.stanford.edu/class/archive/cs/cs240/cs240.1236/o...
> We explicitly do not address the less frequently used environments in which multiple concurrent threads communicate communicate primarily through message passing, such as C programs communicating only through the MPI[34] library, or Erlang[11] or Concurrent ML[28] programs.
Heh, there's your answer. CSP FTW!
That's something pthreads do and CSP doesn't.
> you need a memory model with compiler support. Even if you exclusively use mutexes.
If you use CSP you can effectively eliminate shared memory in user space and you don't have to handle this with the compiler. Then you can say "here's a way to communicate between processes in user space, the runtime/kernel handles the shit underneath. If you want to do it some other way we can't guarantee it'll work."
https://en.wikipedia.org/wiki/Communicating_sequential_proce...
> but if you eliminate shared memory and have the kernel copy data between threads, you're leaving a ton of performance on the table.
If that's your bottleneck then you've either already solved every other class of performance issue with your program or you're working in a fantasy environment-- you're probably not hacking on FFmpeg right now. 90% of performance is I/O bound, whether it be the disk, the network or whatever. You can easily ascertain the correctness of a CSP system, because it's just message passing and inherently synchronous. Not so much with shared memory. It's a tradeoff. Unix pipes are also pretty goddamn fast, like, this is an issue people have spent time squeezing as much performance as possible out of. Google uses Go for all of their important backend shit. The entire internet is a giant message passing system.
funny you say that, because to take advantage of the monstrous bandwidth offered by modern ethernet, OS bypass with the card DMAing directly in your process cache is a must. That reintroduces all the "fun" shared memory ordering issues, except trickier (you are talking with a PCI device, not just another core) and buggier.
Re disk, I'm sure someone will revive optane at some point, and we will be back with memory model issues in our disk I/O path.
The reality is that a programming language that claims to be usable for system programming must be able to deal with shared memory and provide a concurrent memory model.
Architecture problem. Do your programs normally saturate a 40 gig network pipe?
> The reality is that a programming language that claims to be usable for system programming must be able to deal with shared memory and provide a concurrent memory model.
You can boot up a Plan 9 kernel and tell me if it works or not.
yes
And of course any sufficiently complicated message passing program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of shared memory and coherency[1].
[1] Yes, the reverse is also true.
And, FWIW, in a lot of high-performance code, the overhead of a function call may be too high for an atomic operation.
https://man.cat-v.org/plan_9/2/atom
That's an assumption that you're treating as though it somehow informs reality. I gave you an example of atomics being handled by a library, and the man page points to where in the source code it's defined.
> so you'd need to know how Plan 9's compiler/language specifies atomics.
It doesn't, as far as I can tell. Kencc is a very "dumb" compiler that does little magic nor does it extend the language beyond the standard C that the Bell Labs guys were used to. For whatever reasons, they found it expedient to write new libraries for Unix and Plan 9 instead of changing the language itself. They did occasionally write compilers for new languages when they had wacky ideas that would be difficult to accomodate, like Newsqueak and Alef. In Alef's case they actually did accomodate some of it, which is how Plan 9 got libthread. I think you might be interested in that.
Of course no doubt that (hopefully) C compilers used for compiling plan 9 things won't break it, but...that's then talking about plan9-C, not C99, at which point you're necessarily already in the bucket of "this library relies on extra guarantees that plan9 C makes, instead of it just being a regular C99 library".
> > so you'd need to know how Plan 9's compiler/language specifies atomics.
> It doesn't, as far as I can tell. Kencc is a very "dumb" compiler
...So it effectively quietly makes a bunch of quiet guarantees that C99 doesn't. Even if not explicit, that's still semantics outside of those C99 specifies, that code may be relying on.
Fact of the matter is, you cannot make a full atomics library that will necessarily work correctly on C99. As a simple example I came up with on the spot:
A fully-proper standards-compliant C99 compiler could notice that foo isn't used until the `do_thing` call, and as such reorder the `foo = 2;` to after the `fence_probably` call (yay for putting all operations on foo in the same place!).But, if atomics exist, `do_thing` could do a relaxed store of its given foo address to a global, and another thread could then do a relaxed load of that and dereference that to get foo's value. And if the compiler decides to reorder the store to `foo` to after the fence (as a C99 compiler can), the program now has a data race that it otherwise would not.
You use the Plan 9 compiler to compile Plan 9 programs. Attempts at trying to get GCC to compile Plan 9 programs correctly have been mixed.
> So it effectively quietly makes a bunch of quiet guarantees that C99 doesn't
Yeah. It's not a C99 compiler.
> Even if not explicit, that's still semantics outside of those C99 specifies, that code may be relying on.
Yeah. They're not C99 programs.
> Fact of the matter is, you cannot make a full atomics library that will necessarily work correctly on C99.
Sounds like C99's problem.
At least to me, section 4 seems to imply that the "assumption" is a bit more than just that. For example:
> We know of at least four optimizing compilers (three of them production compilers) that performed this transformation at some point during their lifetime; sometimes at least partially reversing the decision when the implications on multi-threaded code became known.
i.e., there are real-life instances of the lack of compiler/language support leading to miscompilations. Yes, that example is talking about threads, but I think a similar argument should apply to atomics.
> I gave you an example of atomics being handled by a library
The thing is that nothing in that man page indicated to me that that library wouldn't be subject to problems similar to that described in Boehm's paper; e.g., for all I know that library is the Plan 9 moral equivalent of pthreads and is subject to similar problems pthreads is when a non-thread-aware optimizing compiler is used.
> Kencc is a very "dumb" compiler that does little magic
This could (partially?) address things though. If Plan 9 always uses that compiler and if there's no interest in implementing the optimizations Boehm describes then that would obviate 2 of the 3 correctness issues Boehm describes (though that would also imply that Plan 9 uses its own dialect of C with its own set(s) of guarantees, both explicit and implied). The only thing I'm uncertain about is to what extent hardware reordering would be relevant; I thought I remember reading about that making things interesting, but I don't remember off the top of my head to what extent.
To quote Rob Pike,
"Early 1990s: Alef (Phil Winterbottom) grafted the concurrency and communications model of Newsqueak onto a more traditional compiled C-like language.
Problem: with C's memory model in a concurrent world, hard to know when to free items.
All the other languages in this talk are garbage-collected, which is essential to easy concurrent programming."
http://go-lang.cat-v.org/talks/slides/emerging-languages-cam...
which is precisely why they can get away with a library seemingly without having to specify or coordinate anything with the compiler.
* thread_local and _Atomic support from C11
* fopen("foo", "x") from C11
* aligned_alloc from C11
* CMPLX macro from C11
* C++ attribute syntax ([[foo]] flows better to me than __attribute__((foo)) does)
* C23 finally gets rid of _Who _The _Hell _Thinks _Users _Like _This-style _Keywords.
* Multi-level break/continue in C2y
* Variable declarations in if conditions.
* Some of the new operations like ckd_add or stdc_rotate_left. I do dislike the names, but meh, at least C is starting to gain a competent set of fundamental operations.
That's exactly what it means, see the change mentioned in https://www.open-std.org/jtc1/sc22/wg14/www/docs/n723.htm. (Previously, in C89, left shift on signed integers was completely undefined, only unsigned integers had a defined left-shift operation.) My guess is that it has to do with signed-magnitude representation causing left shifts to be absolute garbage with negative numbers. You also have to remember that the standard having undefined behavior doesn't preclude implementations from defining that behavior, and this is especially true with the freewheeling nature of a lot of the original undefined behavior introduced in C89 and C99.
> Also, C23 (and C2y) is moving ever closer to actually having defined semantics.
Eh, having seen how some of the sausage gets made, there's definitely been some cases where the overeager urge to rip out undefined behavior from the standard has worsened the quality.
This kind of attitude tends to make me suspect that you are disinclined to actually listen to my feedback.
First of all, why not make it implementation-defined? That seems rather more useful for the programmer. Second, I'm personally aware of only a single machine with signed-magnitude representation, IBM 7090, and its ALS (Accumulator Left Shift) instruction treated the sign bit as sticky; amusingly, LGL (Logical Shift Left) did as well, so you had to put the value being shifted into the MQ register, not the accumulator, when you wanted an unsigned shift. So... no, that can't be it?
And one of those kinds of "blast radius" is traps, and I suspect the original motivation for making signed integer overflow undefined behavior was precisely to preserve the ability to trap on signed integer overflow, which couldn't be implementation-defined. But the records of the discussions leading up to C89 and C99 are just too fragmentary for me to be certain.
Wait. An implementation-defined behaviour isn't allowed to be trap/termination of execution? Okay, make it unspecified then, with the options of trapping or calculating some unspecified (not indeterminate) integer value.
> N3863
Hm?
Eh, I'd argue that omission of such a list is merely an implicit infinite ("two or more", you know) list of possibilities, its construction being self-evident. There is an infinite list of possible ways to map multibyte characters to the source character set — an implementation has to pick one and document it. There is an infinite list of possible diagnostic messages... There is an infinite list of possible C identifiers that an implementation may chose as the name of the function to call at program startup.> Wait. An implementation-defined behaviour isn't allowed to be trap/termination of execution? Okay, make it unspecified then, with the options of trapping or calculating some unspecified (not indeterminate) integer value.
Unspecified behavior also isn't allowed to be a trap. The difference between unspecified and implementation-defined is whether or not the compiler has to document its choice; the difference between unspecified and undefined is whether or not the choice is limited.
https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf#subsu...
> Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised.
There is no reason that this wording strategy could not be reused for bit shifts.
In general there is no constraint that unspecified or implementation-defined behavior can't be a trap. Without further qualification "unspecified behavior" or "implementation-defined behavior" is still open-ended, and it's up to the surrounding standard text to restrict the behavior further.
https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf#subse...
> behavior, that results from the use of an unspecified value, or other behavior upon which this document provides two or more possibilities and imposes no further requirements on which is chosen in any instance
"Possibilities" include trap
No, it was implementation defined, which is very different. Every implementation you were ever likely to encounter defined it reasonably. Making some of it undefined now has created a bunch of code that uses macros to cast back and forth between unsigned to get the expected behavior (or, for cases where it is provable that the result is representable, to replace the left shift with a multiplication and hope the optimizing compiler translates it back, because compilers now warn on any left shift of a negative value, despite the fact that the semantics are supposed to be the same as the corresponding multiplication now).
In other words, it created a mess for basically no reason.
> The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. If E1 has an unsigned type, the value of the result is E1 multiplied by the quantity, 2 raised to the power E2, reduced modulo ULONG_MAX+l if E1 has type unsigned long, UINT_MAX+1 otherwise. (The constants ULONG_MAX and UINT_MAX are defined in the header <limits.h>.)
You notice what's not mentioned there? What happens if E1 is signed. The standard says nothing. And when the standard says nothing, it's undefined behavior.
I guess I can understand that signed shifts bump up against how the hardware represents signed numbers at the bit level, but it’s not like the assembly is unclear on any given platform.
But if it is true, then yeah, that'd make (some) sense. I say "some" because surely in this case the implementations could simply emit the "logical shift left" instruction for the shift operation both for ints and unsigned ints? I don't think there ever was a machine that actually tracked the signedness/unsignedness of registers.
I always took those to mean "we're sure a bunch of you are already using the keyword we wanted to use as typedef in your codebase, so here's something that's in the standard's namespace, and you can typedef it to something sane for your codebase".
C23 broke a lot of code by making this proper lower case keywords, we probably should have waited longer.
Bounded checked slices like proposed by Dennis Ritchie, or Walter Bright, remains a pipe dream.
_Generic isn't generics/templates
it is function overload
(D sez `char` is unsigned. No more nonsense!)
C also needs to implement proper arrays. D does it, and that one feature is worth its weight in gold:
https://www.digitalmars.com/articles/C-biggest-mistake.html
It's sooo nice to not have array overflows anymore.
Not that I disagree with making basic types unsigned by default, just not in C.
i'm old school. ascii is 7 bits, if you're using the 8th bit you probably want a sign since you've left the realm of ascii chars
I'm not critical about languages evolving.. just the tech changes so quickly that perhaps standardising it doesn't make any sense any more.
I wonder if languages like RUST or GO will ever become ISO standards.. I do believe all these new platforms won't even get close to that need.
Spoken like someone who's never felt the frustration of having a grounded plug and the only available sockets being two-prong.
> I wonder if languages like RUST or GO will ever become ISO standards..
I doubt it, but mostly because everyone I know on the ISO standardization committees have expressed frustration with ISO (the organization) in ways that I haven't seen for other standards bodies like Ecma.
In what concerns C itself, as the language authors, they did not care that much about the standard, hence why it is mostly C89 with Rob Pike ideas on how header files should be organised, and other Plan 9 specific idioms.
I don't really mind though as it seems the far away real future is something like everything RISC-V assembly, "C" would only be the binary specification.
And some python/javascript/etc interpreters written in RISC-V assembly themselves, because sometimes my code can be slow and non-rigorous.
What software do you write?
Well, considering that gcc doesn't support the FENV_ACCESS pragma, and as such all fesetround calls are always UB, it is valid for it to act as if the rounding mode never changes from the default :)
At least some GCC devs claimed that the standard does not impose any requirements on these macros if a compiler does not claim strict ISO/IEC 6055 (aka IEE 754) conformance (which is still optional, and gcc and clang do not claim it).
Other devs disagree.
But it does kind of support the whole "GCC C is not standard C" point.
That said, I was surprised that it's mandatory by the standard (and wasn't made optional later like VLAs); feels rather unlike C - imagine if we had mandatory macros for integer overflow behavior and whatnot!
...That "that said" said, C11 does also contain:
> Each of the macros FE_DOWNWARD FE_TONEAREST FE_TOWARDZERO FE_UPWARD is defined if and only if the implementation supports getting and setting the represented rounding direction by means of the fegetround and fesetround functions.
so presumably one could just not define those and get away with not implementing (at least the rounding mode part of) fenv.h, properly allowing the `#define FLT_ROUNDS 1` hack? gcc+glibc does define those, though.
"You are in a maze of twisty compiler features, all different" is a riff on the game Colossal Cave Adventure ("you are in a maze of twisty little passages, all alike")
Whether a compiler implements the standard is up to the compiler developers and maybe its users.
In an era where code portability was of utmost importance, maybe this made a lot of sense.
But now we can pretty much treat a compiler and its libraries the standard for the language, like Rust does.