Live data from Hacker News

Beej’s Guide to C Programming [pdf]

beej.us

161–170 of 178 posts

Re: Beej’s Guide to C Programming [pdf]

#161
post #133

Earlier quoted context omitted.

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?

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 co…

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.

Re: Beej’s Guide to C Programming [pdf]

#163
post #133

Earlier quoted context omitted.

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?

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 co…

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.

Re: Beej’s Guide to C Programming [pdf]

#164
post #127

Earlier quoted context omitted.

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?

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

Re: Beej’s Guide to C Programming [pdf]

#165
post #159

Earlier quoted context omitted.

No type safety and broken alignment. No thanks.

Isn’t it type safe? e.g you can’t add char* to a double array. What do you mean by broken alignment?

It lacks type safety because it's not possible to distinguish between an sc_array and a pointer so there's no way of detecting that someone passed a char * that nobody had ever called sc_array_create on to sc_array_add for example.

The alignment is broken because nothing in the C standard guarantees that the elems member of sc_array will be aligned correctly for any possible element type.

I also spotted another problem, in sc_array_init the code `void *p = a` is also not guaranteed to work. In an example snippet such as `int iv; sc_array_create(iv, 0);` expands to `sc_array_init(&iv, sizeof iv, 0)` so the type of the expression `&iv` is `int *` which is then being converted to `void *` in the function which is actually not allowed by the standard. This is also the reason why if you were writing a wrapper around realloc which exited if the allocation failed you would still have to pass in the current pointer with void * and return the new pointer with void *. This could be applied here actually as an easy fix but it indicates even further to me that the author of the library is taking a very leisurely approach to writing conforming C. This pattern also appears in the other two functions though and I'm not sure if in those cases it's something which can be easily fixed.

Re: Beej’s Guide to C Programming [pdf]

#166

Earlier quoted context omitted.

Treating C as an abstraction over assembly is a surefire way to step into all the thousands of sharp edges C has. In fact I would hazard a guess that the majority of bugs found in software written in C are a result of programmers treating it as a portable assembler instead of a language for programming an abstract machine. So many incorrect assumptions arise as a result of telling people to treat C as a portable asse…

I was discussing pointers. I only commented in passing about C being portable over assembler. You could rephrase this as it being a language for programming an abstract machine and it would not change anything about my comment (nor would it change the fact that C is an abstraction over assembly) Thank you for your reply...

The fact that you didn't use the term "portable assembler" when saying: "If you take a concrete example where memory is effectively an array and indices are addresses (which holds true for most cases and, in any case is a good example)" doesn't change the fact that the statement makes links to how actual machine memory operates on what you personally think is a usual machine. This is really not a good idea because it encourages people to think of pointers as all existing in the same place and encourages erroneous thinking such as subtracting two pointers to different objects or confusion surrounding why the numbers you get when you `int a; char b; printf("%p, %p\n%p, %p\n", &a, &a+1, &b, &b+1);` differ in separation. Also subtler errors arise such as people assuming that all pointer types are effectively equal as long as you convert back to the correct pointer type when it comes to using the pointer (really subtle issues like people assuming that you can convert `int *` to `void *` safely).

The "very abstract" way C is taught actually prevents people from making such assumptions by not priming them to make them. The fact that people get complacent and start to lean on their understanding of (what they think are) real machines to write C is the result of the bugs I mentioned in the previous response.

Re: Beej’s Guide to C Programming [pdf]

#167

Earlier quoted context omitted.

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.

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

Re: Beej’s Guide to C Programming [pdf]

#168
post #28

Earlier quoted context omitted.

These are good points. I can sometimes feel that Python is more pointer-y (?) than people expect, with stuff like: a = {"one": 1, "two": 2 } b = a b["two"] = 99 print(a["two"]) The above prints 99, since "b = a" does not copy the value (the dictionary) but just the reference to the value ("the pointer", kind of). This is surprising to some people.

Reminds me of the Python trap that I fall into every few months because I forget about it: def foo(mylist=[]): mylist.append("a") return mylist mylist is only initialized once, so the function will actually return one more "a" with each function execution

It's a feature! Use this memoization pattern and you'll never forget it

  def foo(x, cache={}):
    if x in cache:
      return cache[x]
    val = cache[x] = x*x+1
    return val
But, be warned, there's no mechanism for cache eviction; use @lru_cache if you don't know ahead of time that x will take a reasonably small number of values

Re: Beej’s Guide to C Programming [pdf]

#169
post #155

Earlier quoted context omitted.

Just wanted to say THANK YOU as I read your guide to network programming way back in 2000, over 20 years ago! I was just starting out in C network programming on VxWorks :) Glad to see you're still updating your guides.

Thanks! Makes my day to hear people find the work useful. :)

+1000 - I used your network programming guide extensively for my Computer Networking final project in 96, invaluable, Thankyou!

Re: Beej’s Guide to C Programming [pdf]

#170
post #163
post #133

Earlier quoted context omitted.

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 co…

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.

Post reply on HN