You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Discussing with @edsko, we need to start using the LibC module in the code that we generate.
When translating C code, we must be able to recognize when a C type is one of the standard types that we support. Such types include the following:
Standard types defined in base in Foreign.**
stdint types that map to Haskell types defined in base in Data.Int and Data.Word
Standard types that we define in HsBindgen.Runtime.LibC
A known C type is mapped to a Haskell package, module, and identifier. Making such a mapping implementation general would be useful, since it could be used if/when we add support for translating multiple headers/modules.
Perhaps we can identify standard types using the name and source location information provided by libclang. Note that the actual source header files for many types may differ in different C library implementation, since they have different internal implementations. For example, Musl defines many types in the bits/alltypes.h header file that is included by the standard header files.
@edsko has a promising idea: perhaps we can parse our standard_headers.h bootstrap file and keep track of where the standard types are defined in that execution (which depends on which include directories are configured). We could then use the results to identify standard types as we translate the user code. With this idea, the implementation details should not matter, and we do not need to worry about the same types being imported from different header files.
If we run into trouble, perhaps we can build up a call-stack-style "include stack." I think we can do this with the information provided by libclang while folding, but we could parse the tokens of include directives if necessary.
Should we add checks to confirm that a parsed standard type matches the Haskell definition/instances? We could check that size and alignment are consistent. We could check that structure/union field names and types are consistent.
The text was updated successfully, but these errors were encountered:
Discussing with @edsko, we need to start using the
LibC
module in the code that we generate.When translating C code, we must be able to recognize when a C type is one of the standard types that we support. Such types include the following:
base
inForeign.**
stdint
types that map to Haskell types defined inbase
inData.Int
andData.Word
HsBindgen.Runtime.LibC
A known C type is mapped to a Haskell package, module, and identifier. Making such a mapping implementation general would be useful, since it could be used if/when we add support for translating multiple headers/modules.
Perhaps we can identify standard types using the name and source location information provided by
libclang
. Note that the actual source header files for many types may differ in different C library implementation, since they have different internal implementations. For example, Musl defines many types in thebits/alltypes.h
header file that is included by the standard header files.@edsko has a promising idea: perhaps we can parse our
standard_headers.h
bootstrap file and keep track of where the standard types are defined in that execution (which depends on which include directories are configured). We could then use the results to identify standard types as we translate the user code. With this idea, the implementation details should not matter, and we do not need to worry about the same types being imported from different header files.If we run into trouble, perhaps we can build up a call-stack-style "include stack." I think we can do this with the information provided by
libclang
while folding, but we could parse the tokens of include directives if necessary.Should we add checks to confirm that a parsed standard type matches the Haskell definition/instances? We could check that size and alignment are consistent. We could check that structure/union field names and types are consistent.
The text was updated successfully, but these errors were encountered: