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

Wrong offset in datatype with many fields #4

Closed
hsyl20 opened this issue Oct 29, 2015 · 1 comment
Closed

Wrong offset in datatype with many fields #4

hsyl20 opened this issue Oct 29, 2015 · 1 comment

Comments

@hsyl20
Copy link
Contributor

hsyl20 commented Oct 29, 2015

I have a datatype with 32 fields and the offsets of some of the fields are wrong as is the global cSizeOf the structure.

My data structure:

data ObjT = ObjT Word32 Word32 CString MemoryObject (Ptr ()) Word32 Word32 (Ptr Object) (Ptr Object) (Ptr Object)
                 Word32 (Ptr Object) (Ptr Object) Word32 (Ptr (Ptr Object)) (Ptr Object) (Ptr Object) Int32
                 Word32 (Ptr Object) Word32 (Ptr Object) (Ptr ()) (Ptr ()) (Ptr ()) (Ptr ()) (Ptr ()) (Ptr ())
                 (Ptr (Ptr Distance)) Word32 (Ptr Info) Word32 (Ptr ())

where MemoryObject is a 32 bytes object and Ptr are 8 bytes long. The size in C is 264 with the padding bytes. With cSizeOf it is 280.

I think the problem is that fields are not evaluated from left to right hence some offsets are wrong. From the documentation of Generics:

As :+: and :: are just binary operators, one might ask what happens if the datatype has more than two constructors, or a constructor with more than two fields. The answer is simple: the operators are used several times, to combine all the constructors and fields as needed. However, users /should not rely on a specific nesting strategy/ for :+: and :: being used. The compiler is free to choose any nesting it prefers. (In practice, the current implementation tries to produce a more or less balanced nesting, so that the traversal of the structure of the datatype from the root to a particular component can be performed in logarithmic rather than linear time.)

I will try to submit a patch

@hsyl20
Copy link
Contributor Author

hsyl20 commented Oct 29, 2015

I have sent you a PR to fix the issue.

@hsyl20 hsyl20 closed this as completed Oct 29, 2015
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

1 participant