Open twesterhout opened 5 months ago
Thanks for taking the time to capture this, and for the extensive write-up, @twesterhout!
@twesterhout : I wanted to make sure you were aware that https://github.com/chapel-lang/chapel/pull/24746 should have addressed your first of two requests here. If you get a chance to try it out and verify that it provides the benefit you were hoping for, that'd be good to know.
I'm leaving this open due to the second request (reducing the number of header files used to something more minimal)
I've been using a pattern where I first hand-write a C header file such as
and then use it for
export proc
s instead of relying on the Chapel-generated header:This has been causing me some trouble for a few reasons:
@bradcray pointed out that I really shouldn't be doing this, and that I should instead share what's wrong with the Chapel-generated headers that's causing me to write my own.
What makes automatically generated headers unusable for me
Here's what Chapel currently generates for my library (I've removed some of the functions to limit the size of the code block):
So which parts cause trouble?
const
annotations are gone. E.g. in Chapel thels_chpl_extract_diag_c128
function is declared asbut the header declares the
matrixPtr
parameter asls_hs_operator *
.sed
, but that's an extra step._real64
type could probably just be adouble
, right? Or are there systems wheredouble
and_real64
are different?_complex128
type is a bit trickier since_Complex double
wouldn't be accepted in C++ andstd::complex<double>
wouldn't be accepted in C. So having a customtypedef
makes sense (even though I'd probably prefer a compiler flag letting me specify my own), but I'm not sure how good a practice it is in C to make type names starting with an underscore and without an additional namespace prefix, visible to external code.#include
s some internal headers which are not needed for the public interface. E.g. I don't think the "Timing.h" should appear in the header.Feature requests :smiley:
1.
Could we teach the Chapel compiler how to handle
c_ptrConst
in the generated C code? The issue here is that if one naively includesconst
qualifiers in the generated signatures, the C backend might break, because it might try to convert const-qualified parameters to non const-qualified local variables. But that's just my guess... perhaps it's much easier in practice.Motivation
In C it's quite tricky to stay "safe" when const qualifiers are not part of the declaration. Say, I'm writing my own C function that received
double const* xs
as an argument, and I'd like to call a Chapel function that expects ac_ptrConst(real(64))
. I'll have to do(double *)xs
when passing the variable to Chapel. Suppose that I now replacedouble const* xs
withfloat const* xs
in my C code. The compiler won't complain and will happily coerce myxs
into adouble *
, but surely that's undesirable. If the Chapel function had expected adouble const*
instead, I would have gotten a compiler error. Illustration with code:Generated header:
Using the library:
2.
Could the Chapel compiler only include headers that are strictly necessary for the declarations?
Motivation
This would open up a possibility for libraries to have Chapel as an implementation detail. E.g., if I'd like to expose some functions to Python, I could just give a header to CFFI. Unfortunately, right now the Python code will need access to the internal Chapel headers which might not even be available on the system. If we were instead to include "stdint.h" and such for
int64_t
instead of "stdchpl.h", the Python code would not need to have access to a Chapel installation.Sorry if that's not the most structured proposal/request, it's mainly meant to initiate a discussion, and I'd be happy to clarify my wishes and struggles in the comments.