[llvm-dev] Noob question from friend of cybersecu guy

[pawel k. via llvm-dev]

Aah. Thats enlightening thank you for extremely detailed explanation. I
understand better how to design my ideal complang now.

Imho rust is not 100% perfect security-wise but still much better than c
and c++ and still keeps those templates lambdas etc.

Looking forward to rusts linux use. My friend is using it above embedded os
from apache on riscv platform for lora board from pine.

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.

Best regards,
Pawel Kunio

śr., 21.04.2021, 14:27 użytkownik David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org> napisał:

> In general, 'undefined behaviour' exists in C/C++ for things that are
> considered infeasible to check statically and too expensive to check
> dynamically.  For example, accessing past the end of an array is UB
> because statically checking would require carrying the bounds
> information through every pointer cast across compilation units and
> tracking the range of the integers used in any array indexing or pointer
> arithmetic.  Use after free is UB because tracking whether any alias of
> a given pointer has been passed to free at any point before the pointer
> is used.
>
> The static analyser does a lot of best-effort checks for these, but
> finding them all in the general case is infeasible.  A few of them are
> trivial (in C, it is UB for your source file to not end with a newline,
> because YACC couldn't express EOF and so early C compilers would
> generate parse errors in this case.  Clang and gcc can warn you about
> this without needing to involve the static analyser).  Any work that
> improves the number of cases that the analyser warns (without generating
> many false positives) is useful, but many of these remain intractable
> for static analysis in the general case.  Safer languages such as Rust
> or C++ with the Core Guidelines don't solve the general case of these
> problems, they just prevent people from writing (valid or invalid)
> programs that are not amenable to static analysis.
>
> David
>
> On 21/04/2021 13:19, pawel k. via llvm-dev wrote:
> > Hello,
> > Oh i found out its mostly or only runtime. I was thinking of something
> > similar but mostly or only compile-time. Its great base for my solution
> > though.
> >
> > Best regards,
> > Pawel Kunio
> >
> > śr., 21.04.2021, 10:21 użytkownik Victor Campos <victor at victorcampos.me
> > <mailto:victor at victorcampos.me>> napisał:
> >
> >     clang -fsanitize=undefined might be what you're looking for.
> >
> >     https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
> >     <https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html>
> >
> >     Cheers,
> >     Victor.
> >
> >     On Wed, 21 Apr 2021, at 03:55, pawel k. via llvm-dev wrote:
> >      > Hello,
> >      > In previous life i knew one cybersecu bounty hunter. As a
> >     leftover from
> >      > then, i was wondering whether it would be useful and feasible to
> >     have
> >      > in clang or clang static analyzer the checks for two classes of
> >     awkward
> >      > types of code. Namely c++'ses 191 undefined behaviours and 52
> >      > unspecified behaviours. That could possibly help to automatically
> >      > pinpoint the nonportable or randomly code working only because of
> >      > coincidence. Whether wed warn or err on such shall be up for
> >     discussion.
> >      >
> >      > Sorry if that is super obvious and already implemented or np hard
> >     or useless.
> >      >
> >      > If interested author of csmith might know something about full
> >     list of
> >      > these as he is author of randome code generator that avoids
> genning
> >      > code with such artifacts.
> >      >
> >      > Best regards,
> >      > Pawel Kunio
> >      >
> >      >
> >      > _______________________________________________
> >      > LLVM Developers mailing list
> >      > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> >     <mailto:llvm-dev%40lists.llvm.org <mailto:
> llvm-dev%2540lists.llvm.org>>
> >      > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >     <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> >      >
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210421/6dd3bf9b/attachment-0001.html>