Actually strnlen is only POSIX, not plain C, so -> if (!memchr(s, 0, 100))
-
-
Show this threadThanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
That requires a compiler with knowledge over specific fn calls. I can see that easily done on LLVM, but it feels like bloating the compile process. I’d rather see some form of “lint” doing the same thing.
-
The std functions are part of the language and gcc and clang already know about them.
-
The compiler and the stdlib are independently provided, and the stdlib is technically optional - specially important when dealing with embedded platforms - or an OS kernel.
-
Most is "optional" (not included in the spec) in a freestanding implementation. GCC and clang already honor -ffreestanding for this and omit special treatment of std functions then.
-
If you're compiling a kernel or libc without -ffreestanding that's a bug; they'll already make transformations that can break your code (like recursive self-calls).
-
-ffreestanding may suppress optimizations that introduce new stdlib calls, but isn’t it still UB for a function to be defined with the same name as a stdlib function and not have the same semantics? Dunno if gcc or clang exercise that even if so though
End of conversation
New conversation -
-
-
it's a good shortcut. you know of codes where this would make a noticeable difference?
-
It's mainly hardening against extra linear factors (increased polynomial order) via untrusted inputs.
-
Wonder if there's code that relies on the trailing memory getting touched...
-
It's possible there is, but if so this code is broken. The compiler is free to optimize out dead loads, which is ultimately what this is (if you think of it as inlining and unrolling the strlen).
-
Cut to 2028: committee fixes this “bug” by making all string functions take volatile pointers.
-
2029: volatile pointers to volatile contents
-
static volatile functions will solve this problem
- 2 more replies
New conversation -
-
-
If "s" is between 1 and 100 bytes longer than the range of size_t, is this defined as true, or is strlen() itself undefined for this case? (I don't see this case explicitly covered in C99 std, but strlen returns size_t, not ssize_t, so I would assume overflow is well defined?)
-
there's no way to create an object larger than the range of size_t in C, and how would you access all of it if there were? And some implementations (musl) only allow allocations in the range of ssize_t.
-
I don't think size_t is required to be the same size as a pointer. You might not be able to create such a large string yourself on the heap, but that doesn't mean it can't already exist...
-
size_t is an unsigned integer type for representing the size of an object. The standard is poorly vague about what requirements that imposes, but any interpretation allowing objects whose size it can't represent is a critically broken one.
End of conversation
New conversation -
-
-
That's an easy Coccinelle script, though.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
