
So you think you know C? - pjmlp
https://medium.com/@okaleniuk/so-you-think-you-know-c-8d4e2cd6f6a6#.eogq49y4a
======
shakna
I can't answer to the C spec, because so much is left undefined, but I can
answer some to GCC and tcc, and that tells me that though these are contrived
examples, I've encountered at least some of these in the wild.

I can't wait till rustc prodyces smaller executables so I can switch to it.

~~~
geofft
I believe rustc produces pretty small executables if you allow it to
dynamically link libstd. C gets two advantages over Rust, one fair and one
slightly unfair: it has a stable binary ABI, and the standard C library is
already installed everywhere. If you're using Rust for internal use, you can
probably figure out a distribution mechanism for every libstd version in use,
because you probably only have very few in use at any given time, and you can
rustc -C prefer-dynamic. (For instance, Debian in fact builds a normal library
package for each libstd for each compiler release they package, which would
probably work.)

~~~
shakna
Unfortunately dynamic doesn't work for me.

I use musl day-to-day to cross compile statically linked executables, which
tend to be 1500kb or so. (Embedded systems with around 10mb of memory or
less).

I used to bash glibc into compliance, and musl was like a gift from heaven.

Unfortunately rustc isn't there yet - though it is on the radar for the
future.

~~~
dbaupp
Have you seen that rustup makes using musl with rustc _really_ easy [0]? One
can then additionally forgo things like the optimised jemalloc allocator and
the main standard library (just using libcore) to knock the binary size down
to what C gives. [0] discusses this in much more detail (especially towards
the end).

[0]: [https://blog.rust-lang.org/2016/05/13/rustup.html#example-
bu...](https://blog.rust-lang.org/2016/05/13/rustup.html#example-building-
static-binaries-on-linux)

[1]: [https://lifthrasiir.github.io/rustlog/why-is-a-rust-
executab...](https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-
large.html)

~~~
shakna
> Today rustup provides access to the standard library, but as we’ve seen in
> this post, there’s more to cross-compilation than rustc + std. It’s
> acquiring and configuring the linker and C toolchain that is the most vexing

Unfortunately I'd have to agree with this, C is just easier.

> We have knocked debug symbols down, now let’s get rid of the remaining
> libraries. Some bad news: From this point on you are entering the realm of
> nightly Rust. This realm is not as scary as you might think, as it doesn't
> break in your face, but it may break in smaller ways (which is why we have
> nightlies!). That’s the major reason that we don’t yet have nightly features
> in stable– they may change.

Relying on a nightly for production code is simply not something I would ever
get approved.

I sort of hope that as Rust solves these issues, tools like rustup and Cargo
will get to the state of Red and its cross-compilation state. (Compile for
Linux-86, Linux-ARM, Windows, macOS, Android with one flag from the one
compiler. Which is less than 1mb, statically linked.)

------
jimjag
This basically sez 'Don't assume a specific answer when something is
undefined'. As long as you don't, and experienced C programmers don't, then
what is the big deal?

~~~
rayiner
> experienced C programmers don't

C leaves _a lot_ undefined. These were tiny examples, and many were undefined
for more than one reason. Experienced C programmers rely on undefined behavior
all the time:
[http://www.metzdowd.com/pipermail/cryptography/2015-October/...](http://www.metzdowd.com/pipermail/cryptography/2015-October/026841.html).

------
kevin_b_er
The answer to #3 is a compiler error. char a = ‘ ‘ * 13; is not a valid line
of C, the compiler will fault for having a left single quotation mark in the
line.

The author or Medium corrupted their line of C with pretty printing
operations.

