develooper Front page | perl.perl5.porters | Postings from May 2019

[perl #134044] Current perl undefined C behaviors

From:
Karl Williamson via RT
Date:
May 9, 2019 15:43
Subject:
[perl #134044] Current perl undefined C behaviors
Message ID:
rt-4.0.24-466-1557416602-882.134044-15-0@perl.org
On Sat, 04 May 2019 18:16:11 -0700, jkeenan wrote:
> On Fri, 03 May 2019 21:22:07 GMT, public@khwilliamson.com wrote:
> > On 4/18/19 2:16 AM, Dave Mitchell via RT wrote:
> > > On Wed, Apr 17, 2019 at 07:56:02PM -0700, karl williamson (via RT)
> > > wrote:
> > >> # New Ticket Created by  karl williamson
> > >> # Please include the string:  [perl #134044]
> > >> # in the subject line of all future correspondence about this
> > >> issue.
> > >> # <URL: https://rt.perl.org/Ticket/Display.html?id=134044 >
> > >>
> > >>
> > >> I ran clang sanitize=undefined on current perl blead.
> > >>
> > >> Attached is a file containing the failures.  It is in the form of
> > >> a
> > >> patch (not intended to be applied) of a typical error message from
> > >> asan
> > >> as a comment preceding the line where the problem occurs in the
> > >> code.
> > >>
> > >> On #irc, Tony Cook pointed out that probably the integer overflows
> > >> are
> > >> ok due to our use of -fwrapv.
> > >
> > > ...
> > >
> > >> @@ -2618,6 +2631,9 @@ PP(pp_i_multiply)
> > >
> > > Note that in general we expect the 'use integer' variants of the
> > > arithmetic functions to have have undefined behaviour because it's
> > > kind of
> > > what they're documented to do.
> > >
> > > There's a file in the top-level dir of the perl src: asan_ignore,
> > > which is designed to tell ASan what functions to ignore for errors.
> > > You need to invoke clang with something like:
> > >
> > > -fsanitize-blacklist=`pwd`/asan_ignore
> > >
> >
> > In collaboration with sisyphus, I worked through all the undefined
> > behaviors, solving the ones that weren't integer overflow.
> >
> > But he and I are confused.  Various sources say such behaviors should
> > be
> > avoided at all costs.  -fwrapv should take care of the integer
> > overflow
> > ones.  But asan provides a black list facility so as to not generate
> > warnings for these, so it must be understood that they can happen.
> > And
> > if you're running, for example, strtod() on user supplied input, they
> > can supply something that will overflow.
> >
> > I couldn't find any documentation that says our shifting follows C
> > rules
> > (or non-rules).
> >
> > Attached are patches that fix the issues.  I think the first at least
> > should go into 5.30 if the warnings about undefined behavior are to
> > be
> > believed.  These appear to be newer than when asan_ignore was last
> > updated.
> >
> 
> Did they occur within the 5.29 dev cycle?  If not, then I don't think
> they should be classified as blockers.

These did not occur in the 5.29 dev cycle, so I'm removing this ticket from the blockers list.  In fact, looking at 5.28, the 5.29 cycle inadvertently removed other undefined behaviors.
> 
> 
> > The second patch fixes the left shifting of a negative value simply
> > by
> > adding some casts, and treating IV_MIN specially.  It appears from
> > asan_ignore that this undefined behavior was to be ignored.  But
> > there
> > was apparently a restructuring of the code so the directive to ignore
> > things no longer applied.  Given that the intent was to ignore these,
> > and it's been this way for a long time, I don't claim that this
> > should
> > go into 5.30.
> 
> Thank you very much.


-- 
Karl Williamson

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=134044



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About