<div dir="auto">Aah. Thats enlightening thank you for extremely detailed explanation. I understand better how to design my ideal complang now. <div dir="auto"><br></div><div dir="auto">Imho rust is not 100% perfect security-wise but still much better than c and c++ and still keeps those templates lambdas etc. </div><div dir="auto"><br></div><div dir="auto">Looking forward to rusts linux use. My friend is using it above embedded os from apache on riscv platform for lora board from pine.</div><div dir="auto"><br></div><div dir="auto">Id think something cycloneish or checkedcish at leash for transition time is closer hit. Im also from this old sad school of pascal delphi etc.</div><div dir="auto"><br></div><div dir="auto">Best regards,</div><div dir="auto">Pawel Kunio</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">śr., 21.04.2021, 14:27 użytkownik David Chisnall via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>> napisał:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In general, 'undefined behaviour' exists in C/C++ for things that are <br>
considered infeasible to check statically and too expensive to check <br>
dynamically. For example, accessing past the end of an array is UB <br>
because statically checking would require carrying the bounds <br>
information through every pointer cast across compilation units and <br>
tracking the range of the integers used in any array indexing or pointer <br>
arithmetic. Use after free is UB because tracking whether any alias of <br>
a given pointer has been passed to free at any point before the pointer <br>
is used.<br>
<br>
The static analyser does a lot of best-effort checks for these, but <br>
finding them all in the general case is infeasible. A few of them are <br>
trivial (in C, it is UB for your source file to not end with a newline, <br>
because YACC couldn't express EOF and so early C compilers would <br>
generate parse errors in this case. Clang and gcc can warn you about <br>
this without needing to involve the static analyser). Any work that <br>
improves the number of cases that the analyser warns (without generating <br>
many false positives) is useful, but many of these remain intractable <br>
for static analysis in the general case. Safer languages such as Rust <br>
or C++ with the Core Guidelines don't solve the general case of these <br>
problems, they just prevent people from writing (valid or invalid) <br>
programs that are not amenable to static analysis.<br>
<br>
David<br>
<br>
On 21/04/2021 13:19, pawel k. via llvm-dev wrote:<br>
> Hello,<br>
> Oh i found out its mostly or only runtime. I was thinking of something <br>
> similar but mostly or only compile-time. Its great base for my solution <br>
> though.<br>
> <br>
> Best regards,<br>
> Pawel Kunio<br>
> <br>
> śr., 21.04.2021, 10:21 użytkownik Victor Campos <<a href="mailto:victor@victorcampos.me" rel="noreferrer noreferrer" target="_blank">victor@victorcampos.me</a> <br>
> <mailto:<a href="mailto:victor@victorcampos.me" rel="noreferrer noreferrer" target="_blank">victor@victorcampos.me</a>>> napisał:<br>
> <br>
> clang -fsanitize=undefined might be what you're looking for.<br>
> <br>
> <a href="https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html" rel="noreferrer noreferrer noreferrer" target="_blank">https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html</a><br>
> <<a href="https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html" rel="noreferrer noreferrer noreferrer" target="_blank">https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html</a>><br>
> <br>
> Cheers,<br>
> Victor.<br>
> <br>
> On Wed, 21 Apr 2021, at 03:55, pawel k. via llvm-dev wrote:<br>
> > Hello,<br>
> > In previous life i knew one cybersecu bounty hunter. As a<br>
> leftover from<br>
> > then, i was wondering whether it would be useful and feasible to<br>
> have<br>
> > in clang or clang static analyzer the checks for two classes of<br>
> awkward<br>
> > types of code. Namely c++'ses 191 undefined behaviours and 52<br>
> > unspecified behaviours. That could possibly help to automatically<br>
> > pinpoint the nonportable or randomly code working only because of<br>
> > coincidence. Whether wed warn or err on such shall be up for<br>
> discussion.<br>
> ><br>
> > Sorry if that is super obvious and already implemented or np hard<br>
> or useless.<br>
> ><br>
> > If interested author of csmith might know something about full<br>
> list of<br>
> > these as he is author of randome code generator that avoids genning<br>
> > code with such artifacts.<br>
> ><br>
> > Best regards,<br>
> > Pawel Kunio<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > LLVM Developers mailing list<br>
> > <a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> <mailto:<a href="mailto:llvm-dev%2540lists.llvm.org" rel="noreferrer noreferrer" target="_blank">llvm-dev%40lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev%252540lists.llvm.org" rel="noreferrer noreferrer" target="_blank">llvm-dev%2540lists.llvm.org</a>>><br>
> > <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> <<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>><br>
> ><br>
> <br>
> <br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> <br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>