From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ober.14@osu.edu>
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr
X-Spam-Level: 
X-Spam-Status: No, score=0.4 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE 
	autolearn=disabled version=3.1.3
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105])
	by yquem.inria.fr (Postfix) with ESMTP id 7FA33BC6B
	for <caml-list@yquem.inria.fr>; Fri, 11 Jan 2008 14:30:32 +0100 (CET)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aq4HAGP+hkdDWxLC/2dsb2JhbACBVpAamDo
X-IronPort-AV: E=Sophos;i="4.24,271,1196636400"; 
   d="scan'208";a="21128470"
Received: from ip67-91-18-194.z18-91-67.customer.algx.net (HELO server1.bertec.net) ([67.91.18.194])
  by mail4-smtp-sop.national.inria.fr with ESMTP; 11 Jan 2008 14:30:31 +0100
Received: from kuba.bertec.net (kuba.bertec.net [192.168.2.16])
	by server1.bertec.net (Postfix) with ESMTP id BFEEB105830
	for <caml-list@yquem.inria.fr>; Fri, 11 Jan 2008 08:30:30 -0500 (EST)
From: Kuba Ober <ober.14@osu.edu>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Hash clash in polymorphic variants
Date: Fri, 11 Jan 2008 08:30:29 -0500
User-Agent: KMail/1.9.6 (enterprise 0.20071123.740460)
References: <200801101709.14110.jon@ffconsultancy.com> <200801102124.26245.jon@ffconsultancy.com> <003a01c853d1$718d8730$9201a8c0@countertenor>
In-Reply-To: <003a01c853d1$718d8730$9201a8c0@countertenor>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200801110830.29988.ober.14@osu.edu>
X-Spam: no; 0.00; hash:01 variants:01 constructors:01 avoided:01 clashing:01 hash:01 variants:01 translating:01 enum:01 bindings:01 clashing:01 clashes:01 bindings:01 non-issue:01 cheers:01 

> > > > ISTR advice that constructors sharing the first few characters should
> > > > be avoided in order to reduce the likelihood of clashing hash values
> > > > for polymorphic variants. Is that right?
> > >
> > > I don't think it's worth worrying about.
> >
> > I'm interested in automatically translating the GL_* enum from OpenGL
> > into
> > polymorphic variants. So although it is generated code I have little
>
> I presume you're worried about the bindings clashing internally rather than
> someone who uses the library happening to use a variant that clashes?
>
> You can do something about it - when you're generating your bindings, you
> can use the hash_variant() C function to detect the collisions yourself. If
> you detect one, you can either issue *your own* warning while generating
> the bindings allowing you to specify specific renaming for the program
> generating your bindings or you could append digits to the names until the
> collisions disappear (which is likely, though not guaranteed, to happen
> quickly).
>
> It's slightly ugly, but then the possibility of collisions in the first
> place is IMHO ugly too!

Are those collisions of any real importance? I mean, do they break anything? 
If all they do is imply linearly searching a list of a few elements, for the 
colliding entry, then it's a non-issue?

Cheers, Kuba