Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

danger dans compare custom? #8208

Closed
vicuna opened this issue Jul 16, 2003 · 3 comments
Closed

danger dans compare custom? #8208

vicuna opened this issue Jul 16, 2003 · 3 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Jul 16, 2003

Original bug ID: 1756
Reporter: administrator
Status: closed (set by @damiendoligez on 2012-01-26T14:18:59Z)
Resolution: fixed
Priority: normal
Severity: minor
Fixed in version: 3.12.1
Category: ~DO NOT USE (was: OCaml general)

Bug description

Il me semble que le code pour le cas Custom_tag dans compare.c est
potentiellement dangereux, car il ne verifie pas que les deux
blocs utilisent la meme fonction de comparaison.

Le probleme peut se poser si on compare deux objets custom differents
(mais de meme taille), dont on a prealablement oublie' le type par
Obj.repr.

Il me semble qu'il faudrait ajouter la ligne:

if (Custom_ops_val(v1) != Custom_ops_val(v2))
return ((value)Custom_ops_val(v1) >> 1) - ((value)Custom_ops_val(v2) >> 1);

Ca peut paraitre un peu tire' par les cheveux, mais ca me semble etre
le seul cas ou` [compare (Obj.repr a) (Obj.repr b)] est
potentiellement incorrect.

D'autre part, si Custom_ops_val(v1)->compare == NULL, l'exception
Failure est levee, alors que dans les autres cas c'est Invalid_argument.

    Jacques
@vicuna
Copy link
Author

vicuna commented Jul 16, 2003

Comment author: administrator

fixed Failure by DD & XL on 2003-07-16

@vicuna
Copy link
Author

vicuna commented Jul 18, 2003

Comment author: administrator

Il me semble que le code pour le cas Custom_tag dans compare.c est
potentiellement dangereux, car il ne verifie pas que les deux
blocs utilisent la meme fonction de comparaison.

Le probleme peut se poser si on compare deux objets custom differents
(mais de meme taille), dont on a prealablement oublie' le type par
Obj.repr.

Comme tu dis, c'est un peu tiré par les cheveux :-)

Il me semble qu'il faudrait ajouter la ligne:

if (Custom_ops_val(v1) != Custom_ops_val(v2))
return ((value)Custom_ops_val(v1) >> 1) - ((value)Custom_ops_val(v2) >> 1);

On peut, par prudence, comparer les Custom_ops_val et s'ils diffèrent,
lever une exception Invalid_argument. Mais comparer les pointeurs
Custom_ops_val est un peu bizarre.

D'autre part, si Custom_ops_val(v1)->compare == NULL, l'exception
Failure est levee, alors que dans les autres cas c'est Invalid_argument.

Bien vu. C'est réparé.

  • Xavier

@vicuna
Copy link
Author

vicuna commented Jan 26, 2012

Comment author: @damiendoligez

Heterogenous comparison fixed by XL in 3.12.1 (commit 11037) and trunk [3.13.0] (commit 11123).

FTR, this could be triggered without using Obj, with exceptions or first-class modules.

@vicuna vicuna closed this as completed Jan 26, 2012
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant