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
