Live data from Hacker News

Lesser known tricks, quirks and features of C

blog.joren.ga

11–20 of 189 posts

Re: Lesser known tricks, quirks and features of C

#12
post #4

Nice article. Saw a few things I wish I'd known about. 1. %n in printf would be handy when writing CLIs dealing w/ multiple lines or precise counts of backspaces. 2. Using enums as a form of static_assert() is a great idea (triggering a div by zero compiler error).

%n is an extremely poor fit for CLI manipulation or tokenization for backspacing.

%n is for bytes, not user-perceived characters.

Re: Lesser known tricks, quirks and features of C

#13

Here's another one. Handy "syntax" that makes it possible to iterate an unsigned type from N-1 to 0. (Normally this is tricky.) for (unsigned int i = N; i --> 0;) printf("%d\n", i); This --> construction also works in JavaScript and so on.

AFAICT this would parse as "(i--) > 0", there's no "-->" operator.

Re: Lesser known tricks, quirks and features of C

#14
I remember once upon a time I thought C was fairly simple, so I decided to write a program to generate ASTs from C programs. I was very wrong and it was kind of a nightmare. There are so many weird little quirks or lesser-used features that I never saw in the wild even in large production codebases; I feel like you really don't _need_ a lot of these features. I can't imagine doing proper compiler work, especially for something like C++. Nice article.

Re: Lesser known tricks, quirks and features of C

#16
Never quite understood why compound literals are lvalues, but fine, whatever, I guess, it's so that you can write "&(struct Foo){};" instead of "struct Foo tmp; &tmp;"... which, on a tangential note, reminds me about Go: the proposals to make things like &5 and &true legal in Go were rejected because "the implied semantics would be unclear" even though &structFoo{} is legal and apparently has obvious semantics.

Re: Lesser known tricks, quirks and features of C

#18

> The 0 width field tells that the following bit fields should be set on the next atomic entity (char). This isn't correct since int can't be less than 16-bits. Fields are placed on the nearest natural alignment for the target platform, which might not support unaligned access.

C is fundamentally confused, because it offers (near) machine-level specifications but then leaves just enough wiggle room for compilers to "optimize" (through alignment and such) while ruining the precision of a specification. You end up not getting exactly what you want at the machine level. It's infuriating.

The bitfield stuff in C would be fantastic if it weren't fundamentally broken. E.g. some Microsoft compilers in the past interpreted bit fields as signed...always. In V8 we had a work around with templates to avoid bitfields altogether. Fail.

Re: Lesser known tricks, quirks and features of C

#19
post #3

Yet another proof that C is simple but not easy.

The simplest languages tend to be the most difficult. Brainfuck, Binary Lambda Calculus, Unlambda, and other "Turing tarpits" are all extremely difficult to use for anything even mildly complex.

Re: Lesser known tricks, quirks and features of C

#20

> The 0 width field tells that the following bit fields should be set on the next atomic entity (char). This isn't correct since int can't be less than 16-bits. Fields are placed on the nearest natural alignment for the target platform, which might not support unaligned access.

int isn't a bitfield.
Post reply on HN