View it in the editor instead.

It's a C99 feature, and clang's the only compiler I know of that produces the diagnostic (and only in later versions)

btw; I wrote this talk.

I didn't know that. To answer my previous question, clang doesn't fire a warning when passing pointers of any size to the function foo.

And by the way, nice talk, it's great learning these dark secrets of C.

The compiler can't know at compile time with a naked pointer like it can with an array. [static 1] is handy to say it must not explicitly be NULL, as if it were optional, however.

Yes, but I expected some kind of "You're passing a pointer as an array of size n. I can't check the size, but you should make sure you've checked it".

I can't imagine that would be anything but noise. 99% of my function calls have pointers passed through, not arrays.

But a pointer is not the same thing as an array, a pointer does not carry the size of the allocated space which an array does in the same scope.

Good, because I was missing a slide:

= Bitfields =

Not even once.

;)

Everybody knows about bitfields :)

Bitfields have some crazy fun dark corners, though. For instance, which values can this bitfield hold:

    int b:1;

Signed two's-complement n-bit integers can hold values from 2^(n-1)-1 to -2^(n-1), so in theory it can hold 0 and -1, but many compilers get that one wrong. Always declare one-bit bitfields as unsigned. (The Sparse static analyzer will warn you about that one.)

Please tell me who you work for, so I know to avoid any of your products. Using BBC Basic like this terrifies me. If anything, because its total lack of type safety for anything but the simplest of values.

Anecdotally, I think you got the wrong end of the stick regarding type safety.

I used to work for a defence contractor who avidly programmed everything in ADA with verified compilers and mathematically proved algorithms.

Stuff still broke because the algorithms and designs were wrong. That particular problem is far more problematic than type constraints.

Regarding BBC BASIC, it is strongly typed but all casts and conversions are implicit so you need to know what it's going to do:

   REM win
   p%=4;q%=4;r%=p%/q%;PRINTr%

   REM fail
   p%=4;q=4.0;r%=p%/q;PRINTr%

The earlier has no cast, the latter does.

When it goes wrong, it's not usually the code that's gone phut:

http://www.ntk.net/2000/07/14/dohtrain.jpg

Wow! Thanks for the reminder about how great NTK was. :-)

Out of interest, let me ask: Do you believe it's impossible to write safety-critical software in C?

What understanding is it that you have that suggests that? It can shovel data via DMA as well as the next architecture.

High-density ARM servers are not ideal for every application. However, there are plenty of applications where you don't need massive amounts of computational grunt in each CPU, such as web serving, hadoop, mail and DNS servers, etc. Also, the density and lower power/cooling requirements can often offset the lack of performance. Each slab has a 260W PSU. The whole system can't pull more than 260W, ever. Some Intel CPUs need 200W just on their own.

Yeah, it's eight individual systems with two very fast Ethernet links to an on-board managed switch.

Half depth, not width. Everything comes out the front, so you mount them back-to-back in a rack.

Been a while since I was heavily involved in high-density data centers... How does that work with traditional hot aisle/cold aisle layouts? Seems like you'd need to adjust the cooling to have an air channel up the middle of the rack?

You could do, or have one of them exhaust to its "front", and the other exhaust to its "back".

So the one at the "back" is getting pre-warmed air. Wouldn't this be a problem?

*Note I am used to normal data-centers but not high density stuff. I don't know of the special provisions a high-density setup would have.

In general, high-density or supercompute systems are installed with custom racks, cooling, power supplies, etc. This doesn't need anything custom, just something that isn't always the default in some DCs.

They're ARMs, they don't need much cooling anyway.

And you can buy them where, exactly? :)

Boston Limited should be shipping Viridis units now [1][2].

[1]: http://www.boston.co.uk/solutions/viridis/default.aspx

[2]: http://www.theregister.co.uk/2012/07/09/boston_viridis_arm_s...

Yeah, I see they have the same sort of "talk to us for pricing and more info".

Important things to note is that each of the nodes in this Slab have their own local SATA solid-state storage, and the individual CPUs are quicker. The Boston thing has higher density though.

The only thing they're not in the same ballpark for is quantity of generated data. If you don't need much, this is as good.

Possibly. If your SSH and HTTP daemons and encrypted file systems use /dev/random, and you're running Linux, then possibly. Look in /proc/sys/kernel/random/entropy_avail, and possibly graph this over time. Also, some modern Linux distributions use data from the random pool at exec() (to randomise linkage), and so it's possible you could be running low already. TLS email also consumes huge amounts, and anybody running virtual servers might be having a problem.

Is there anyway to speed this up without hardware? My server has a laughably low amount of entropy available and I think it is why a lot of the connections are slow.

If not what is a cheapish way to get hardware entropy?

If you have a sound chip on your server which is capable of disconnecting itself from the microphone socket on the back then you might be able to use low-order bits from that and a tool such as the audio entropy daemon or 'randomsound' (the latter is packaged in Debian) however I'd not recommend that as anything other than a stopgap until you can get something more effective.

Simtec expect to release their Entropy Key for around GBP42 delivered in the UK. (worldwide postage costs will obviously inflate that a bit).

Wow, that is a pretty reasonable price. When do they expect to ship?

If I have anything to do with it, in the next month or so :)