I agree the testcase is contrived and 64-bit overflow should not
happen in real world unless the same application has running
continuously for many years (or millennium?).
Чт, 09 июн 2016, Eric Iverson написал(а):
> Bill,
>
> Thanks for pointing out the last remaining use of strtol (last letter is a
> lowercase el). This caused the problem seen in win64 vs linux64.
>
> I have pushed a change so that strtoI (last letter is a capitol eye) is
> used instead and this fixes the immediate problem (overflow before it is
> necessary in win64).
>
> The larger and older problem of overflow remains, but does not warrant the
> effort to fix now. This is not a practical problem and there are better
> areas to spend our efforts.
>
> On Thu, Jun 9, 2016 at 11:28 AM, 'Pascal Jasmin' via Source <
> sou...@jsoftware.com> wrote:
>
> > Even if this is "MS's fault", could windows get the same behaviour as
> > linux on this?
> >
> >
> >
> >
> > ----- Original Message -----
> > From: bill lam <bbill....@gmail.com>
> > To: Source forum <sou...@jsoftware.com>
> > Sent: Thursday, June 9, 2016 9:20 AM
> > Subject: Re: [Jsource] strtol
> >
> > No problem on linux64
> >
> > a_12345678901234_ =: 3
> > cocreate ''
> > +--------------+
> > |12345678901235|
> > +--------------+
> > JVERSION
> > Engine: j805/j64/linux
> > Beta: commercial/2016-05-10T12:23:26
> > Library: 8.04.15
> > Platform: Linux 64
> > Installer: unknown
> > InstallPath: /usr/share/j/8.0.4
> > Contact: www.jsoftware.com
> >
> > I suspect it only breaks on windows64 where strtol is 32-bit.
> >
> > a_12345678901234_ =: 3
> > cocreate''
> > +----------+
> > |2147483648|
> > +----------+
> > JVERSION
> > Engine: j804/j64/windows
> > Release: commercial/2015-12-21 16:18:48
> > Library: 8.04.15
> > Platform: Win 64
> > Installer: j801 beta install
> > InstallPath: z:/usr/share/j/8.0.4
> > Contact: www.jsoftware.com
> >
> >
> >
> > Чт, 09 июн 2016, bill lam написал(а):
> > > Did you test on windows? Does it also failed on linux or mac?
> > > On Jun 9, 2016 8:11 PM, "'Pascal Jasmin' via Source" <
> > sou...@jsoftware.com>
> > > wrote:
> > >
> > > > On a (afaiu) related note, could the numbered locale limit be raised
> > on 64
> > > > bit systems?
> > > >
> > > >
> > > > a_12345678901234_ =: 3
> > > >
> > > > cocreate ''
> > > > ┌───────────┐
> > > > │-2147483646│
> > > > └───────────┘
> > > >
> > > >
> > > > using unlimited extended integers (to track next object number) on all
> > > > systems (or just on 32bit) would seem viable as well.
> > > >
> > > > The constraint becomes an issue with systems that hope to have high
> > uptime.
> > > >
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: Henry Rich <henryhr...@gmail.com>
> > > > To: sou...@jsoftware.com
> > > > Sent: Wednesday, June 8, 2016 12:25 PM
> > > > Subject: Re: [Jsource] strtol
> > > >
> > > > The way to create a testcase is to create a locale with a very large
> > > > number, by
> > > >
> > > > a_2147483648_ =: 5
> > > >
> > > > locale numbering will start after the largest number that has been
> > used.
> > > >
> > > > Henry
> > > >
> > > > On 6/8/2016 8:54 AM, bill lam wrote:
> > > > > I think using strtoI should be harmless, but I am not sure if u will
> > > > exceed
> > > > > range of 32-bit integer. And how to design a test script to show
> > strtol
> > > > > will fail while strtoI will pass.
> > > > >
> > > > > PS. I realized it is nearly impossible to distinguish strtol (last
> > > > > character is el) and strtoI (last is capital i) on android gmail app.
> > > > > On Jun 8, 2016 8:36 PM, "Raul Miller" <rauldmil...@gmail.com> wrote:
> > > > >
> > > > >> Oh!
> > > > >>
> > > > >> There is also a microsoft supplied definition for strtoI, I was
> > > > >> similarly lazy and forgot to look in the source code to see if it
> > > > >> redefined the name (which it looks like it does).
> > > > >>
> > > > >> So one part of my objection (that strtoI would cause problems which
> > > > >> currently do not happen) should not be the case.
> > > > >>
> > > > >> But the other issue - that it does not seem like strtoI would fix
> > > > >> anything (would not make J perform in a fashion which is closer to
> > > > >> what was prescribed by the dictionary), either - might still be an
> > > > >> issue.
> > > > >>
> > > > >> Do you disagree?
> > > > >>
> > > > >> Thanks,
> > > > >>
> > > > >> --
> > > > >> Raul
> > > > >>
> > > > >>
> > > > >> On Wed, Jun 8, 2016 at 1:12 AM, bill lam <bbill....@gmail.com>
> > wrote:
> > > > >>> I am sorry that I was too lazy to include the definition of
> > > > >>> strtoI for discussion
> > > > >>>
> > > > >>> #if SY_64
> > > > >>> #define IMAX 9223372036854775807L
> > > > >>> #define FMTI "%lli"
> > > > >>> #define FMTI02 "%02lli"
> > > > >>> #define FMTI04 "%04lli"
> > > > >>> #define FMTI05 "%05lli"
> > > > >>>
> > > > >>> #if SY_WIN32
> > > > >>> #define strtoI _strtoi64
> > > > >>> #else
> > > > >>> #define strtoI strtoll
> > > > >>> #endif
> > > > >>>
> > > > >>> #else
> > > > >>> #define IMAX 2147483647L
> > > > >>> #define FMTI "%li"
> > > > >>> #define FMTI02 "%02li"
> > > > >>> #define FMTI04 "%04li"
> > > > >>> #define FMTI05 "%05li"
> > > > >>> #define strtoI strtol
> > > > >>> #endif
> > > > >>>
> > > > >>> For *nix, strtol and strtoll are almost equivalent.
> > > > >>>
> > > > >>> Вт, 07 июн 2016, Raul Miller написал(а):
> > > > >>>> I think strtol (long result) should be better than strtoI (int
> > > > result).
> > > > >>>>
> > > > >>>> The distinction should only matter when a numeric local name
> > exceeds
> > > > >>>> the value which can be stored in a 32 bit integer. That's a rare
> > > > >>>> problem and it's probably more important that the behavior be
> > correct
> > > > >>>> for that case on 64 bit systems than on 32 bit systems. Worse,
> > > > >>>> changing to strtoI would not actually fix any failure case, but it
> > > > >>>> would introduce additional failure cases.
> > > > >>>>
> > > > >>>> That said, it might be worthwhile investigating a solution for the
> > > > >>>> resulting problem. I guess you would first want to
> > cocreate/coerase
> > > > >>>> about 5 billion times to see if that works. And, if it fails, work
> > > > >>>> from there.
> > > > >>>>
> > > > >>>> One possible failure mode would be overlapping locales. For
> > example,
> > > > >>>> locale 4294967296 on a 32 bit system might be the same as locale
> > 0.
> > > > >>>> Other failure modes (crashes or whatever) might also be possible?
> > > > >>>>
> > > > >>>> Thanks,
> > > > >>>>
> > > > >>>> --
> > > > >>>> Raul
> > > > >>>>
> > > > >>>> On Tue, Jun 7, 2016 at 9:00 PM, bill lam <bbill....@gmail.com>
> > wrote:
> > > > >>>>> There is still one artefact of strtol in sl.c
> > > > >>>>>
> > > > >>>>> A jtstfind(J jt,B b,I n,C*u){I old;L*v;
> > > > >>>>> if(!n){n=4; u="base";}
> > > > >>>>> if('9'>=*u)R stfindnum(b,strtol(u,NULL,10));
> > > > >>>>> else{
> > > > >>>>> old=jt->tbase+jt->ttop; v=probe(nfs(n,u),jt->stloc);
> > > > >>>>> tpop(old);
> > > > >>>>> R v?v->val:b?stcreate(0,jt->locsize[0],n,u):0;
> > > > >>>>> }} /* find the symbol table for locale u, create if b and
> > > > >>>>> non-existent */
> > > > >>>>>
> > > > >>>>> Is it safe to use strtol here?
> > > > >>>>>
> > > > >>>>> Is it ok to change to strtoI?
> > > > >>>>>
> > > > >>>>> * strtol returns 32-bit integers under 32-bit windows.
> > > > >>>>>
> > > > >>>>> --
> > > > >>>>> regards,
> > > > >>>>> ====================================================
> > > > >>>>> GPG key 1024D/4434BAB3 2008-08-24
> > > > >>>>> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> > > > >>>>> gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
> > > > >>>>>
> > > > ----------------------------------------------------------------------
> > > > >>>>> For information about J forums see
> > > > >> http://www.jsoftware.com/forums.htm
> > > > >>>>
> > ----------------------------------------------------------------------
> > > > >>>> For information about J forums see
> > > > http://www.jsoftware.com/forums.htm
> > > >
> > > > >>> --
> > > > >>> regards,
> > > > >>> ====================================================
> > > > >>> GPG key 1024D/4434BAB3 2008-08-24
> > > > >>> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> > > > >>> gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
> > > > >>>
> > ----------------------------------------------------------------------
> > > > >>> For information about J forums see
> > http://www.jsoftware.com/forums.htm
> > > > >>
> > ----------------------------------------------------------------------
> > > > >> For information about J forums see
> > http://www.jsoftware.com/forums.htm
> > > > >
> > ----------------------------------------------------------------------
> > > > > For information about J forums see
> > http://www.jsoftware.com/forums.htm
> >
> > > >
> > > > ----------------------------------------------------------------------
> > > > For information about J forums see http://www.jsoftware.com/forums.htm
> > > > ----------------------------------------------------------------------
> > > > For information about J forums see http://www.jsoftware.com/forums.htm
> >
> > --
> > regards,
> > ====================================================
> > GPG key 1024D/4434BAB3 2008-08-24
> > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> > gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
> >
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
