Henry,

Would you fix it if it is broken?  Thanks.
On Jun 9, 2016 12:25 AM, "Henry Rich" <henryhr...@gmail.com> wrote:

> 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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to