5 ms·
In either case dereferencing a null pointer would still be a bug, right? Or is it kind of "all bets are off" if you feed LLVM bad IR and don't enable verificati
by EE84M3i 5y ago
In either case dereferencing a null pointer would still be a bug, right? Or is it kind of "all bets are off" if you feed LLVM bad IR and don't enable verification?
- comex 5y agoIt is.
- eyelidlessness 5y agoTerse affirmative is ambiguous.
- nlewycky 5y agoIf you feed LLVM bad IR, all bets are off. LLVM's assertions and IR verifier are impressively comprehensive, but not a guarantee. For example, LLVM has a pointer type and a void type, but you may not make a pointer-to-void type, see https://llvm.org/docs/LangRef.html#pointer-type https://llvm.org/docs/LangRef.html#pointer-type . If you do call `Type::getVoidTy(C)->getPointerTo()` then LLVM will hit an assertion only in a build with assertions enabled. Without assertions LLVM may silently execute UB.
- akimball 5y agoAs are all tautologies;)
- theresistor 5y agoLLVM makes use of assertions to validate things like this, but many users of LLVM, including rustc, turn them off for performance reasons.
- mshockwave 5y agoLLVM makes trade off on enabling/disabling certain checks, including assertions and IR verification, primarily to keep compilation time acceptable in release build. The idea is that we catch as many bugs as possible in debug version of LLVM such that release version can run fast.
- tedunangst 5y agoIf you call free((void *)-1) in C code, it will very likely crash, but it will crash in libc, not your program. Is that a bug in libc?
- Thorrez 5y agoThat's documented undefined behavior. Is it documented undefined behavior to feed bad IR into LLVM?
- scatters 5y agoOf course. If there's an input checking mode, and you disable the checks, then you're guaranteeing that you won't supply invalid input.
- MaxBarraclough 5y agoI think even deriving the argument might invoke undefined behaviour here, but I'm not certain. If I understand correctly, it's undefined behaviour to do this: int *ptr = (int*)42; As, in order to avoid undefined behaviour, ptr should only be assigned a valid address of an int, or the 'address' one past the end of an array of int, or NULL (logical zero). It's possible things are different when the type is void*, I'm not certain.
- tedunangst 5y agoMake it free(free) if you want it to be a valid pointer.
- kelnos 5y agoNo, because the defined contract for free() is that you pass it a pointer that was previously returned from malloc(), that you don't try to free() it twice, etc.