diff options
| -rw-r--r-- | src/parseTools.js | 51 | ||||
| -rwxr-xr-x | tests/runner.py | 2 |
2 files changed, 31 insertions, 22 deletions
diff --git a/src/parseTools.js b/src/parseTools.js index 92fb038a..21852c5d 100644 --- a/src/parseTools.js +++ b/src/parseTools.js @@ -1314,27 +1314,36 @@ function finalizeLLVMFunctionCall(item, noIndexizeFunctions) { // Warn about some types of casts, then fall through to the handling code below var oldType = item.params[0].type; var newType = item.type; - if (isPossiblyFunctionType(oldType) && isPossiblyFunctionType(newType) && - countNormalArgs(oldType) != countNormalArgs(newType)) { - warnOnce('Casting a function pointer type to another with a different number of arguments. See more info in the source'); - // This may be dangerous as clang generates different code for C and C++ calling conventions. The only problem - // case appears to be passing a structure by value, C will have (field1, field2) as function args, and the - // function will internally create a structure with that data, while C++ will have (struct* byVal) and it - // will create a copy before calling the function, then call it with a pointer to the copy. Mixing the two - // first of all leads to two copies being made, so this is a bad idea even regardless of Emscripten. But, - // what is a problem for Emscr ipten is that mixing these two calling conventions (say, calling a C one from - // C++) will then assume that (struct* byVal) is actually the same as (field1, field2). In native code, this - // is easily possible, you place the two fields on the stack and call the function (you know to place the - // values since there is 'byVal'). In Emscripten, though, this means we would need to always do one or the - // other of the two possibilities, for example, always passing by-value structs as (field1, field2). This - // would slow down everything, just to handle this corner case. (Which, just to point out how much of a - // corner case it is, does not appear to happen with nested structures!) - // - // The recommended solution for this problem is not to mix C and C++ calling conventions when passing structs - // by value. Either always pass structs by value within C code or C++ code, but not mixing the two by - // defining a function in one and calling it from the other (so, just changing .c to .cpp, or moving code - // from one file to another, would be enough to fix this), or, do not pass structs by value (which in general - // is inefficient, and worth avoiding if you can). + if (isPossiblyFunctionType(oldType) && isPossiblyFunctionType(newType)) { + var oldCount = countNormalArgs(oldType); + var newCount = countNormalArgs(newType); + if (oldCount != newCount && oldCount && newCount) { + if (!ASSERTIONS) { + warnOnce('Casting a function pointer type to another with a different number of arguments. See more info in the compiler source'); + } else { + warn('Casting a function pointer type to another with a different number of arguments: ' + oldType + ' vs. ' + newType + ', on ' + item.params[0].ident); + } + // This may be dangerous as clang generates different code for C and C++ calling conventions. The only problem + // case appears to be passing a structure by value, C will have (field1, field2) as function args, and the + // function will internally create a structure with that data, while C++ will have (struct* byVal) and it + // will create a copy before calling the function, then call it with a pointer to the copy. Mixing the two + // first of all leads to two copies being made, so this is a bad idea even regardless of Emscripten. But, + // what is a problem for Emscr ipten is that mixing these two calling conventions (say, calling a C one from + // C++) will then assume that (struct* byVal) is actually the same as (field1, field2). In native code, this + // is easily possible, you place the two fields on the stack and call the function (you know to place the + // values since there is 'byVal'). In Emscripten, though, this means we would need to always do one or the + // other of the two possibilities, for example, always passing by-value structs as (field1, field2). This + // would slow down everything, just to handle this corner case. (Which, just to point out how much of a + // corner case it is, does not appear to happen with nested structures!) + // + // The recommended solution for this problem is not to mix C and C++ calling conventions when passing structs + // by value. Either always pass structs by value within C code or C++ code, but not mixing the two by + // defining a function in one and calling it from the other (so, just changing .c to .cpp, or moving code + // from one file to another, would be enough to fix this), or, do not pass structs by value (which in general + // is inefficient, and worth avoiding if you can). + // + // Note that removing all arguments is acceptable, as a vast to void ()*. + } } } var temp = { diff --git a/tests/runner.py b/tests/runner.py index 3a2b3537..cfb0832c 100755 --- a/tests/runner.py +++ b/tests/runner.py @@ -2702,7 +2702,7 @@ def process(filename): output = Popen(['python', EMCC, all_name], stderr=PIPE).communicate() # Check for warning in the generated code generated = open(os.path.join(self.get_dir(), 'src.cpp.o.js')).read() - assert 'Casting a function pointer type to another with a different number of arguments.' in output[1], 'Missing expected warning' + assert 'Casting a function pointer type to another with a different number of arguments' in output[1], 'Missing expected warning' def test_stdlibs(self): if Settings.USE_TYPED_ARRAYS == 2: |