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
