3 ms·

I remember the first time I read about this technique used by the Linux kernel to find the \0 at the end of the string. If course XORing with another char will

I remember the first time I read about this technique used by the Linux kernel to find the \0 at the end of the string. If course XORing with another char will detect that char instead. But before you run to implement it as a drop-in replacement for strlen() all over your code, please note that in real-world cases the string length is not guaranteed to be a multiple of 8. When you read the last long, you might overrun your memory buffer and trigger a page fault.

Karellen 3y ago
> When you read the last long, you might overrun your memory buffer and trigger a page fault. You know that page boundaries are always on a `PAGE_SIZE` alignment, which you can get with `getpagesize()` or `sysconf(_SC_PAGESIZE)`. ...but overrunning the declared size of a memory allocation is still UB, even if you don't trigger a page fault, so YMMV ;-)
- o11c 3y ago
  Also, as I learned recently: UB minor faults are allowed to change under you. You're not guaranteed to get the same value next time you access them, even if nothing else in your process is touching that memory.
  - Karellen 3y ago
    Anything is allowed to happen if your program invokes UB. All bets are off (according to the C standard/abstract machine) for the rest of the runtime of your program, from the first time it happens. In fact, because the compiler is allowed to re-order your program provided that the end result of any non-UB computation is the same (the "as-if" rule[0]), if part of your program invokes UB, it's possible for that to "reach backwards" and invalidate computations that appear to happen before the UB is/was invoked (by a straightforward reading of the source code). [0] https://en.wikipedia.org/wiki/As-if_rule https://en.wikipedia.org/wiki/As-if_rule
    - o11c 3y ago
      My point is: we normally speak of UB as a C-source-specific thing. But some UB exists even in compiled code from any language.
      - Karellen 3y ago
        That's because UB has a well-defined meaning in the C programming language specification, for over 35 years now. And C has been one of the most widespread programming languages in use over that time. One of the important things about UB and C is that C is a language defined by a standard, not any one compiler - and there are a lot of compilers. If a C compiler does something weird with your source code, we can say whether the compiler is correct or not, or whether your code is at fault. For many languages, that is not the case, and "whatever the compiler does to your code" is de facto correct, and "whatever the compiled version of your code happens to do on any given platform" is well-defined, even if it wasn't what you meant. I'd argue that if a compiled language does not define what it means by UB, it doesn't have "UB". But also, if a person talks about "UB", it is reasonable for a listener to assume they are by default talking about the well-defined term in the C programming language standard - unless they specify otherwise. Because that's the most enduring definition of the term we have.

Karellen 3y ago

> When you read the last long, you might overrun your memory buffer and trigger a page fault. You know that page boundaries are always on a `PAGE_SIZE` alignment, which you can get with `getpagesize()` or `sysconf(_SC_PAGESIZE)`. ...but overrunning the declared size of a memory allocation is still UB, even if you don't trigger a page fault, so YMMV ;-)

o11c 3y ago
Also, as I learned recently: UB minor faults are allowed to change under you. You're not guaranteed to get the same value next time you access them, even if nothing else in your process is touching that memory.
- Karellen 3y ago
  Anything is allowed to happen if your program invokes UB. All bets are off (according to the C standard/abstract machine) for the rest of the runtime of your program, from the first time it happens. In fact, because the compiler is allowed to re-order your program provided that the end result of any non-UB computation is the same (the "as-if" rule[0]), if part of your program invokes UB, it's possible for that to "reach backwards" and invalidate computations that appear to happen before the UB is/was invoked (by a straightforward reading of the source code). [0] https://en.wikipedia.org/wiki/As-if_rule https://en.wikipedia.org/wiki/As-if_rule
  - o11c 3y ago
    My point is: we normally speak of UB as a C-source-specific thing. But some UB exists even in compiled code from any language.
    - Karellen 3y ago
      That's because UB has a well-defined meaning in the C programming language specification, for over 35 years now. And C has been one of the most widespread programming languages in use over that time. One of the important things about UB and C is that C is a language defined by a standard, not any one compiler - and there are a lot of compilers. If a C compiler does something weird with your source code, we can say whether the compiler is correct or not, or whether your code is at fault. For many languages, that is not the case, and "whatever the compiler does to your code" is de facto correct, and "whatever the compiled version of your code happens to do on any given platform" is well-defined, even if it wasn't what you meant. I'd argue that if a compiled language does not define what it means by UB, it doesn't have "UB". But also, if a person talks about "UB", it is reasonable for a listener to assume they are by default talking about the well-defined term in the C programming language standard - unless they specify otherwise. Because that's the most enduring definition of the term we have.