This should be a problem for Windows and Unix systems for managing things
like handles. How do they do it?

On Thu, Jun 9, 2016 at 6:10 AM, 'Pascal Jasmin' via Source <
sou...@jsoftware.com> wrote:

> On a (afaiu) related note, could the numbered locale limit be raised on 64
> bit systems?
>
>
> a_12345678901234_ =: 3
>
> cocreate ''
> ┌───────────┐
> │-2147483646│
> └───────────┘
>
>
> using unlimited extended integers (to track next object number) on all
> systems (or just on 32bit) would seem viable as well.
>
> The constraint becomes an issue with systems that hope to have high uptime.
>
>
>
>
> ----- Original Message -----
> From: Henry Rich <henryhr...@gmail.com>
> To: sou...@jsoftware.com
> Sent: Wednesday, June 8, 2016 12:25 PM
> Subject: Re: [Jsource] strtol
>
> 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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to