*X-seq*: zsh-users 19080*From*: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>*To*: zsh-users@xxxxxxx*Subject*: Re: Determining the length of "long"?*Date*: Fri, 12 Sep 2014 17:17:37 -0700*In-reply-to*: <20140912234254.GA30434@gmx.de>*List-help*: <mailto:zsh-users-help@zsh.org>*List-id*: Zsh Users List <zsh-users.zsh.org>*List-post*: <mailto:zsh-users@zsh.org>*Mailing-list*: contact zsh-users-help@xxxxxxx; run by ezmlm*References*: <20140911213608.GA1029@gmx.de> <140911213901.ZM21898@torch.brasslantern.com> <20140912084230.GA4226@linux.vnet.ibm.com> <140912161627.ZM23323@torch.brasslantern.com> <20140912234254.GA30434@gmx.de>

On Sep 13, 12:42am, Dominik Vogt wrote: } Subject: Re: Determining the length of "long"? } } To clarify, on s390 (1 << 31) has the same result as (1 << 63) *if* } the integer type is long (which I doubt, zsh probably uses long } long). Indeed, I wasn't aware (more accurately, forgot) that s390 has those oddball 31-bit integers. } The underlying assumption of the test that shifting an integer } value to the left by its width in bits or more yields zero is } wrong on some platforms. That's not the underlying assumption, acctually. The assumption is that shifting by (number of bits minus one) will yield a very long binary number (the ${#:-"..."} in the test: lots of trailing zeroes), whereas shifting by the number of bits or more yields a number with a smaller footprint because multiple leading zeroes are not printed.

**References**:**Determining the length of "long"?***From:*Dominik Vogt

**Re: Determining the length of "long"?***From:*Bart Schaefer

**Re: Determining the length of "long"?***From:*Dominik Vogt

**Re: Determining the length of "long"?***From:*Bart Schaefer

**Re: Determining the length of "long"?***From:*Dominik Vogt

Messages sorted by: Reverse Date, Date, Thread, Author