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

Reply via email to