Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Hash clash in polymorphic variants
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Kuba Ober <ober.14@o...>
Subject: Re: [Caml-list] Hash clash in polymorphic variants
> > > > 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