Date: Wed, 06 Jul 2016 11:46:23 +0000 From: bugzilla-noreply@freebsd.org To: perl@FreeBSD.org Subject: [Bug 210837] lang/perl5.22 (and related?): ext/re/re_exec.c has long long format matched up with long argument Message-ID: <bug-210837-14331-J2J86cEtLd@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-210837-14331@https.bugs.freebsd.org/bugzilla/> References: <bug-210837-14331@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210837 --- Comment #9 from Mark Millard <markmi@dsl-only.net> --- (In reply to Mathieu Arnold from comment #7) I quoted the code in question and then I said of it: "the IVdf vs. (long)(rx_origin - strbeg) do not match types" That is a (too short?) description of a way of being broken: it indicates t= hat the compiler's report was not a false positive. In 32-bit long / 64-bit long long contexts the IVdf format uses more bytes = (for long long) then are put out on the stack for the value (long), picking out = some other bytes from memory as well. The details of the bad bytes use depends on big-endian vs. little-endian (or other memory layouts for such values). For little-endian if the extra bytes are zero bytes then the values would look okay. Otherwise not. The operational difficulty for live testing comes in knowing how to reach t= he problem code in order to see the bad result. I'm not so sure that I'm likel= y to hit the broken code in the implicit use of perl5 in my context. (perl5 was built because of dependencies, not because I directly built it f= or my own use.) amd64 and powerpc64 would not be observably broken (long is also 64 bits). powerpc would be broken (long is 32-bits and poewrpc is big-endian). armv6 would depends on if the extra bytes at the time happened to be zeros (long = is 32 bits little-endian). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-210837-14331-J2J86cEtLd>