search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.91k stars 542 forks source link

vec assignments generate 2 warnings, I'd prefer none #5502

Closed p5pRT closed 12 years ago

p5pRT commented 22 years ago

Migrated from rt.perl.org#9423 (status was 'resolved')

Searchable as RT9423$

p5pRT commented 22 years ago

From dcd@tc.fluke.com

Created by dcd@tc.fluke.com

The following script issues warnings (2 of them) for vec assignments\, while normal assignments to scalars don't generate any warnings. Since perl guarantees that the extra bits are filled with zeros\, I believe it should not issue these warnings.

While the script demonstrates simple cases\, the testing if the hash element exists and pre-initializing it before the vec assignment complicates production scripts\, and I'd strongly prefer to avoid "no warnings".

Use of uninitialized value in vec at vec_warn.pl line 16. Use of uninitialized value in scalar assignment at vec_warn.pl line 16. Use of uninitialized value in vec at vec_warn.pl line 17. Use of uninitialized value in scalar assignment at vec_warn.pl line 17.

$ cat vec_warn.pl

use warnings; use strict;

my ($s\, %sh); $s = 1; $sh{foo} = 1;

#If an element off the end of #the string is written to\, Perl will first extend #the string with sufficiently many zero bytes. # yet perl generates 2 warnings each for the following 2 vec assignments. # Use of uninitialized value in vec # Use of uninitialized value in scalar assignment my ($v\, %vh); vec($v\,0\,1) = 1; vec($vh{foo}\,0\,1) = 1;

# to avoid warnings must pre-init vectors

my ($wv\, %wvh); $wv = $wvh{foo} = ''; vec($wv\,0\,1) = 1; vec($wvh{foo}\,0\,1) = 1;

Perl Info ``` Flags: category=core severity=medium Site configuration information for perl v5.7.3: Configured by dcd at Tue May 28 12:01:59 PDT 2002. Summary of my perl5 (revision 5.0 version 7 subversion 3 patch 16840) configuration: Platform: osname=linux, osvers=2.4.19-pre8-ac4, archname=i686-linux uname='linux dd 2.4.19-pre8-ac4 #1 thu may 16 10:27:27 pdt 2002 i686 ' config_args='-Dmksymlinks -Dinstallusrbinperl -Uversiononly -Dusedevel -Doptimize=-O3 -g -de -Dcf_email=dcd@tc.fluke.com' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O3 -g', cppflags='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='egcs-2.91.66.1 19990314/Linux (egcs-1.1.2 release)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lgdbm -ldbm -ldb -ldl -lm -lc perllibs=-ldl -lm -lc libc=/lib/libc.so.5.4.44, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Locally applied patches: DEVEL16824 @INC for perl v5.7.3: /usr/local/lib/perl5/5.7.3/i686-linux /usr/local/lib/perl5/5.7.3 /usr/local/lib/perl5/site_perl/5.7.3/i686-linux /usr/local/lib/perl5/site_perl/5.7.3 /usr/local/lib/perl5/site_perl . Environment for perl v5.7.3: HOME=/home/dcd LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/dcd/bin:/sbin:/usr/local/bin:/bin:/usr/bin:/usr/X11/bin:/usr/games:/usr/local/samba:/home/hobbes/tools/scripts:/home/hobbes/tools/linux:/usr0/hobbes/tools/scripts:/usr0/dcd/bin:/apps/general/bin:/usr/public PERL_BADLANG (unset) SHELL=/bin/bash ```
p5pRT commented 13 years ago

From @chorny

Same 2 warnings for each line on perl 5.14.0.

http​://rt.perl.org/rt3/Ticket/Display.html?id=9423

On Fri May 31 02​:26​:08 2002\, dcd@​tc.fluke.com wrote​:

The following script issues warnings (2 of them) for vec assignments\, while normal assignments to scalars don't generate any warnings. Since perl guarantees that the extra bits are filled with zeros\, I believe it should not issue these warnings.

While the script demonstrates simple cases\, the testing if the hash element exists and pre-initializing it before the vec assignment complicates production scripts\, and I'd strongly prefer to avoid "no warnings".

Use of uninitialized value in vec at vec_warn.pl line 16. Use of uninitialized value in scalar assignment at vec_warn.pl line 16. Use of uninitialized value in vec at vec_warn.pl line 17. Use of uninitialized value in scalar assignment at vec_warn.pl line 17.

$ cat vec_warn.pl

use warnings; use strict;

my ($s\, %sh); $s = 1; $sh{foo} = 1;

#If an element off the end of #the string is written to\, Perl will first extend #the string with sufficiently many zero bytes. # yet perl generates 2 warnings each for the following 2 vec assignments. # Use of uninitialized value in vec # Use of uninitialized value in scalar assignment my ($v\, %vh); vec($v\,0\,1) = 1; vec($vh{foo}\,0\,1) = 1;

# to avoid warnings must pre-init vectors

my ($wv\, %wvh); $wv = $wvh{foo} = ''; vec($wv\,0\,1) = 1; vec($wvh{foo}\,0\,1) = 1;

-- Alexandr Ciornii\, http​://chorny.net

p5pRT commented 13 years ago

From [Unknown Contact. See original ticket]

Same 2 warnings for each line on perl 5.14.0.

http​://rt.perl.org/rt3/Ticket/Display.html?id=9423

On Fri May 31 02​:26​:08 2002\, dcd@​tc.fluke.com wrote​:

The following script issues warnings (2 of them) for vec assignments\, while normal assignments to scalars don't generate any warnings. Since perl guarantees that the extra bits are filled with zeros\, I believe it should not issue these warnings.

While the script demonstrates simple cases\, the testing if the hash element exists and pre-initializing it before the vec assignment complicates production scripts\, and I'd strongly prefer to avoid "no warnings".

Use of uninitialized value in vec at vec_warn.pl line 16. Use of uninitialized value in scalar assignment at vec_warn.pl line 16. Use of uninitialized value in vec at vec_warn.pl line 17. Use of uninitialized value in scalar assignment at vec_warn.pl line 17.

$ cat vec_warn.pl

use warnings; use strict;

my ($s\, %sh); $s = 1; $sh{foo} = 1;

#If an element off the end of #the string is written to\, Perl will first extend #the string with sufficiently many zero bytes. # yet perl generates 2 warnings each for the following 2 vec assignments. # Use of uninitialized value in vec # Use of uninitialized value in scalar assignment my ($v\, %vh); vec($v\,0\,1) = 1; vec($vh{foo}\,0\,1) = 1;

# to avoid warnings must pre-init vectors

my ($wv\, %wvh); $wv = $wvh{foo} = ''; vec($wv\,0\,1) = 1; vec($wvh{foo}\,0\,1) = 1;

-- Alexandr Ciornii\, http​://chorny.net

p5pRT commented 12 years ago

From @Hugmeir

On Mon Jun 13 11​:53​:26 2011\, chorny wrote​:

Same 2 warnings for each line on perl 5.14.0.

http​://rt.perl.org/rt3/Ticket/Display.html?id=9423

Same warnings in 5.16.0\, albeit slightly more helpful\, since they point at the uninit variable. Attached two two patches​: the first one makes sv_pvn_force_flags guard against sv_2pv_flags returning NULL\, which can happen if it's passed SV_UNDEF_RETURNS_NULL; The second patch silences the uninit warnings for vec() by using SV_UNDEF_RETURNS_NULL.

However\, I make no judgment whenever silencing these is a good move; But if it isn't\, this ticket should be rejected.

--hugmeir

p5pRT commented 12 years ago

From @Hugmeir

0002-Fix-for-perl-9423-vec-assignments-generate-2-warning.patch ```diff From a1a507943a713d1ad1b3b20b7d256d25cbfa8f4f Mon Sep 17 00:00:00 2001 From: Brian Fraser Date: Fri, 25 May 2012 22:39:14 -0300 Subject: [PATCH 2/2] Fix for [perl #9423] vec assignments generate 2 warnings Before this commit, this: vec(my $v,0,1) = 1; would've produced four warnings about uninitialized values; however, the ticket argued that these were spurious. --- doop.c | 10 ++++++++-- t/lib/warnings/9uninit | 2 -- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/doop.c b/doop.c index a562536..4353d66 100644 --- a/doop.c +++ b/doop.c @@ -764,9 +764,14 @@ Perl_do_vecget(pTHX_ SV *sv, SSize_t offset, int size) { dVAR; STRLEN srclen, len, uoffset, bitoffs = 0; - const unsigned char *s = (const unsigned char *) SvPV_const(sv, srclen); + const unsigned char *s = (const unsigned char *) SvPV_flags_const(sv, srclen, + SV_GMAGIC | SV_UNDEF_RETURNS_NULL); UV retnum = 0; + if (!s) { + s = (const unsigned char *)""; + } + PERL_ARGS_ASSERT_DO_VECGET; if (offset < 0) @@ -921,7 +926,8 @@ Perl_do_vecset(pTHX_ SV *sv) if (!targ) return; - s = (unsigned char*)SvPV_force(targ, targlen); + s = (unsigned char*)SvPV_force_flags(targ, targlen, + SV_GMAGIC | SV_UNDEF_RETURNS_NULL); if (SvUTF8(targ)) { /* This is handled by the SvPOK_only below... if (!Perl_sv_utf8_downgrade(aTHX_ targ, TRUE)) diff --git a/t/lib/warnings/9uninit b/t/lib/warnings/9uninit index 37e24e7..1511b20 100644 --- a/t/lib/warnings/9uninit +++ b/t/lib/warnings/9uninit @@ -1032,10 +1032,8 @@ Use of uninitialized value $g2 in substr at - line 9. Use of uninitialized value $m1 in substr at - line 9. Use of uninitialized value $m2 in vec at - line 11. Use of uninitialized value $g1 in vec at - line 11. -Use of uninitialized value $m1 in vec at - line 11. Use of uninitialized value $m2 in vec at - line 12. Use of uninitialized value $g1 in vec at - line 12. -Use of uninitialized value $m1 in vec at - line 12. Use of uninitialized value $m1 in index at - line 14. Use of uninitialized value $m2 in index at - line 14. Use of uninitialized value $g1 in index at - line 15. -- 1.7.9.5 ```
p5pRT commented 12 years ago

From @Hugmeir

0001-sv.c-Make-sv_pvn_force_flags-guard-against-SV_UNDEF_.patch ```diff From 9d42fb3a3a1dd76d5d0f341f5bc8b7df76d6f3b4 Mon Sep 17 00:00:00 2001 From: Brian Fraser Date: Fri, 25 May 2012 22:30:02 -0300 Subject: [PATCH 1/2] sv.c: Make sv_pvn_force_flags guard against SV_UNDEF_RETURNS_NULL. Previously, if SV_UNDEF_RETURNS_NULL was passed to sv_pvn_force_flags, it would call sv_2pv_flags with that flag, and get back a NULL instead of a char *, which lead to issues. This commit makes sv_pvn_force_flags use an empty string in that case. --- sv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sv.c b/sv.c index 65f0e79..fa8899d 100644 --- a/sv.c +++ b/sv.c @@ -9112,6 +9112,9 @@ Perl_sv_pvn_force_flags(pTHX_ SV *const sv, STRLEN *const lp, const I32 flags) Perl_croak(aTHX_ "Can't coerce %s to string in %s", sv_reftype(sv,0), OP_DESC(PL_op)); s = sv_2pv_flags(sv, &len, flags &~ SV_GMAGIC); + if (!s) { + s = (char *)""; + } if (lp) *lp = len; -- 1.7.9.5 ```
p5pRT commented 12 years ago

From @cpansprout

On Fri May 25 18​:49​:56 2012\, Hugmeir wrote​:

On Mon Jun 13 11​:53​:26 2011\, chorny wrote​:

Same 2 warnings for each line on perl 5.14.0.

http​://rt.perl.org/rt3/Ticket/Display.html?id=9423

Same warnings in 5.16.0\, albeit slightly more helpful\, since they point at the uninit variable. Attached two two patches​: the first one makes sv_pvn_force_flags guard against sv_2pv_flags returning NULL\, which can happen if it's passed SV_UNDEF_RETURNS_NULL; The second patch silences the uninit warnings for vec() by using SV_UNDEF_RETURNS_NULL.

However\, I make no judgment whenever silencing these is a good move; But if it isn't\, this ticket should be rejected.

I agree that silencing the warning for lvalue vec makes sense\, but it should still warn for rvalue\, I think.

I admit to having only skimmed your patch quickly. Does it do that? This bit here suggests it does​:

@​@​ -1032\,10 +1032\,8 @​@​ Use of uninitialized value $g2 in substr at - line 9. Use of uninitialized value $m1 in substr at - line 9. Use of uninitialized value $m2 in vec at - line 11. Use of uninitialized value $g1 in vec at - line 11. -Use of uninitialized value $m1 in vec at - line 11. Use of uninitialized value $m2 in vec at - line 12. Use of uninitialized value $g1 in vec at - line 12. -Use of uninitialized value $m1 in vec at - line 12. Use of uninitialized value $m1 in index at - line 14. Use of uninitialized value $m2 in index at - line 14. Use of uninitialized value $g1 in index at - line 15.

--

Father Chrysostomos

p5pRT commented 12 years ago

From @Hugmeir

On Sat\, May 26\, 2012 at 3​:22 PM\, Father Chrysostomos via RT \< perlbug-followup@​perl.org> wrote​:

On Fri May 25 18​:49​:56 2012\, Hugmeir wrote​:

On Mon Jun 13 11​:53​:26 2011\, chorny wrote​:

Same 2 warnings for each line on perl 5.14.0.

http​://rt.perl.org/rt3/Ticket/Display.html?id=9423

Same warnings in 5.16.0\, albeit slightly more helpful\, since they point at the uninit variable. Attached two two patches​: the first one makes sv_pvn_force_flags guard against sv_2pv_flags returning NULL\, which can happen if it's passed SV_UNDEF_RETURNS_NULL; The second patch silences the uninit warnings for vec() by using SV_UNDEF_RETURNS_NULL.

However\, I make no judgment whenever silencing these is a good move; But if it isn't\, this ticket should be rejected.

I agree that silencing the warning for lvalue vec makes sense\, but it should still warn for rvalue\, I think.

I admit to having only skimmed your patch quickly. Does it do that? This bit here suggests it does​:

It silenced both; but you make a good point. I've attached a modified version of the second patch that only silences the warning for lvalue vec.

p5pRT commented 12 years ago

From @Hugmeir

0002-Fix-for-perl-9423-vec-assignments-generate-2-warning.patch ```diff From 2b954d72800cfb54cdb375758e31bb7e98a534c1 Mon Sep 17 00:00:00 2001 From: Brian Fraser Date: Sat, 26 May 2012 17:35:26 -0300 Subject: [PATCH 2/2] Fix for [perl #9423] vec assignments generate 2 warnings Before this commit, this: vec(my $v,0,1) = 1; would've produced four warnings about uninitialized values; however, the ticket argued that these were spurious. --- doop.c | 11 +++++++++-- t/lib/warnings/9uninit | 1 - 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/doop.c b/doop.c index a562536..f151737 100644 --- a/doop.c +++ b/doop.c @@ -764,9 +764,15 @@ Perl_do_vecget(pTHX_ SV *sv, SSize_t offset, int size) { dVAR; STRLEN srclen, len, uoffset, bitoffs = 0; - const unsigned char *s = (const unsigned char *) SvPV_const(sv, srclen); + const unsigned char *s = (const unsigned char *) SvPV_flags_const(sv, srclen, + SV_GMAGIC | ((PL_op->op_flags & OPf_MOD || LVRET) + ? SV_UNDEF_RETURNS_NULL : 0)); UV retnum = 0; + if (!s) { + s = (const unsigned char *)""; + } + PERL_ARGS_ASSERT_DO_VECGET; if (offset < 0) @@ -921,7 +927,8 @@ Perl_do_vecset(pTHX_ SV *sv) if (!targ) return; - s = (unsigned char*)SvPV_force(targ, targlen); + s = (unsigned char*)SvPV_force_flags(targ, targlen, + SV_GMAGIC | SV_UNDEF_RETURNS_NULL); if (SvUTF8(targ)) { /* This is handled by the SvPOK_only below... if (!Perl_sv_utf8_downgrade(aTHX_ targ, TRUE)) diff --git a/t/lib/warnings/9uninit b/t/lib/warnings/9uninit index 37e24e7..177a781 100644 --- a/t/lib/warnings/9uninit +++ b/t/lib/warnings/9uninit @@ -1035,7 +1035,6 @@ Use of uninitialized value $g1 in vec at - line 11. Use of uninitialized value $m1 in vec at - line 11. Use of uninitialized value $m2 in vec at - line 12. Use of uninitialized value $g1 in vec at - line 12. -Use of uninitialized value $m1 in vec at - line 12. Use of uninitialized value $m1 in index at - line 14. Use of uninitialized value $m2 in index at - line 14. Use of uninitialized value $g1 in index at - line 15. -- 1.7.9.5 ```
p5pRT commented 12 years ago

From @cpansprout

On Sat May 26 13​:41​:51 2012\, Hugmeir wrote​:

On Sat\, May 26\, 2012 at 3​:22 PM\, Father Chrysostomos via RT \< perlbug-followup@​perl.org> wrote​:

On Fri May 25 18​:49​:56 2012\, Hugmeir wrote​:

On Mon Jun 13 11​:53​:26 2011\, chorny wrote​:

Same 2 warnings for each line on perl 5.14.0.

http​://rt.perl.org/rt3/Ticket/Display.html?id=9423

Same warnings in 5.16.0\, albeit slightly more helpful\, since they point at the uninit variable. Attached two two patches​: the first one makes sv_pvn_force_flags guard against sv_2pv_flags returning NULL\, which can happen if it's passed SV_UNDEF_RETURNS_NULL; The second patch silences the uninit warnings for vec() by using SV_UNDEF_RETURNS_NULL.

However\, I make no judgment whenever silencing these is a good move; But if it isn't\, this ticket should be rejected.

I agree that silencing the warning for lvalue vec makes sense\, but it should still warn for rvalue\, I think.

I admit to having only skimmed your patch quickly. Does it do that? This bit here suggests it does​:

It silenced both; but you make a good point. I've attached a modified version of the second patch that only silences the warning for lvalue vec.

Thank you. Applied as 5204593b and 032061d2.

--

Father Chrysostomos

p5pRT commented 12 years ago

@cpansprout - Status changed from 'open' to 'resolved'

p5pRT commented 12 years ago

From @demerphq

On 26 May 2012 22​:41\, Brian Fraser \fraserbn@&#8203;gmail\.com wrote​:

On Sat\, May 26\, 2012 at 3​:22 PM\, Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org wrote​:

On Fri May 25 18​:49​:56 2012\, Hugmeir wrote​:

On Mon Jun 13 11​:53​:26 2011\, chorny wrote​:

Same 2 warnings for each line on perl 5.14.0.

http​://rt.perl.org/rt3/Ticket/Display.html?id=9423

Same warnings in 5.16.0\, albeit slightly more helpful\, since they point at the uninit variable. Attached two two patches​: the first one makes sv_pvn_force_flags guard against sv_2pv_flags returning NULL\, which can happen if it's passed SV_UNDEF_RETURNS_NULL; The second patch silences the uninit warnings for vec() by using SV_UNDEF_RETURNS_NULL.

However\, I make no judgment whenever silencing these is a good move; But if it isn't\, this ticket should be rejected.

I agree that silencing the warning for lvalue vec makes sense\, but it should still warn for rvalue\, I think.

I admit to having only skimmed your patch quickly.  Does it do that? This bit here suggests it does​:

It silenced both; but you make a good point. I've attached a modified version of the second patch that only silences the warning for lvalue vec.

Thanks a lot for this patch\, this bit me recently\, and I appreciate you fixing it.

Cheers\, yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"