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

Misleading comment in cparser/StructPassing.ml #318

Open
sixcy opened this issue Oct 14, 2019 · 2 comments
Open

Misleading comment in cparser/StructPassing.ml #318

sixcy opened this issue Oct 14, 2019 · 2 comments

Comments

@sixcy
Copy link

sixcy commented Oct 14, 2019

In the case of a struct passing using SP_split_args, this code of cparser/StructPassing.ml is actually misleading

let classify_param env ty =
  if is_composite_type env ty then begin
    match !struct_passing_style with
    | SP_ref_callee -> Param_unchanged
    | SP_ref_caller -> Param_ref_caller
    | _ ->
      match sizeof env ty, alignof env ty with
      | Some sz, Some al ->
          Param_flattened ((sz + 3) / 4, sz, al)
      | _, _ ->
          Param_unchanged  (* should not happen *)
  end else
Param_unchanged

The should not happen part actually happens for the test in test/regression/struct2.c :

struct B;
int f(struct B);
struct B { double d; };
int g() { struct B b; return f(b); }

This can be tested by replacing Param_unchanged (*should not happen *) by a failwith "Should not happen", then attempting to compile test/regression/struct2.c, on the x86_32-linux architecture.

@sixcy
Copy link
Author

sixcy commented Oct 14, 2019

Thankfully, at first glance there seems to be no hidden bug.

As I understand it, when parsing int f(struct B), this classify_param is called - since no information is available yet for struct B, the sizeof and alignof return None. classify_param is then returning Param_unchanged.

However, classify_param is called again when parsing f(b), where the structure has this time the relevant information available. So there seems to be no misbehaviour here.

@xavierleroy
Copy link
Contributor

You,re right that the comment was written with function definitions in mind (where incomplete structs cannot occur) and doesn't match what happens with function declarations (as in your example). At least a better comment is in order.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants