Original bug ID: 1583
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Allen Stoughton
Version: 3.06
OS: Linux (RedHat 7.2)
Submission from: dhcp9.user.cis.ksu.edu (129.130.11.178)

As shown in the example included below, ocamlyacc sometimes generates code
that's not type safe. The problem seems to come up when the types specified
for
symbols using %type are incorrect, but are unifiable with the real types.

In the supplied example, the function returned as the value of the symbol
start has type (string -> 'a) -> 'a, but the type specified by the user is
('s -> unit) -> unit. In the file parser.ml generated by ocamlyacc,
the function is constrained to have type ('s -> unit) -> unit, and is then
turned into a value of type Obj.t using Obj.repr. Later, this value is
turned back into a function using Obj.obj, and is expicitly given the
type ('s -> unit) -> unit. It can then be passed an argument of type
(int -> unit), resulting in a violation of the type system.

The problem seems to exist because ocamlyacc is making an assumption about
how type constraints work that is incorrect. Presumably, ocamlyacc is
hoping that the expression

((fun ppf -> ppf "file.f") : ('s -> unit) -> unit)

won't typecheck. Instead, it does typecheck, but with the type
(string -> unit) -> unit. But when this value is turned into an object and
then brought back to a function, it's given the incorrect type
('s -> unit) -> unit, leading to problems.

--------------------- parser.mly

%token EOF

%start start

%type < ('s -> unit) -> unit > start

%%

start :
EOF
{ fun ppf -> ppf "file.f" }
--------------------- main.ml

let main x = Parser.EOF() in
let pi = open_in "emptyfile" in
let lexbuf = Lexing.from_channel pi in
let f = Parser.start main lexbuf in
f (Printf.printf "file:%d\n")