Comments by "MrAbrazildo" (@MrAbrazildo) on "C Must Die" video.

  1. 34:00, I'm not following the point here. What I heard about this happens when 2 pointers may -> to the same address. It's not the case of int and double. I'm not have been following C, but speaking for C++, this is accepted, even with the same type. The issue is that C++ might lose performance: void f(int *x, int *y) { // They may -> to same address. *y = 3; // It might be indirectly making *x = 3 at the same time too! *x = *x + 2; } It loses performance: each time 1 of these pointers appear, it must seek the pointed address, instead of working with their value on CPU registers! Easy portable fix: if they are not const, copy their values to local variables, and bingo: ~12x faster! Nonportable fix: compilers have different attributes, holding/pairing those parameters. Clang compiler has a tool to report if it's losing this performance. 1 can go to compilerexplorer.org(?), put the f() there, select Clang with -OX, and there's an option I don't remember where, which will say "variable clubbered by" something, when it couldn't optimize. However, I think this is an issue only when compiling part of the code. Otherwise, the compiler should be able to track all the pointer steps, knowing for sure if 2 of them point to the same place.
    1
  2. 10:10, Clang compiler has a tool to "trap" overflow and UB. So it'd halt this app. Case closed. 11:33, it's UB because "it doesn't make sense to do that". If 1 wants to 0 the var, just attrib. that value. Or if wants to rotate, which is a slow operation, use a 3rd party lib. for that, or write your own. C doesn't want to lose precious time checking that. And I think the lang. is right about that. This could be avoided by the discipline of using 'assert' f() call before any operation. C++ offers an even more interesting option: wrap the var into a class, making the assert calls implicit/automatic, meaning: even when you forget them! Remembering that even on C those assert calls execution can vanish by just #define-ing NDEBUG. So, for releasing version, they won't take performance. 16:14, hmm... delicious. Bookmarked to read later. 18:47, in C++ 1 can make a class, holding a pointer, which always automatically check to forbid it to be nullptr. It was even already deployed, on the GSL lib, to reinforce C++ Core Guidelines. 23:00, he's wrong because, despite the ptr_byte is "walking over the ptr mem", it's always taking the least byte from value. memset is not forcing him to use the least byte: he used that, instead of the entire value. The result was actually: memset (ptr, (unsigned char) value, num); 28:50, this may be C-only. I never saw this in C++.
    1
  3. 39:53, it's comparing the addresses they are pointing to, which should be y's, if x and y are in this sequence. 41:50, 0x7fff'ffff + 100 is UB, invading the bit for the sign area. The right way to write that check would be: assert (0x7fff'ffff - 100 >= a); And I guess the standard <stdint.c> lib has INT_MAX (or alike) constant for that max value, which should be used instead. Plus, there's an UB on main too: not returning an int, when promised that. However, there's a compiler flag to catch that. 46:00, it's broken, because an UB was created BEFORE even the check for UB was complete! 48:35, precisely. 53:49, I disagree, because it's inflicting the compiler's freedom. Let's say a compiler deploys signed 32 bits represented as 31 bits, with the signal being kept somewhere else. This unnecessary way of checking might create unnecessary problems.
    1