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 function argument type translation #282

Open
dataPulverizer opened this issue May 16, 2021 · 1 comment
Open

Wrong function argument type translation #282

dataPulverizer opened this issue May 16, 2021 · 1 comment
Labels
bug good first issue Good issue for a beginner to take on help wanted

Comments

@dataPulverizer
Copy link

dataPulverizer commented May 16, 2021

Hello,

I am trying to call the fftw3 library using dpp however there is an issue with type translation in particular with function definitions. Within the C library mentioned, consider the function fftw_plan_dft_1d, within the library documentation the type signature is:

fftw_plan fftw_plan_dft_1d(int n, fftw_complex *in, fftw_complex *out,
                           int sign, unsigned flags);

where fftw_complex is defined by

typedef double fftw_complex[2];

The dpp library correctly converts the type fftw_complex as

alias fftw_complex = double[2];

however incorrectly converts the function signature to:

fftw_plan_s* fftw_plan_dft_1d(int, double**, double**, int, uint)

and the compiler gives an error:

Error: function `fftw_plan_dft_1d(int, double**, double**, int, uint)` is not 
          callable using argument types `(int, double[2]*, double[2]*, int, uint)`

Though double* is a generalization of double[2] in this case the substitution is undesirable, not only because it contravenes Data Type Compatibiity as defined in D's spec, and prevents the programmer from using the correct type alias for fftw_complex which is actually safer, but also because it looses type information, and where it to be the case where it inserted the correct aternative double[2] for fftw_complex some flexibility in controlling the behaviour of fftw_complex over the whole library is lost. Also attemping to using double* as fftw_complex could cause the function not to work at all (this has happened to me).

For me the issue is not a show stopper because I'm using dstep and direct translation methods.

All the best.

Thank you

@atilaneves
Copy link
Owner

Oof. I never thought I'd see pointers to arrays in actual production C code as opposed to examples, even if it's hidden behind a typedef.

@atilaneves atilaneves added bug good first issue Good issue for a beginner to take on help wanted labels May 17, 2021
atilaneves added a commit that referenced this issue May 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug good first issue Good issue for a beginner to take on help wanted
Projects
None yet
Development

No branches or pull requests

2 participants