Matlab compiler c language error

1.Matlab compiles C language error, but the code should be correct, other people can run successful, report wrong on my computer.Enter this sentence "mex -v -setup",get

2.but when I compile c, I make a mistake.

[James Tursa]

The file read_csi.c apparently has coding errors, which we can't help you with unless we see the source code.

[Walter Roberson]

Are you using https://github.com/xieyaxiongfly/Atheros-CSI-Tool-UserSpace-APP ?

[ning zhang]

Yes, I used https://github.com/xieyaxiongfly/Atheros-CSI-Tool-UserSpace-APP.

[ning zhang]

Yes, I used it. Could you help me? Thank you .

Answer 1

[Jan]

read_csi.c line 65:

local_h = mxGetData(prhs[0]);

This does not match to the message "missing ; before type". Therefore there must be another problem. I see this in line 78:

    int size[]  = {nr, nc, num_tones};

In strict C (to be exact: C89) all variables must be declared before the first command in a [function - wrong, better:] scope block (thanks Walter). But declaring variables inside the code is allowed in C++. So try to rename the file from .c to .cpp and see, if the compilation works then.

If this solves the problem: Let me mention that you would find several corresponding discussions, if you ask an internet search engine for "Matlab Mex missing ; before type".

[Walter Roberson]

In strict old C, variables can be declared as the first thing in any block (not just function).

[ning zhang]

Jan Simon, When it's changed from c to c++, it's still wrong.

[Jan]

@ning zhnag: Please do not post text as screenshots. It is tedious to read.

Note that the line 66 in the original read_csi.c file is empty. Therefore I cannot even guess, where the show error is coming from. But you find instructions to solve the problem in the message already: insert an explicit cast. The mixing of signed and unsigned integer types and the confusion of int, mwSize and size_t causes troubles usually. The only reliable solution is to use clean data types.

My impression is, that the code contains severe problems. Ask the author for help.

[ning zhang]

I'm sorry to do that.

66

local_h = mxGetData(prhs[0]);

68

    nr_p  = mxGetPr(prhs[1]);

71

nc_p  = mxGetPr(prhs[2]);

74

 num_tones_p = mxGetPr(prhs[3]);

79

mxArray *csi  = mxCreateNumericArray(3, size, mxDOUBLE_CLASS, mxCOMPLEX);

[Jan]

You can fix it as suggested in the messages:

local_h = (unsigned char *) mxGetData(prhs[0]);

While this might be okay, this is dirty:

nr_p  = (unsigned int *) mxGetPr(prhs[1]);

Don't do this. You cannot even be sure if int has 32 or 64 bits, because this depends on the compiler and the OS. At least at this line I would decide not to trust the author and write a function by my own.

[ning zhang]

There was no other way, so I did what you could do. But the last question I won't solve.

mxArray *csi  = (const size_t *)mxCreateNumericArray(3, size, mxDOUBLE_CLASS, mxCOMPLEX);

[Jan]

@ning zhnag: Let me repeat: Please do not post text as screenshots. It is tedious to read and makes it harder to post an answer, because copy&paste is not possible.

size_t size2[3];
size2[0] = (size_t) size[0];
size2[1] = (size_t) size[1];
size2[2] = (size_t) size[2];
mxArray *csi  = mxCreateNumericArray(3, size2, mxDOUBLE_CLASS, mxCOMPLEX);

It looks like you are not sure what the error messages mean. Then modifying a C code is a really bold idea. I would not trust it afterwards. I would not trust my suggestions in the forum also, when the code is used for productive work and not for playing. Better hire a professional, who test the code seriously.

But if you really dare to proceed: The "signed/unsigned mismatch" problem occurs, if you have different integer types on both sides of the < operator. Adjust the types accordingly, but it is not trivial to find out, if signed or unsigned is better here. Maybe an explicit case works also here.

[N Z]

Jan, I'm sorry to ask you this question. I asked the author for a set of his measurements. And the matlab is not wrong. I ran it successfully. Thank you for helping me.

[Walter Roberson]

When you run code and get the expected answer for a single test, that does not mean that the code is right: it can just mean that you did not happen to encounter the conditions under which the code was wrong.

Also, in C, there are a number of constructs whose meaning is not completely specified by the standards, so the behaviour can depend on the compiler being used and upon the compiler settings, so you can encounter situations in which the behaviour of code changes after a seemingly unrelated compiler or operating system or processor change.

[Jan]

@N Z: There is no reason for being sorry. Asking question is welcome here. I only want to support, that you get the required results in a reliable and trustworthy way. C code is magnitudes more fragile than Matlab code. The missing checks of array limits, the power to use pointers to access everything and low level access to the memory offers a high computational speed and the power to drill a hole in your computer in nano seconds. Code can run "successfully" thousands of times by accident, and fail tremendously in another run.