Skip to content

Improve handling of "Bad pointer type solution" #680

Open
@mattmccutchen-cci

Description

@mattmccutchen-cci

Currently, if there is a contradiction in the pointer type constraints, the constraint solver automatically generates a constraint to wild on one (or more?) of the atoms affected by the contradiction, with the root-cause message "Bad pointer type solution". Forcing the pointer to wild avoids compile errors due to the pointer type contradiction, but we currently don't have an easy way for the user to find and resolve the contradiction in order to proceed with porting. This is an umbrella issue for anything we might do to improve the situation. I'm going ahead and filing an issue as Mike requested, even though John knows much more about the topic than I do.

Some fragmentary thoughts:

  • John said Wrong return type on unsafe use #127 is related.
  • One way for a user to move forward with porting is to manually give the pointer the checked type that seems to be appropriate. Of course, this might cause a compile error or a "Bad pointer type solution" message elsewhere in the code.
  • It would help if 3C outputs the path through the constraint graph that produces the contradiction. For example, if we have constraints of the form "PTR <= x <= y <= z <= ARR", then 3C would show the names and source locations of the atoms x, y, and z. There were concerns about whether fixing pointer types during the multi-pass solving algorithm might affect 3C's ability to accurately identify contradiction paths, but I think we can just scan for contradictions during the first pass, since fixing pointer types solved during one pass cannot introduce a contradiction where none existed before.
  • Once the user knows what the contradiction is, they still need a way to remove it so they can re-run 3C and it will generate better output. If there isn't a natural way to change the code to avoid generating one of the pointer-type constraints, we might need some code pattern or pragma recognized by 3C specifically to copy a pointer without generating a pointer-type constraint, so the user can break the chain.

We'd like to collect some examples of programs that trigger "Bad pointer type solution" to inform our design. @Zanedaws If you do find a resolution to one of the real cases that came up in your Icecast port, would you do us the favor of posting a simplified version of the code here and explaining what you did?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions