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

CAMLreturn invites incorrect use #4068

Closed
vicuna opened this issue Jul 24, 2006 · 1 comment
Closed

CAMLreturn invites incorrect use #4068

vicuna opened this issue Jul 24, 2006 · 1 comment
Labels

Comments

@vicuna
Copy link

vicuna commented Jul 24, 2006

Original bug ID: 4068
Reporter: @mmottl
Status: closed (set by @damiendoligez on 2006-07-25T09:02:18Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 3.08.4
Category: ~DO NOT USE (was: OCaml general)
Monitored by: smimram @mmottl

Bug description

The definition of CAMLreturn is:

#define CAMLreturn(result) do{
caml_local_roots = caml__frame;
return (result);
}while(0)

This means that "result", which may be an expression, is evaluated outside of the protected block. I have already seen several instances where people who didn't know about this subtlety wrote something like e.g. "CAMLreturn(caml_copy_string(x))", where "x" is part of an object protected by the CAMLparam/return block. This may, of course, lead to segfaults if the string allocation triggers the GC.

The following definition would prevent people from making this common mistake:

#define CAMLreturn(result) do{
value v_res = (result);
caml_local_roots = caml__frame;
return v_res;
}while(0)

The C-compiler will optimize away assignments of values anyway.

@vicuna
Copy link
Author

vicuna commented Jul 25, 2006

Comment author: @damiendoligez

I think your example still works, because there is no allocation between the assignment
to caml_local_roots and the use of the variable.

I'm fixing this problem in the 3.09 branch.

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