| Anonymous | Login | Signup for a new account | 2013-06-18 09:03 CEST |  |
| Main | My View | View Issues | Change Log | Roadmap |
| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | |||
| 0001756 | OCaml | OCaml general | public | 2003-07-16 12:11 | 2012-01-26 15:18 | |||
| Reporter | administrator | |||||||
| Assigned To | ||||||||
| Priority | normal | Severity | minor | Reproducibility | always | |||
| Status | closed | Resolution | fixed | |||||
| Platform | OS | OS Version | ||||||
| Product Version | ||||||||
| Target Version | Fixed in Version | 3.12.1 | ||||||
| Summary | 0001756: danger dans compare custom? | |||||||
| 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 | |||||||
| Tags | No tags attached. | |||||||
| Attached Files | ||||||||
 Relationships |
|
 Relationships |
|
Notes |
|
|
(0000158) administrator (administrator) 2003-07-16 17:55 |
fixed Failure by DD & XL on 2003-07-16 |
|
(0000159) administrator (administrator) 2003-07-18 16:31 |
> 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 |
|
(0006812) doligez (manager) 2012-01-26 15:18 |
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. |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2005-11-18 10:13 | administrator | New Issue | |
| 2012-01-26 15:18 | doligez | Note Added: 0006812 | |
| 2012-01-26 15:18 | doligez | Severity | feature => minor |
| 2012-01-26 15:18 | doligez | Status | acknowledged => closed |
| 2012-01-26 15:18 | doligez | Resolution | open => fixed |
| 2012-01-26 15:18 | doligez | Fixed in Version | => 3.12.1 |
| 2012-01-26 15:18 | doligez | Description Updated | View Revisions |
|
Issue History |
| Copyright © 2000 - 2011 MantisBT Group |
 |