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
