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
