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 <[email protected]> To: [email protected] 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" <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
