Hacker News Reader

Comment by signa11 | Hacker News Reader

Jens Gustedt's "Modern C" (https://modernc.gforge.inria.fr) is an excellent resource as well.

Jens Gustedt is a co-editor of the ISO C standard, so he knows his shit. Modern C is probably the best book about modern C, short of reading the standard.

It's far easier to read than the standard, too, since it's explanatory rather than declaratory. The standard tells you what C can do, Modern C teaches you how.

What does "modern" C imply? AFAIK, there are not very many new language features; is it about organizing code differently than what one would learn from K&R?

I'm chuckling to myself at "there are not many new language features" because that's what I thought.

There's fair amount added to the core since C89, actually... And if you include the library changes, game over! I had no idea how much had been added.

More challenging is to find what's been subtracted.

This no longer defaults to int:

static i;

And gets() is toast.

Anyone know any others?

Array initializers! Lots of changes there. Oh, things subtracted? Wasn't there a change in typedef vs type tags?

VLAs, made optional in C11, so compilers that jumped from C89 to C11, like on embedded space, or MSVC, never bothered with supporting them.

Apart from the new features added in C11 or C17 that others have mentioned, both Beej's Guide and Modern C also cover threads and string encoding (neither of these topics are covered in K&R 2nd edition, as far as I remember). Beej's Guide also has a section on internationalization and one about date/time handling.

But yes, the code is also quite different than in K&R which is relatively terse. See for example this comment in K&R about strcpy on print page 105 (page 119 of the PDF)[1], where after showing two versions of strcpy that are pretty readable and easy to follow, the book says:

> In practice, strcpy would not be written as we showed it above. Experienced C programmers would prefer

    void strcpy(char *s, char *t)
    {
        while ((*s++ = *t++) != '\0')
            ;
    }

Followed by a paragraph saying the condition could be simplified, and that

> the function would likely be written as

    void strcpy(char *s, char *t)
    {
        while (*s++ = *t++)
            ;
    }

Make of that what you will :-)

[1] https://kremlin.cc/k&r.pdf#page=119

While experienced C programmers that care about security wouldn't even touch strcpy().

All those code samples will crash and burn if s and t point to the wrong locations, t happens to point to a string without a null terminator, or s points to a buffer not big enough to handle the string pointed by t.

> All those code samples will crash and burn if s and t point to the wrong locations

This is true for all uses of pointers in C. The only validation you can do is whether a pointer is null. Apart from that you can never know that a pointer points to a non-wrong location. And still experienced C programmers seem to be OK with using pointers.

Actually no, many OSes do have APIs to validate pointer integrity.

But even then, most experienced C programmers don't care about using them anyway, that is why Apple, Oracle, Microsoft, ARM, Google, Cambridge university are all leading efforts for hardware memory tagging.

So it won't matter how much they care, as the OS will kill their beloved application when pointers get misused.

A scenario already made reality in platforms like Solaris SPARC.

> many OSes

Are outside the scope of the C language. But if you allow these special APIs, you can use them to implement a safe strcpy. Either way your point from above is still invalid.

I know that

    while (*s++ = *t++);

is the type of thing seemingly designed to reach through history to make a modern programmer spit out their tea — but I also can’t help but feel that it’s a very direct “C machine” representation of the semantics of a processor string instruction, ala x86’s REPNZ MOVSB.

According to the introduction of the book, C17. Which is mostly just bugfixes on C11. But, compared to c99, you get nice things like generic expressions, better unicode, and (standard) multithreading.

> But, compared to c99, you get nice things like generic expressions

I'd have a hard time calling the way they designed _Generic "a nice thing" :-)

C99 I would imagine: https://en.wikipedia.org/wiki/C99

The current standard is C17, of course: https://en.m.wikipedia.org/wiki/C17_(C_standard_revision).

Nice book. As a C++ programmer how much of its discussion related to C's storage/memory model would carry over to C++?

All of it. C++ is a superset of C.

Others disagree: https://mcla.ug/blog/cpp-is-not-a-superset-of-c.html

You don't really have to ask others. The C and C++ standard disagree, you can easily find instances of this disagreement if you just peruse them. The easiest example to find is the difference in behavior of the auto keyword or in how conversions from void * to something_else * are implicit in C not in C++. There's now also an extreme number of subtleties in terms of undefined behavior which differ between the languages.

And even if it was, the idioms would still be different. Even if yaml is a superset of JSON, you wouldn't apply JSON pattern (eg. Using a "_comment" key for comments) to yaml. And similarly, many of the JavaScript design pattern won't apply to typescript because it has language features instead of conventions.

Bjarne Stroustrup, C++ creator, disagrees, IIRC. Think I read it on his site.

Edit:

https://www.stroustrup.com/bs_faq.html#C-is-subset

>Please note that "C" in the paragraphs above refers to Classic C and C89. C++ is not a descendant of C99; C++ and C99 are siblings.

foo_t foo = {.bar=1} ; doesn't work in C++.

Reply on news.ycombinator.com