Re: Primitive en C pour OCaml

Merci beaucoup pour toutes ces précisions, je comprends mieux ce qui se passe (ainsi que l'organisation interne du compilateur).

Et ça peut expliquer pourquoi une sémantique sous-spécifiée a été choisie (mais je spécule) : les shifts sont traduits vers du code très efficace, mais leurs sémantiques côté machine change selon les plateformes.

En spéculant aussi, j'en arrive à la même conclusion. D'appelant en appelé, on finit toujours par appeler en toute fin une instruction machine : autant prendre le plus dénominateur commun des architectures. Cela permet d'avoir le code le plus efficace sur toute les architectures, et si l'appelant veut une spécification plus large, il la code lui même, ce n'est pas bien compliqué.

let rec ( << ) m n = 
 if n < 0 then m >> (~- n)
 else if n >= 64 then Int64.minus_one
 else Int64.shift_left m n
and ( >> ) m n =
 if n < 0 then m << (~- n)
 else if n >= 64 then Int64.zero
 else Int64.shift_right m n;;
val ( << ) : int64 -> int -> int64 = <fun>
val ( >> ) : int64 -> int -> int64 = <fun>
1L >> 63;;
- : int64 = 0L
1L >> 64;;
- : int64 = 0L
1L >> (-64);;
- : int64 = -1L
1L >> (-63);;
- : int64 = -9223372036854775808L

Je pense que ce doit être aussi la raison pour laquelle en C ou C++ le comportement n'est pas spécifié. Ce sont des instructions très bas niveau, cela permet d'avoir l'instruction la plus efficace sur chaque architecture et il est de la responsabilité de l'appelant de vérifier que le second paramètre se trouve bien dans les bornes où la fonction fait sens sans ambiguïté. Dans des langages haut niveau, on peut même se demander si le choix de la structure de données est le plus adapter au problème si l'on se retrouve à devoir gérer des cas en dehors des bornes « naturelles ».

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.