From dhd@eradicator.org

dhd@​timebomb​:~$ perl -v
This is perl, v5.6.0 built for i386-linux
dhd@​timebomb​:~$ perl -le 'use integer; $foo=0xffffffff; print $foo; ++$foo; print $foo'
4294967295
4294967296
dhd@​timebomb​:~$ perl -le 'use integer; $foo=0xffffffff; print $foo; $foo += 1; print $foo'
4294967295
0

Looks to me like the pre/postincrement operators are not respecting
the integer pragma. This problem also exists in 5.005_03.

Flags:
    category=core
    severity=low

Site configuration information for perl v5.6.0:

Configured by bod at Wed Feb 21 04:08:51 EST 2001.

Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.2.18, archname=i386-linux
    uname='linux duende 2.2.18 #1 thu dec 28 14:51:40 est 2000 i686 unknown '
    config_args='-Dccflags=-DDEBIAN -Darchname=i386-linux -Dprefix=/usr -Dprivlib=/usr/share/perl/5.6.0 -Darchlib=/usr/lib/perl/5.6.0 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.6.0 -Dsitearch=/usr/local/lib/perl/5.6.0 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dman1ext=1 -Dman3ext=3 -Dpager=/usr/bin/pager -Uafs -Ud_csh -Uusesfio -Duseshrplib -Dlibperl=libperl.so.5.6.0 -Dd_dosuid -des'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=define 
    use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
  Compiler:
    cc='cc', optimize='-O2', gccversion=2.95.3 20010125 (prerelease)
    cppflags='-DDEBIAN -fno-strict-aliasing -I/usr/local/include'
    ccflags ='-DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
    stdchar='char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -ldl -lm -lc -lcrypt
    libc=/lib/libc-2.2.2.so, so=so, useshrplib=true, libperl=libperl.so.5.6.0
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.6.0:
    /home/dhd/site_perl/i386-linux
    /home/dhd/site_perl
    /home/dhd/site_perl/i386-linux
    /usr/local/lib/perl/5.6.0
    /usr/local/share/perl/5.6.0
    /usr/lib/perl5
    /usr/share/perl5
    /usr/lib/perl/5.6.0
    /usr/share/perl/5.6.0
    /usr/lib/perl5/5.6/i386-linux
    /usr/lib/perl5/5.6
    /usr/lib/perl5/5.005/i386-linux
    .


Environment for perl v5.6.0:
    HOME=/home/dhd
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
    PERL5LIB=/home/dhd/site_perl:/home/dhd/site_perl/i386-linux
    PERL_BADLANG (unset)
    SHELL=/bin/bash

From @iabyn

still present in bleedperl@​19435.

The pre/post ++ ops upgrade to an NV; the += keeps the IV and wraps to zero.

From cmoore@hellyeah.org

The released 5.8.1 has this as well.

From @smpeters

dhd@​timebomb​:~$ perl -v
This is perl, v5.6.0 built for i386-linux
dhd@​timebomb​:~$ perl -le 'use integer; $foo=0xffffffff; print $foo;
++$foo; print $foo'
4294967295
4294967296
dhd@​timebomb​:~$ perl -le 'use integer; $foo=0xffffffff; print $foo;
$foo += 1; print $foo'
4294967295
0

Comment from davem

The pre/post ++ ops upgrade to an NV; the += keeps the IV and wraps to
zero.

Comment from hydo

The released 5.8.1 has this as well.

I've tried this in later Perls, but it seems to be working correctly in
Perl 5.8.2 and higher. Does anyone know if this is fixed in 5.8.2?

From perl_dummy@bloodgate.com

Moin,

Steve wrote​:

dhd@​timebomb​:~$ perl -v
This is perl, v5.6.0 built for i386-linux
dhd@​timebomb​:~$ perl -le 'use integer; $foo=0xffffffff; print $foo;
++$foo; print $foo'
4294967295
4294967296
dhd@​timebomb​:~$ perl -le 'use integer; $foo=0xffffffff; print $foo;
$foo += 1; print $foo'
4294967295
0

Comment from davem

The pre/post ++ ops upgrade to an NV; the += keeps the IV and wraps to
zero.

Comment from hydo

The released 5.8.1 has this as well.
I've tried this in later Perls, but it seems to be working correctly in
Perl 5.8.2 and higher. Does anyone know if this is fixed in 5.8.2?

Nope, present in at least v5.8.3 (or re-introduced?)​:

te@​linux​:~> perl -le 'use integer; $foo=0xffffffff; print $foo; ++$foo;
print $foo'
4294967295
4294967296
te@​linux​:~> perl -le 'use integer; $foo=0xffffffff; print $foo; $foo += 1;
print $foo'
4294967295
0
te@​linux​:~> perl -v

This is perl, v5.8.3 built for i586-linux-thread-multi

Copyright 1987-2003, Larry Wall

Perl may be copied only under the terms of either the Artistic License or
the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to the
Internet, point your browser at http​://www.perl.com/, the Perl Home Page.

Best wishes,

Tels

--
Signed on Sat Aug 28 18​:11​:05 2004 with key 0x93B84C15.
Visit my photo gallery at http​://bloodgate.com/photos/
PGP key on http​://bloodgate.com/tels.asc or per email.

"Call me Justin, Justin Case."

From @iabyn

On Sat, Aug 28, 2004 at 06​:12​:07PM +0200, Tels wrote​:

Moin,

Steve wrote​:

dhd@​timebomb​:~$ perl -v
This is perl, v5.6.0 built for i386-linux
dhd@​timebomb​:~$ perl -le 'use integer; $foo=0xffffffff; print $foo;
++$foo; print $foo'
4294967295
4294967296
dhd@​timebomb​:~$ perl -le 'use integer; $foo=0xffffffff; print $foo;
$foo += 1; print $foo'
4294967295
0

Comment from davem

The pre/post ++ ops upgrade to an NV; the += keeps the IV and wraps to
zero.

Comment from hydo

The released 5.8.1 has this as well.
I've tried this in later Perls, but it seems to be working correctly in
Perl 5.8.2 and higher. Does anyone know if this is fixed in 5.8.2?

Nope, present in at least v5.8.3 (or re-introduced?)​:

The real problem is that although there are integer-specific versions of
ops like add (ie pp_i_add() rather than pp_add()), there aren't specific
ones for the pre/post inc/dec ops. In fact, opcode.h has the following
lines​:

  #define Perl_pp_i_preinc Perl_pp_preinc
  #define Perl_pp_i_predec Perl_pp_predec
  #define Perl_pp_i_postinc Perl_pp_postinc
  #define Perl_pp_i_postdec Perl_pp_postdec

So if we are agreed that $foo=0xffffffff; $foo++ should leave $foo
as 0 rather than 2^32 on 32-bit systems, then
adding specific pp_i_preinc() fucntions seems to be the way to go.

Dave.

--
Never do today what you can put off till tomorrow.

From @nwc10

On Wed, Sep 01, 2004 at 10​:41​:26PM +0100, Dave Mitchell wrote​:

The real problem is that although there are integer-specific versions of
ops like add (ie pp_i_add() rather than pp_add()), there aren't specific
ones for the pre/post inc/dec ops. In fact, opcode.h has the following
lines​:

\#define Perl\_pp\_i\_preinc Perl\_pp\_preinc
\#define Perl\_pp\_i\_predec Perl\_pp\_predec
\#define Perl\_pp\_i\_postinc Perl\_pp\_postinc
\#define Perl\_pp\_i\_postdec Perl\_pp\_postdec

So if we are agreed that $foo=0xffffffff; $foo++ should leave $foo
as 0 rather than 2^32 on 32-bit systems, then
adding specific pp_i_preinc() fucntions seems to be the way to go.

I have no opinion (yet) on the first part. But on the way to go, yes.

This doesn't feel like the sort of change suitable for maint now.
(It's far too subtle but might break working code). Maint can't have new
ops (breaks binary compatibility) but this isn't a restriction on blead,
so new pp_i_preinc() etc opcode functions seem the most sensible
implementation route.

Nicholas Clark

From @ysth

On Wed, Sep 01, 2004 at 10​:41​:26PM +0100, Dave Mitchell <davem@​iabyn.com> wrote​:

The real problem is that although there are integer-specific versions of
ops like add (ie pp_i_add() rather than pp_add()), there aren't specific
ones for the pre/post inc/dec ops. In fact, opcode.h has the following
lines​:

\#define Perl\_pp\_i\_preinc Perl\_pp\_preinc
\#define Perl\_pp\_i\_predec Perl\_pp\_predec
\#define Perl\_pp\_i\_postinc Perl\_pp\_postinc
\#define Perl\_pp\_i\_postdec Perl\_pp\_postdec

So if we are agreed that $foo=0xffffffff; $foo++ should leave $foo
as 0 rather than 2^32 on 32-bit systems, then
adding specific pp_i_preinc() fucntions seems to be the way to go.

And with such an op and 32-bit ints, $foo=0x7fffffff; $foo++ should
leave $foo as -2147483648, yes? Definitely not a maint-friendly
change.

From @iabyn

On Wed, Sep 01, 2004 at 02​:58​:24PM -0700, Yitzchak Scott-Thoennes wrote​:

On Wed, Sep 01, 2004 at 10​:41​:26PM +0100, Dave Mitchell <davem@​iabyn.com> wrote​:

The real problem is that although there are integer-specific versions of
ops like add (ie pp_i_add() rather than pp_add()), there aren't specific
ones for the pre/post inc/dec ops. In fact, opcode.h has the following
lines​:

\#define Perl\_pp\_i\_preinc Perl\_pp\_preinc
\#define Perl\_pp\_i\_predec Perl\_pp\_predec
\#define Perl\_pp\_i\_postinc Perl\_pp\_postinc
\#define Perl\_pp\_i\_postdec Perl\_pp\_postdec

So if we are agreed that $foo=0xffffffff; $foo++ should leave $foo
as 0 rather than 2^32 on 32-bit systems, then
adding specific pp_i_preinc() fucntions seems to be the way to go.

And with such an op and 32-bit ints, $foo=0x7fffffff; $foo++ should
leave $foo as -2147483648, yes? Definitely not a maint-friendly
change.

Yep.

Note that currently​:

[davem@​percy perl] P4$ perl585 -le'use integer;print 0x7fffffff+1'
-2147483648

so we'd just be bringing ++ in line with +. But like you say,
not for maint.

Dave.

--
Justice is when you get what you deserve.
Law is when you get what you pay for.

From @hvds

Dave Mitchell <davem@​iabyn.com> wrote​:
:On Wed, Sep 01, 2004 at 02​:58​:24PM -0700, Yitzchak Scott-Thoennes wrote​:
:> And with such an op and 32-bit ints, $foo=0x7fffffff; $foo++ should
:> leave $foo as -2147483648, yes? Definitely not a maint-friendly
:> change.
:
:Yep.
:
:Note that currently​:
:
:[davem@​percy perl] P4$ perl585 -le'use integer;print 0x7fffffff+1'
:-2147483648
:
:so we'd just be bringing ++ in line with +. But like you say,
:not for maint.

Hmm, what determines that it's an IV rather than a UV? Or is 'integer'
actually short for 'integer​::signed' by definition?

(FWIW, almost all the stuff I do with 'use integer' wants unsigned
integers.)

Hugo

From @ysth

On Thu, Sep 02, 2004 at 09​:13​:43AM +0100, hv@​crypt.org wrote​:

Dave Mitchell <davem@​iabyn.com> wrote​:
:On Wed, Sep 01, 2004 at 02​:58​:24PM -0700, Yitzchak Scott-Thoennes wrote​:
:> And with such an op and 32-bit ints, $foo=0x7fffffff; $foo++ should
:> leave $foo as -2147483648, yes? Definitely not a maint-friendly
:> change.
:
:Yep.
:
:Note that currently​:
:
:[davem@​percy perl] P4$ perl585 -le'use integer;print 0x7fffffff+1'
:-2147483648
:
:so we'd just be bringing ++ in line with +. But like you say,
:not for maint.

Hmm, what determines that it's an IV rather than a UV? Or is 'integer'
actually short for 'integer​::signed' by definition?

(FWIW, almost all the stuff I do with 'use integer' wants unsigned
integers.)

use integer means a C-level (IV) cast on arithmetic operands, so
it's never UV. Sounds like you'd be better off without use integer.

From @nwc10

On Thu, Sep 02, 2004 at 01​:45​:34AM -0700, Yitzchak Scott-Thoennes wrote​:

On Thu, Sep 02, 2004 at 09​:13​:43AM +0100, hv@​crypt.org wrote​:

Dave Mitchell <davem@​iabyn.com> wrote​:
:On Wed, Sep 01, 2004 at 02​:58​:24PM -0700, Yitzchak Scott-Thoennes wrote​:
:> And with such an op and 32-bit ints, $foo=0x7fffffff; $foo++ should
:> leave $foo as -2147483648, yes? Definitely not a maint-friendly
:> change.
:
:Yep.
:
:Note that currently​:
:
:[davem@​percy perl] P4$ perl585 -le'use integer;print 0x7fffffff+1'
:-2147483648
:
:so we'd just be bringing ++ in line with +. But like you say,
:not for maint.

Hmm, what determines that it's an IV rather than a UV? Or is 'integer'
actually short for 'integer​::signed' by definition?

(FWIW, almost all the stuff I do with 'use integer' wants unsigned
integers.)

use integer means a C-level (IV) cast on arithmetic operands, so
it's never UV. Sounds like you'd be better off without use integer.

Mmm. So strictly that would mean that the result of 0x7fffffff + 1 under use
integer is nasal demons.

Overflow of signed integer arithmetic is undefined behaviour in ANSI C, and
perl runs on Amdahl UTS (where (int)0x7fffffff + 1 is 0) so we better not
make (or test) any guarantees we aren't prepared to make portable.

Nicholas Clark

From @iabyn

On Thu, Sep 02, 2004 at 11​:14​:17AM +0100, Nicholas Clark wrote​:

Overflow of signed integer arithmetic is undefined behaviour in ANSI C, and
perl runs on Amdahl UTS (where (int)0x7fffffff + 1 is 0) so we better not
make (or test) any guarantees we aren't prepared to make portable.

Gack!
It's times like this when I wish I'd become a VB programmer....

--
Lady Nancy Astor​: If you were my husband, I would flavour your coffee
with poison.
Churchill​: Madam - if I were your husband, I would drink it.

From @gannett-ggreer

On Tue Mar 13 00​:39​:47 2001, dhd@​eradicator.org wrote​:

dhd@​timebomb​:~$ perl -v
This is perl, v5.6.0 built for i386-linux
dhd@​timebomb​:~$ perl -le 'use integer; $foo=0xffffffff; print $foo;
++$foo; print $foo'
4294967295
4294967296
dhd@​timebomb​:~$ perl -le 'use integer; $foo=0xffffffff; print $foo;
$foo += 1; print $foo'
4294967295
0

Looks to me like the pre/postincrement operators are not respecting
the integer pragma. This problem also exists in 5.005_03.

The consensus of this ticket was "not during maint" but that is years
ago so I thought I'd prod this back to attention.

DaveM also noted​:
$ perl585 -le'use integer;print 0x7fffffff+1'
-2147483648

so it is already inconsistent.

One "solution" to the problem is everybody getting 64-bit machines​:

$ ./perl -I lib -le 'use integer; $foo=0xffffffff; print $foo; $foo +=
1; print $foo'
4294967295
4294967296
$ ./perl -I lib -V​:archname
archname='x86_64-linux';

This ticket also notable for having Nicholas Clark's nasal demons.

--
George Greer

From @jkeenan

On Tue Mar 13 00​:39​:47 2001, dhd@​eradicator.org wrote​:

-----------------------------------------------------------------
[Please enter your report here]

dhd@​timebomb​:~$ perl -v
This is perl, v5.6.0 built for i386-linux
dhd@​timebomb​:~$ perl -le 'use integer; $foo=0xffffffff; print $foo;
++$foo; print $foo'
4294967295
4294967296
dhd@​timebomb​:~$ perl -le 'use integer; $foo=0xffffffff; print $foo;
$foo += 1; print $foo'
4294967295
0

Looks to me like the pre/postincrement operators are not respecting
the integer pragma. This problem also exists in 5.005_03.

In Perl 5.14.2, 'perldoc integer' includes many qualifications about the
workings of the 'integer' pragma. Specifically​:

#####
Now, it so happens that the pre- and post- increment
and decrement operators, ++ and --, are not affected by "use integer;"
either. Some may rightly consider this to be a bug -- but at least
it's a long-standing one.
#####

Given this documentation, should we keep this ticket open?

Thank you very much.
Jim Keenan

From @ikegami

On Thu, Jan 5, 2012 at 8​:56 PM, James E Keenan via RT <
perlbug-followup@​perl.org> wrote​:

On Tue Mar 13 00​:39​:47 2001, dhd@​eradicator.org wrote​:

-----------------------------------------------------------------
[Please enter your report here]

dhd@​timebomb​:~$ perl -v
This is perl, v5.6.0 built for i386-linux
dhd@​timebomb​:~$ perl -le 'use integer; $foo=0xffffffff; print $foo;
++$foo; print $foo'
4294967295
4294967296
dhd@​timebomb​:~$ perl -le 'use integer; $foo=0xffffffff; print $foo;
$foo += 1; print $foo'
4294967295
0

Looks to me like the pre/postincrement operators are not respecting
the integer pragma. This problem also exists in 5.005_03.

In Perl 5.14.2, 'perldoc integer' includes many qualifications about the
workings of the 'integer' pragma. Specifically​:

#####
Now, it so happens that the pre- and post- increment
and decrement operators, ++ and --, are not affected by "use integer;"
either. Some may rightly consider this to be a bug -- but at least
it's a long-standing one.
#####

Given this documentation, should we keep this ticket open?

Thank you very much.
Jim Keenan

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

Why do people use C<use integer;>?

The pragma indicates it's for performance reasons (i.e. use the machine's
integer operation when integers are expected anyway), but I doubt someone
would rather get a wrong answer from ++ than a correct one just because
it's faster. (The beavhiour of ++ on overflow is undefined in C, right?)

Some might use the pragma to perform rounding (i.e. to get integers in the
mathematical sense). Since 4294967296 is an integer in the mathematical
sense, there's no problem for these users either.

If anything, C<+= 1> is the one that needs fixing (i.e. switch to floating
point numbers on overflow).

- Eric

From @rjbs

No, I'm resolving this. It would be nice to see it fixed, but it's already documented and keeping
it open as a bug is just going to crowd the tracker.

From [Unknown Contact. See original ticket]

No, I'm resolving this. It would be nice to see it fixed, but it's already documented and keeping
it open as a bug is just going to crowd the tracker.

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

From @rjbs

I changed my mind. We need a policy for bugs that are listed as todos, rather than
undocumented screwups. We can work this out later. Added to my todo list...

From [Unknown Contact. See original ticket]

I changed my mind. We need a policy for bugs that are listed as todos, rather than
undocumented screwups. We can work this out later. Added to my todo list...

@rjbs - Status changed from 'resolved' to 'stalled'

From @jkeenan

On Sun Jan 08 08​:16​:24 2012, rjbs wrote​:

I changed my mind. We need a policy for bugs that are listed as
todos, rather than
undocumented screwups. We can work this out later. Added to my todo
list...

rjbs​:

How's that todo list lookin'? ;-)

Perhaps this should be in the Open queue rather than Stalled?

Thank you very much.
Jim Keenan

The RT System itself - Status changed from 'stalled' to 'open'

From @iabyn

On Sun, Oct 07, 2012 at 08​:22​:33AM -0700, James E Keenan via RT wrote​:

On Sun Jan 08 08​:16​:24 2012, rjbs wrote​:

I changed my mind. We need a policy for bugs that are listed as
todos, rather than
undocumented screwups. We can work this out later. Added to my todo
list...

rjbs​:

How's that todo list lookin'? ;-)

Perhaps this should be in the Open queue rather than Stalled?

yeah, I think its a bug.

--
Spock (or Data) is fired from his high-ranking position for not being able
to understand the most basic nuances of about one in three sentences that
anyone says to him.
  -- Things That Never Happen in "Star Trek" #19