Front page | perl.perl5.porters |
Postings from December 2014
On Fri, Dec 05, 2014 at 10:44:52AM -0500, George Greer wrote:
> Perl isn't "sanitize=undefined" clean so it would always fail. I suppose I
> could turn it on but not Cc: p5p, which would be useful. I'll do that
> tonight.
With these commits, it now passes all tests (but with zillions of run-time
warnings still):
db58a81 fix integer overflow in S_regpiece().
a1b2073 fix integer overflow in S_study_chunk().
55b6a5f fix integer overflow in S_study_chunk().
646e8787 fix integer overflow in S_scan_commit().
2e2c882 add asan_ignore - which errors to ignore
But you'll have to modify the build flags you use; to quote that first
commit:
commit 2e2c882dd53d6b966a0cd3b0ef111ff9e85f2c41
Author: David Mitchell <davem@iabyn.com>
AuthorDate: Fri Dec 19 20:31:00 2014 +0000
Commit: David Mitchell <davem@iabyn.com>
CommitDate: Fri Dec 19 21:49:55 2014 +0000
add asan_ignore - which errors to ignore
"clang -fsanitize=undefined" produces lots of false positives.
This file allows certain functions to be excluded from checking.
Use it as:
clang -fsanitize=undefined -fsanitize-blacklist=`pwd`/asan_ignore
create mode 100644 asan_ignore
Affected files ...
M MANIFEST
A asan_ignore
and to quote asan_ignore:
# This file intended to be used with clang as
#
# clang -fsanitize=foo -fsanitize-blacklist=`pwd`/asan_ignore
#
# It lists those files / functions that clang's Address Sanitizer should
# ignore.
#
# See http://clang.llvm.org/docs/SanitizerSpecialCaseList.html.
# The pp functions used under 'use integer' shouldn't warn about
# integer overflow etc.
#
# Unfortunately there doesn't seem to be any way to disable just specific
# errors (i.e. the integer overflow ones). The manual implies that you can
# suffix with =foo for a "tool-specific category", but neither =undefined
# nor =signed-integer-overflow worked.
fun:Perl_pp_i_*
--
A power surge on the Bridge is rapidly and correctly diagnosed as a faulty
capacitor by the highly-trained and competent engineering staff.
-- Things That Never Happen in "Star Trek" #9
Thread Previous
|
Thread Next