Path: csiph.com!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.lang.c
Subject: Re: Safety of casting from 'long' to 'int'
Date: Sat, 9 May 2026 01:36:32 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <10tm330$8d2$1@reader1.panix.com>
References: <10su8cn$am9i$1@dont-email.me> <10tk4sg$2l19a$2@dont-email.me> <10tloub$32n$1@reader1.panix.com> <10tlvaa$1l93l$16@dont-email.me>
Injection-Date: Sat, 9 May 2026 01:36:32 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80"; logging-data="8610"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Xref: csiph.com comp.lang.c:398565

In article <10tlvaa$1l93l$16@dont-email.me>,
Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:
>On 2026-05-09 00:43, Dan Cross wrote:
>>> [...]
>> 
>> Sure.  This was a bit of a contrived example, but you ask a good
>> question: how often might one want write code like that?
>> 
>> In short, I don't know, but I can think of any number of hash
>> functions, checksums, etc, that may be implemented using 16-bit
>> arithmetic, and I can well see programmers wanting to take
>> advantage of the modular semantics afforded by using unsigned
>> types to do so.  Every day?  Probably not.  But often enough.
>
>I mentioned it before but it may have got lost in the lots text
>typically exchanged here; for hash functions a modulus based on
>powers of two has *bad* _distribution properties_, so it's not
>a sensible example or plausible rationale to vindicate modular
>arithmetic for the few special cases (m=8, 16, 32, 64, etc.).

Maybe, maybe not, depending on the exact hashing function and
the values it uses.  Since K&R2 came up elsewhere, consider the
hash function the presented on pp 128-129:

/* hash: form hash value for string s */
unsigned hash(char *s)
{
    unsigned hashval;

    for (hashval = 0; *s != '\0'; s++)
        hashval = *s + 31 * hashval;

    return hashval % HASHSIZE;
}

I wrote about collisions in this function a long time ago:
https://pub.gajendra.net/2012/09/notes_on_collisions_in_a_common_string_hashing_function

In this case, the important characteristic with respect to
distribution is that the multiplier is relatively prime to the
modulous.  Their choice of multipler is 31, which is a prime
number, and thus by definition co-prime to all positive moduli

They happen to chose 101 (also prime) for `HASHSIZE` but
assuming reasonably random input, the pathological behavior you
are referring to would be avoided even if the modulus were (say)
128.

	- Dan C.