Lesser known tricks, quirks and features of C

https://blog.joren.ga/less-known-c

by jandeboevrie • 3 years ago

410 176 3 years ago

blog.joren.ga

gallier22• 3 years ago

Cool. Two of the tricks shown are from my contribution in stackoverflow.

vocram• 3 years ago

Yet another proof that C is simple but not easy.

SAI_Peregrinus• 3 years ago

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.

elcritch• 3 years ago

Forth. It’s easy for a small cute script. But quickly becomes a PITA.

mtlmtlmtlmtl2• 3 years ago

I always felt like unlambda and other SKI calculus esque esolangs(iota comes to mind) could have some kinda strange use case in some kind of generalised genetic programming. It should be possible to create a binary notation for SKI calculus where arbitrary bitstrings will be valid, and so one could randomly mutate and recombine arbitrary programs. Though I've never delved deeper into genetic algorithms and evolutionary programming, my sense is that genetic algorithms tend to be restricted to parameterised algorithms where the "genes" determine the various parameters. Which can be great for optimisation problems.

It's one of those weird ideas I've had kicking about for years but never did anything about, and yet I keep coming back to it.

dantle• 3 years ago

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

torstenvl2• 3 years ago

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

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

jcelerier• 3 years ago

using enums as a form of static_assert is very bad when C nowadays literally has static_assert (_Static_assert: https://gcc.godbolt.org/z/bfv6rKdKM)

tom_4• 3 years ago

The enum idea is interesting. I've previously used an extern with a conditional size of either 1 (valid) or -1 (invalid). This requires no additional boilerplate, and is #define-able into a static assert when built with a recent enough compiler. Something like this, from memory:

    #define STATIC_ASSERT(COND) extern char static_assert_cond_[(COND)?1:-1] /* C99 or earlier */
    #define STATIC_ASSERT(COND) _Static_assert(COND) /* C11 or later */

As both are declarations, I don't think you'll end up in a situation where one is valid and the other isn't - but I could be wrong, and I suspect it would rarely matter in practice anyway.

Miserlou57• 3 years ago

“Quirks and features”

aranchelk• 3 years ago

Where’s the DougScore?

ufo• 3 years ago

Fun fact about %n:

Mazda cars used to have a bug where they used printf(str) instead of printf("%s", str) and their media system would crash if you tried to play the "99% Invisible" podcast in them. All because the "% In" was parsed as a "%n" with some extra modifiers. https://99percentinvisible.org/episode/the-roman-mars-mazda-...

rerdavies2• 3 years ago

Fun fact about %n:

The %n functionality also makes printf accidentally Turing-complete even with a well-formed set of arguments. A game of tic-tac-toe written in the format string is a winner of the 27th IOCCC.

- sez wiki.

A not so fun fact:

Because the %n format is inherently insecure, it's disabled by default.

- MSVC reference.

charcircuit5• 3 years ago

The %n functionality also makes printf accidentally Turing-complete

No it doesn't. Printf has no way to loop so it's not Turing complete. Even if you did what the IOCCC entry did with putting it into a loop it still wouldn't be Turing complete as it would not have an infinite memory.

tom_4• 3 years ago

"format not a string literal" is one warning I always upgrade to an error. Dear reader: you should do this, too!

wrigby• 3 years ago

Thanks! This prompted me to look up the flag to enable this. For GCC it’s:

  -Werror=format-security

Gigachad2• 3 years ago

Why are these not compiler errors by default? Opting in to such important safety features seems like broken design.

tialaramex• 3 years ago

I don't like a lot of things in C++, but one thing worth praising in particular is std::format

std::format specifically only works for constant† format strings. Not because they can't make it work with a dynamic format, std::vformat is exactly that, but most of the time you don't want and shouldn't use a dynamic format and the choice to refuse dynamic formats in std::format means fewer people are going to end up shooting themselves in the foot.

Because it requires constant formats, std::format also gets to guarantee compile time errors. Too many or not enough arguments? Program won't build. Wrong types? Program won't build. This shifts some nasty errors hard left.

† Not necessarily a literal, any constant expression, so it just needs to have some concrete value when it's compiled.

gdprrrr• 3 years ago

Also iPhones had a RCE uaing a WiFi Name that contained %s https://thehackernews.com/2021/07/turns-out-that-low-risk-io...

saagarjha2• 3 years ago

%@.

GolangProject• 3 years ago

This is one of those annoying little problems that is easily picked up by the vet command (https://pkg.go.dev/cmd/vet) when writing Go code. There are, of course, many linters that do the same thing in C, but it's nice to have an authoritative one built in as part of the official Go toolchain, so everyone's code undergoes the same basic checks.

foobiekr• 3 years ago

Most of these are pretty familiar if old enough but this is a wonderful list.

I didn’t know C23 was getting rid of trigraphs. That’s probably a good thing and easy to clean up if needed.

int_19h5• 3 years ago

The bit about "register" is old enough that I don't think it's meaningful anymore.

The stock verbiage about how modern compilers ignore "register" because they can do better but it may be useful on simpler ones, has been around in this exact form 20 years ago already. And one curious thing is that even back then, such statements would never list specific compilers where "register" still did something useful.

So far as I can tell, "register" was in actual use back when many C compilers were still single-pass, or at least didn't have a full-fledged AST, and thus their ability to do things like escape analysis was limited. With that in mind, "register" was basically a promise to such a compiler to not take the address of a local in the function body (this is the only standard way in which it affects C semantics!). But we haven't had such compilers for a very long time now, even when targeting embedded - the compilers themselves run on full-power hardware, so there's no reason for them to take shortcuts.

camel-cdr• 3 years ago

I think register is closer to const, as in: it's a hint to the programmer not the compiler.

So if you want to make absolutely sure that a variable can always be in a register then you should consider adding the register specifier to stop other programmers from taking the address of that variable.

taviso• 3 years ago

It's still useful on non-simple compilers when mixing inline assembly and c, for example `register __m128 foo asm("ymm7")`.

I realize that's a gnu extension - but it's super useful!

kevin_thibedeau2• 3 years ago

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.

titzer3• 3 years ago

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.

HybridCurve4• 3 years ago

I think the problem with this is the C compiler has to find a solution which work with all the architectures it is expected to support. It order to achieve this, it must generalize in some areas and have flexibility in others. C programmers are required to be familiar with both the specifics of the architectures they are building for and the idiosyncrasies of their complier. I always assumed most other compiled languages were like this since I started with C and moved to x86 assembly from there. However, the more I read about people disliking C for this reason, the more I believe this may not be the case.

The bitfield stuff in C would be fantastic if it weren't fundamentally broken

Bitfields in C can be manageable. Each compiler has it's own set of rules for how it prefers to arrange and pack them. Despite them not always being intuitive, I use them regularly since they are so succinct. If you are concerned about faithful and predictable ordering you generally just have a test program which uses known values to verify your layout as part of your build configuration or test battery.

... some Microsoft compilers ...

I've used many C compilers but I have always avoided microsoft ones, going so far to carry a floppy disc with my own when working in the lab at school.

rerdavies2• 3 years ago

int isn't a bitfield.

Jorengarenar8• 3 years ago

I think I'll use other example. Thanks!

kevin_thibedeau2• 3 years ago

You can just expand your example to use 16-bit values or switch to uint8_t. Bitfields with signed integers are also a minefield so it's best to never attempt it.

suprjami6• 3 years ago

The entire placement of bitfields is implementation defined.

So yeah, the placement in memory might be `xxxxx000 00000000 yyyyyyy0` but it could also be `yyyyyyy0 00000000 xxxxx000` or `yyyyyyy0 00000000 00000000 xxxxx000` or anything else.

Bitfields are very misunderstood and really only safe to treat as an ADT with access through their named API, not their bit placement ABI. People misuse them a lot.

ikran03• 3 years ago

Too young to know about anything in there, but these look so interesting. Can't wait to show off '%n' in my next uni project

nstbayless• 3 years ago

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.

titzer3• 3 years ago

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

texaslonghorn5• 3 years ago

https://stackoverflow.com/questions/1642028/what-is-the-oper...

Jorengarenar8• 3 years ago

I was hesitant to put it on the list, but fine, you convinced me

stonegray• 3 years ago

If you're gonna test the i--, shouldn't it fall through on zero anyway?

    for (unsigned int i = N; i--;){}

    unsigned int i = N;
    while(i--){ ... }

Also I think I'm missing the tricky part. Couldn't this be a bog-standard for loop?

   for (unsigned int i = N - 1; i > 0; i--){ ... }

The "downto" pseudooperator definitely scores some points for coolness and aesthetics, but there's no immediately obvious use case for me.

Jorengarenar8• 3 years ago

The former executes loop when `i` is 0.

And we cannot change the comparison to `>=` in the later, because unsigned is always bigger or equal 0, thus we would get infinite loop.

skribanto• 3 years ago

how would you iterate over every possible value of a unsigned int?

mtklein4• 3 years ago

Usually I use a do-while loop,

    unsigned char x = 0;
    do {
        printf("%d\n", x);
    } while (++x);

NoZebra120vClip3• 3 years ago

The unary complement operator should get you there:

  unsigned int x = 0;
  const unsigned int max = ~x;

  while (x <= max) {
     calc(x++);
  }

Or,

  #include <limits.h>

  const unsigned int max = UINT_MAX;

mtklein4• 3 years ago

It's worth noting that this does also work on signed types, so it can be a kind of handy idiom to see

   while (N --> 0) { ... }

and know it will execute N times no matter the details of the type of N.

localplume• 3 years ago

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.

HybridCurve4• 3 years ago

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.

Oh man, I think we all have been this young and naive at some point.

I have spent time working with compilers for this purpose (having realized I did not want to attempt parsing source and generating the AST) and decided it is much easier to let them do the work. That being said, it can still be more than a handful (both GCC and Clang have their eccentricities) and depending on how you are using it you still might be in over your head.

When you start a project like this and end up failing because you simply do not have the depth of knowledge or time to see it to completion it often feels a bit demoralizing from the loss of investment. Truthfully though, having started many such ventures (emulators for 6502 and 80386 to name a few), you get all the benefit of experience from working on a difficult problems without the misery of debugging and model checking until everything until is more/less perfect. It's great fun, you learn a lot, and you should never avoid trying simply because it might be too much to handle.

Joker_vD2• 3 years ago

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.

leni536• 3 years ago

In C compound literals have a relatively long lifetime compared to C++ temporaries. With these lifetime rules it makes sense that they are lvalues, although I like C++ rvalues (especially prvalues) more.

https://cigix.me/c17#6.5.2.5.p5

If the compound literal occurs outside the body of a function, the object has static storage duration; otherwise, it has automatic storage duration associated with the enclosing block.

cataphract• 3 years ago

It's useful when a function has a out or in/out struct parameter whose value at the end you're not interested in. Or in functions where the struct is an input parameter, but they return it as a return value too, which you can then assign to a pointer variable or immediately pass to another function.

Note that the struct values thus created have longer lifetimes than temporary C++ objects created directly inside the argument list of a function call.

flohofwoe4• 3 years ago

That's extemely useful for invoking a function that takes a pointer to a struct, but you don't want 'taint' the code with a temporary variable that's only needed for the function call:

   func(&(bla_t){ .x = 0, .y = 1 });

gallier22• 3 years ago

Compound literals are anonymous variables, i.e. like variables except that there is no label visible in the C program. If you look at the assembly you'll see that they are declared exactly like a variable except with a compiler generated internal label.

zabzonk4• 3 years ago

the c training course at a popular uk training company (the instruction set) had duff's device on something like page 5 of their c course - expunging it was one of the first things i did when i joined them. there were many others.

zabzonk4• 3 years ago

i don't ask this too often - but what is wrong with this comment?

bombcar• 3 years ago

I presume you angered the Duff Defenders (there are those that feel C shouldn’t be taught unless you’re taught all the weird things it can do).

milgra3• 3 years ago

Very nice collection. My favorite C feature is actually a gcc/clang feature : the __INCLUDE_LEVEL__ predefined macro. It made me code&maintain my C projects exactly twice as fast as before because file count dropped to half : https://github.com/milgra/headerlessc .

3836293648• 3 years ago

How do you handle third party headers?

milgra3• 3 years ago

I just include them, everything works as before. If I have to create a library then I create a separate header file for the api functions and only the internals are headerless.

gavinray• 3 years ago

This is great!

enriquto• 3 years ago

I love this. Somehow it feels more elegant than "header-only" libraries.

xigoi2• 3 years ago

How does this help? It just moves the content of the .h file to the .c file, but you still need to Write Everything Twice.

milgra3• 3 years ago

It reduces file count in the project browser, renaming/refactoring is much simpler in one file, it just feels like working with a newer language.

account423• 3 years ago

Is having two files really that much of a bother? I have my editor set switch between the .c(pp) and the .h with a keyboard shortcut and that seems easier than scrolling between declaration and definition when you want to change something.

zwieback• 3 years ago

Be interesting to see when these features showed up. I learned C from the K&R book back in the day and it doesn't mention most of these.

Designated initializer is something I'll try to remember, seems handy.

suprjami6• 3 years ago

Designated initialisers were added in C99

AceJohnny24• 3 years ago

Yeah the K&R, while being a masterpiece of clarity and conciseness, is severely outdated in many important ways.

I wish there was some effort to create a modern version while preserving the clarity and conciseness of Kernighan and Ritchie.

Designated initializers in particular are extremely useful. I once halted a factory line for days because of a mistake they would have avoided.

flohofwoe4• 3 years ago

Designated init and compound literals were added in C99. I think there are two reasons for those features not being better known:

1) C++ 'forked' their C subset before C99 (ca. "C95"), and while C++20 finally got its own version of designated init, this has so many restrictions compared to C99 that it is basically pointless.

2) MSVC hasn't supported any important C99 features until around 2016

neverrroot3• 3 years ago

It’s cool to have these, it’s fun to use them for fun. But please don’t use them in production code. Also don’t assume most of them will he known by other developers.

suprjami6• 3 years ago

Professional C developers definitely should be using at least designated init and FAM, standard features both added in C99 and currently 24 years old.

neverrroot3• 3 years ago

Well, it’s either a lesser known trick or it’s something people should be using. In general using lesser known tricks it’s not a good idea for production code. But I understand there are cases where there is no good alternative, so it’s warranted.

Jorengarenar8• 3 years ago

Also don’t assume most of them will he known by other developers.

Given the title of the article, one ought to assume the opposite ;)

Gigachad2• 3 years ago

Please don’t use C at all in production if you can help it.

jjgreen2• 3 years ago

So no Unix, Linux, Bash, cURL, Ruby, ...?

icedchai2• 3 years ago

The entire world runs on C. Even if you’re not writing new C code, it is useful to understand.

flohofwoe4• 3 years ago

Some of those are regular modern C features and definitely should be used, most importantly compound literals and designated init, since they make the code both safer and more readable (and I blame the Visual Studio compiler team for dragging their asses for 16 years to support at least a subset of C99 for those features to be 'lesser known').

LegionMammal9783• 3 years ago

volatile type qualifier
This qualifier tells the compiler that a variable may be accessed by other means than the current code (e.g. by code run in another thread or it's MMIO device), thus to not optimize away reads and writes to this resource.

It's dangerous to mention cross-thread data access as a use case for volatile. In standard C, modifying any non-atomic value on one thread, while accessing it on another thread without synchronization, is always UB. Volatile variables do not get any exemption from this rule. In practice, the symptoms of such a data race include the modification not being visible on the other thread, or the modified value getting torn between its old and new states.

Jorengarenar8• 3 years ago

`volatile` is one of the things we need to pay attention to when dealing with threads, but as you notice it's not the only one.

Eskil Steenberg talks about it at 12:42 in his talk Advanced C: The UB and optimizations that trick good programmers. [0]

[0] https://youtu.be/w3_e9vZj7D8?t=762

plugin-baby• 3 years ago

UB?

G3rn0ti• 3 years ago

„undefined behavior“

mid-kid2• 3 years ago

These days it can be chained with _Atomic to achieve the desired effect. That said, oftentimes you need more serious synchronization mechanisms your library would provide.

LegionMammal9783• 3 years ago

_Atomic is indeed the correct qualifier to use for unsynchronized cross-thread access. The volatile qualifier doesn't add anything useful on top of that. Really, the only things volatile should be used for are MMIO, debugging, performance testing, and certain situations with signal handlers or setjmp within a single thread.

clnq• 3 years ago

Do we have something like this for C++ (parts not shared with C)?

HybridCurve4• 3 years ago

Can't say for all, but I am reasonably certain C++ does not support designated initializers/sparse array definitions. Some of these features where added in more recent revisions to the C specification from which C++ has diverged from. I would expect most of the differences would become more pronounced starting with C99.

flohofwoe4• 3 years ago

In theory, C++20 has designated init, but it has so many restrictions compared to C99 that it is pretty much useless for real world code.

int_19h5• 3 years ago

One non-obvious thing about named function types is that they can also be used to declare (but not define) functions:

   typedef void func(int);
   func f;
   void f(int) {}

I don't think I've ever seen a practical use for this in C, though. In C++, where this also works, and extends to member functions, this can be very occasionally useful in conjunction with decltype to assert that a function has signature identical to some other function - e.g. when you're intercepting and detouring some shared library calls:

    int foo();
    decltype(foo) bar;

I suppose with typeof() in C23 this might also become more interesting.

mtklein4• 3 years ago

I have found this pretty handy for declaring a bunch of functions of all the same type, e.g. steps in a direct-threaded interpreter.

    typedef void Step(whatever...);

    Step add,sub,mul,div,
         load,store,
         etc...;

torstenvl2• 3 years ago

I've seen this used to define function pointers / callbacks in a "cleaner" way. I think Mg does this IIRC.

AceJohnny24• 3 years ago

Compound Literals in C are great. They're no surprise to anyone coming from more sophisticated languages, but I've never seen them used in the C codebases I've worked on.

What with C also allowing structures as return values, another rarely-used feature, they're really useful for allowing a richer API than the historical `int foo(...)` that so many people are used to seeing.

C has so much legacy that it's really hard for even decades-old (C99!) feature to impose themselves. Or perhaps that's MSVC's lagging support that's to blame :p

pjmlp• 3 years ago

MSVC supports C11 and C17, minus the C99 stuff that was made optional in C11.

Anyway given the option, one should always favour C++ over C, if they care about secure code, which while not perfect it is much better than any C compiler will do.

AceJohnny24• 3 years ago

Anyway given the option, one should always favour C++ over C

Eh. I work in embedded, where C reigns supreme. C++ has its own issues in the area, namely that you need to construct your own sub-dialect that removes some features of C++ to make it fit embedded constraints. Commonly, it's C++-but-no-exceptions, sometimes C++-but-no-templates, and others.

That said, I'll grant that us embedded developers are effectively "traumatized" and have difficulty accepting new approaches because we're too focused on certain paradigms that are no longer relevant (See my previous about returning structures, which has encountered responses like "but then it might do an extra memcpy()!!11")

AceJohnny24• 3 years ago

MSVC supports C11 and C17, minus the C99 stuff that was made optional in C11.

Sure they do now. They were particularly slow at implementing a bunch of C99 stuff, some of it landing only in VS 2019

https://learn.microsoft.com/en-us/cpp/overview/visual-cpp-la...

MSVC has long lagged in C support because they focused on that subset of C standards that were required for C++.

https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...

icedchai2• 3 years ago

For many, I think "C" is still "C89."

I remember working on a commercial project in the mid-2000's that still had #ifdefs for K&R C prototypes (meaning, pre-ANSI C.) This was a recent-ish project at the time, started in 2000. Were people going to go back in time and compile it on an old architecture? I doubt it.

C moves slow.

tastysandwich• 3 years ago

"Expert C Programming: Deep C Secrets" is a really good book to learn a lot of C tricks and quirks, plus some history. I read it a few years ago and loved it.

I was a grad when I read it and remember annoying my older coworkers for a few weeks with little gotchas I picked up. "hey what do you think THIS example prints?" "Stop sending me these!"

jjgreen2• 3 years ago

Fabulous book, includes a section "Bus Error, Take the Train" explaining the "bus errors" one found on Sun hardware ...

defrost• 3 years ago

When I wrote a lot of cross platform performant numerics I loved the bus error thrown by the Sun machines.

In essence it was a RISC machine saying "I can't deal with unaligned data" and a sign that code was (say) storing a 32 or 64 bit int that straddled a word boundary and the hardware was not coping on a MOV.

Why did that matter and why was it good thing?

It forced programmers to think about data alignment and resulted in code that run faster on CISC Intel chips.

The dirty secret about Intel chips was they "just did it" w/out complaint - and it slowed them down significantly on pipelined computations if they were constantly double handling unaligned data to get it from memory (across a word boundary) to bus (aligned for transit) to memry again (across a word boundary).

somewhereoutth2• 3 years ago

I'm a bit better at English than c, and in the spirit of language peculiarities, this jumped out at me:

It's possible, because C cares less than more about whitespace

Idiomatically we'd say 'couldn't care less'. I guess we should be glad it wasn't the diabolical and illogical 'could care less'

Jedd• 3 years ago

I don't believe those are functionally / semantically equivalent - couldn't care less does imply a min() value of care.

In contrast, the author is suggesting a comparative only.

And, on careful re-reading, I suspect the author is having a play on syntax & semantics here -- the context of the quote is:

You may ask, since when C has such operator and the answer is: since never. --> is not an operator, but two separate operators -- and > written in a way they look like one. It's possible, because C cares less than more about whitespace.

Given that '--' is decrement (kind of 'lessen') and > is greater than (kind of 'more'). Perhaps I am reading too much into that.

(I feel 'couldn't care less' is perhaps more common in northern America than elsewhere, and while TFA has a Gabon TLD, appears to be resident in Poland, so automatically receives a lot of leeway in their use of idiomatic English.)

Jorengarenar8• 3 years ago

Hah, unfortunately this bit of "poetry" wasn't intentional. I just meant that C does care about whitespace, just not a lot.

zabzonk4• 3 years ago

c does care about whitespace - compare:

    int x;

with:

    intx;

teo_zero3• 3 years ago

Try removing spaces here:

  *z = *x / *y;

Or here:

  address = mask & &object;

Or here:

  a = b - --c;

teo_zero3• 3 years ago

I think the 5[arr] deserves more love.

  // traditional syntax:
  boxes[products[myorder.product].box].weight
  // index[array]:
  myorder.product[products].box[boxes].weight

Jorengarenar8• 3 years ago

Don't mind if I do

panzi2• 3 years ago

Before reading it, does it include the array[index] == index[array] thing again? reading Yep it does. :D

Razengan• 3 years ago

I wish there was a language "between" assembly and C: basically assembly with some quality-of-life improvements.

Shortcuts to reduce redundant chores (like those multiple instructions to load one 64-bit number into an ARM register) but minimal "magic" or unintended consequences as in C. Things like maybe a function call syntax like:

CALL someFunc(R1: thingForRegister1, @R7: pushR7ThenPopOnReturn, R42: [memoryAddressForR42])

and the function might be defined as:

someFunc(R1 as localNameForR1, R7 as oneMoreThing, R42? as optionalArgument)

and so on. (but anyone could come up with better ideas than me)

xigoi2• 3 years ago

I think QBE might be what you're looking for?

https://c9x.me/compile/

spc476• 3 years ago

You just need a decent assembler with macro support. Here's a few lines of code I have for 32-bit x86 code:

    PRINTF "main_task: sf=%p",ebp
    PRINTF " sf: 1=%d 2=%d 3=%d 4=%d",dword [ebp+8],dword [ebp+12],eax,ebx

I'm using NASM and it wasn't hard to write the macro to do so.

jokoon• 3 years ago

I'm currently trying to make a programming language that translates to C. I've started with a pseudo BNF parser.

I started reading the C BNF and I have to admit that I was not prepared at all. It's not as easy as it sounds.

I cannot imagine how difficult it must be to maintain a modern C++ compiler.

lionkor• 3 years ago

Yeah, good luck hahaha

There is a reason why modern languages use keywords like "func", "def", "fn", "var", "let" to discern between different types of declarations, for example. I dont think many languages are LL(k) (please correct me if im wrong), but C is as far away from that as it gets, for small k.

Gibbon12• 3 years ago

I've thought it would be nice to add func to the language. Even if it's just sugar it would help. Type inference + allowing functions to return an anonymous struct or a tuple would be super.

augustk2• 3 years ago

There are three macros which I find indispensable and which I use in all my C projects, namely LEN, NEW and NEW_ARRAY. I keep them in a file named Util.h:

  #ifndef UTIL_H
  #define UTIL_H

  #include <errno.h>
  #include <stdio.h>
  #include <stdlib.h>
  #include <string.h>

  #define LEN(arr) (sizeof (arr) / sizeof (arr)[0])

  #define NEW_ARRAY(ptr, n) \
     (ptr) = malloc((n) * sizeof (ptr)[0]); \
     if ((ptr) == NULL) { \
        fprintf(stderr, "Memory allocation failed: %s\n", strerror(errno)); \
        exit(EXIT_FAILURE); \
     }

  #define NEW(ptr) NEW_ARRAY(ptr, 1)

  #endif

With these in place, working with arrays and dynamic memory is safer, less verbose and readability is improved.

GnarfGnarf2• 3 years ago

I found a lot of bugs went away when I switched to STL (Standard Template Library) arrays and ditched managing my own memory. That's C++, I guess it's not available in straight C?

krapp• 3 years ago

That's C++, I guess it's not available in straight C?

No, because C doesn't have templates. The best you can do for a "vector" in C is macros like above, that also realloc, or write an API around structs for each type.

augustk2• 3 years ago

It's even easier if you use a garbage collector, like for instance libgc. Then you just replace

  (ptr) = malloc((n) * sizeof (ptr)[0]);

with

  (ptr) = GC_MALLOC((n) * sizeof (ptr)[0]);

in the macro and don't have to worry about calling free.

Gibbon12• 3 years ago

With gcc you can use this to get the elements of an array.

   // will barf if fed a pointer
   #define sizeof_array(arr) \
       (sizeof(arr) / sizeof((arr)[0]) \
       + sizeof(typeof(int[1 - 2 * \
       !!__builtin_types_compatible_p(typeof(arr), \
       typeof(&arr[0]))])) * 0)

mnaydin2• 3 years ago

I am not able to understand how

  int (*ap3)[900000] = malloc(sizeof *ap3);

is nicer than

  int *a = malloc(900000 * sizeof *a);

Notice that, in the former case, the array elements must be accessed as (*ap3)[i] whereas in the latter case the usual method a[i] is fine.

syockit• 3 years ago

Me neither. In the VLA use cases page he does that with multidimensional array too.

    int (*arr)[n][m] = malloc(sizeof *arr);

which you have to access with

    (*arr)[i][j]

I prefer doing

    int (*arr)[m] = malloc(n*sizeof(*arr));

though this separates m and n to be one on left side while the other on the right side, it allows me to index directly

    arr[i][j]

teo_zero3• 3 years ago

You don't use this technique to define a new array, but to get a pointer to an array you already have.

The goal is to have a pointer to the array, and not a pointer to the first element of the array.

Whether this is "nicer" or not, and whether this is what you need in your application, are out of the scope of the fine article.

michaelcampbell• 3 years ago

When I coded C my go-to for fun stuff like this was Peter Van Der Linden's "Deep C Secrets" book. One of those I don't need, but wish I hadn't sold.

ljosifov• 3 years ago

Great read, and lead me to "When VLA in C doesn't smell of rotten eggs" https://blog.joren.ga/vla-usecases and this:

  int n = 3, m = 4;
  int (*matrix_NxM)[n][m] = malloc(sizeof *matrix_NxM); // `n` and `m` are variables with dimensions known at runtime, not compile time
  if (matrix_NxM) {
      // (*matrix_NxM)[i][j] = ...;
      free(matrix_NxM);
  }

Well, that makes much easier a few things I'm doing atm, really glad I read it.

Lesser known tricks, quirks and features of C

Related Stories