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
