Can I use bool type in c-mex s-function?

[Kate J.]

I have a c-mex s-function whose resulting mex-file is called by my Simulink model. This c-mex s-function calls an external library of functions that were coded in C++, but which use the 'extern "C" ' technique to "convert" this code to C. Some of the functions in this library return a bool type. However, from what I've read, bool isn't a permitted C type.

Currently, in my c-mex s-function, I have declared some variables as bools, which I use to capture the output values of various function calls to the library functions. So far, this seems to work ok (e.g. if the function's return value is bool value "true", and I print out my bool variable (as an int) that is assigned this return value, the value displays as 1).

My questions:
~ Is my using bool variables within my c-mex s-function acceptable? Or, will/can it cause problems? If it's illegal, why wouldn't it cause a compile error or warning, and why does this bool-containing code seem to run without problems?

~ Should I consider altering the library function definitions, so that every function that returns a bool, should be converted to return an int?

Thanks for your input.

[Rune Allnor]

On 3 Nov, 18:47, "Kate J." <kmj.w...@gmail.com> wrote:
> I have a c-mex s-function whose resulting mex-file is called by my Simulink model. This c-mex s-function calls an external library of functions that were coded in C++, but which use the 'extern "C" ' technique to "convert" this code to C. Some of the functions in this library return a bool type. However, from what I've read, bool isn't a permitted C type.

Does your code compile?

The bool data type is in fact a number, where the value indicates
the logical state. You might try and declare the bool values as
void*, and test if the value is 0 or not. I do't remember off the
top of my head whate state a 0 value represents, so check that
with the C docs.

> Currently, in my c-mex s-function, I have declared some variables as bools, which I use to capture the output values of various function calls to the library functions. So far, this seems to work ok (e.g. if the function's return value is bool value "true", and I print out my bool variable (as an int) that is assigned this return value, the value displays as 1).
>
> My questions:
> ~ Is my using bool variables within my c-mex s-function acceptable?

It's been a long time since I coded C, so check with the
C docs what they say about bool.

> Or, will/can it cause problems?

It might. If bool is illegal C, it's up to the compiler vendor
whether to allow such non-standard C code. The fact that things
seem to work with your present compiler does not guarantee that
it will work if you use a different compiler.

> If it's illegal, why wouldn't it cause a compile error or warning, and why does this bool-containing code seem to run without problems?

Because of pragmatics: C and C++ are closely related languages.
It makes sense to bring what works in one language over to
the other - within reason. You *can* force your C(++) compiler
to only accept legal code by setting compiler directives.
Check the documentation.

> ~ Should I consider altering the library function definitions, so that every function that returns a bool, should be converted to return an int?

I'd write a C++ wrapper that calls the C++ library, collects
the bool values, and returns an int to the C caller function.
There might be a little overhead in the function call, but
if you have a good optimizing compiler it might optimize the
wrapper away, altogether.

I'd recommend that you, as a matter of principle, write
standard code, be it either C or C++. It makes sense for
C++ libraries to return bools, so let them do that, for the
benefit of a C++ calling function. Don't let properties or
limitations of the C language influence how you write C++.

C and C++ are different languages, so isolate the handling
of discrepancies in wrapper functions.

Rune

[Kate J.]

Thanks for sharing your input, Rune.

>> Does your code compile?
Yes, it compiles and runs with no apparent problems.

I'll look into using your suggested C++ wrapper to make the two code systems consistent with each other. Thanks again!

[Rune Allnor]

What I would try first, if I were to do this:

namespace MyNamespace {
bool myFunction(double x, float y, int z);
};

Then the wrapper function. Note that it resides
in the global namespace, and also that it is on
the C++ side:

int myFunction(double x, float y, int z)
{
// The compiler might very likely optimize
// all overhead away if you can do things
// like this:

return int(MyNamespace::myFunction(x,y,z));
}

with the added "extern C" keywords added as required.

Rune