long long[] map was using JNI type as C/C++ type. General spirit of
JAVA_ARRAYS_TYPEMAPS is to cast individual array elements, not to
rely on potentially incompatible pointer casts.
As for __int64 definition. __int64 is a non-standard Visual-C-specific
type used in win32/jni_md.h. It is defined by other Win32 compilers in
one way or another, obviously for compatibility. It's more appropriate
to give the compiler a chance to make necessary arrangements instead
of reinventing the wheel. This, giving a chance, can be achieved by
including virtually any standard header. Since jni.h includes stdio.h,
defining __int64 in javahead.swg is redundant. Since doing so actually
triggers compilation errors on MinGW if a system header is included
in the %begin section, it's arguably appropriate to omit it.
As for #undef _LP64 removal. Undefining a pre-defined macro, which
_LP64 is, is bad style, and if followed by inclusion of systems
headers, it's actually error-prone. Log suggests that it was added
to resolve a warning. I'm inclined to believe that it rather was a
misunderstanding of some kind. Or a bug in warning subsystem of
some particular compiler version, in which case it would have been
more appropriate to advise users to ignore the warning.
Reportedly the code we were using in the directorin case gave segfaults
in PHP 7.2 and later - we've been unable to reproduce these, but the new
approach is also simpler and should be bit faster too.
Fixes#1527, #1975
PHP already provides all the wrapped constants and all the wrapped
functions except fabs() (PHP provides abs() instead). Rewrapping
the constants causes warnings or errors (depending on PHP version)
and the rewrapped functions seem to be hidden by the built-in
versions, so only wrap fabs() for PHP.
(Even a wrapper for fabs() seems of little use since abs() is already
provided, but really math.i seems of little use more generally since
any general purpose programming language will provide its own maths
functions and constants - the key motivation here is to eliminate
warnings and errors from running the testsuite.)
Add testcase for previous commit.
Add missing assert for future type conversions support that will use
the heap instead of pointer casts (for smart pointer type conversions).
Closes#1963
* array_fix:
add javascript_arays.i fix to changes file
Convert javascript_arrays.i example into testcase
Update .gitignore for java doxygen output
Javascript code formatting corrections
Fix Javascript arrays for modern node versions
Fix for new SWIGV8_ARRAY_NEW definition
Proper array typemaps in Javascript
* vaughamhong-master:
fixed build error - ISO C90 forbids mixed declarations and code for jsc
touch to kickoff another build - from accidental close pull request
Implemented SetModule / GetModule for JSC to allow type sharing across modules - with fix for passing NULL to non-pointer argument
Implemented SetModule / GetModule for JSC to allow type sharing across modules
Context-aware initialization allows to instantiate add-ons multiple
times, most importantly in multiple Workers' contexts. Workers made
first appearance in v10.5. Context-aware initialization was option
earlier than that, even before supported minimum v6.x, yet condition
is chosen more conservatively as NODE_MODULE_VERSION >= 64, a.k.a.
v10.0.
SWIGJSC_ValueIsArray could be implemented by JSValueIsArray in later
versions of Javascript webkit, similar fix to previous commits for v8.
Enhance testing of OUTPUT typemaps to test more than one output.
* pr/new-node-fixes:
Travis testing: Node 12 support not fully working yet
Revert "Merge pull request #3 from tungntpham/new-node-fixes-refactor"
OPTIM: Restructured the code where it checks for V8 version, removing duplicate code and potentially improving the readability.
Nodejs: run tests against Node.js v12
Add support for Node.js v12
Replace Handle with Local depending on Node.js version
Introduce macros to support both Handle and Local types
* commit '8245277ad3':
Remove test for unsupported complex or _Complex by itself
More C99 complex fixes, plus Python tests
Restore _Complex as standalone type
Small corrections for handling C99 _Complex
Properly handle C99 complex types even in C++ mode
Conflicts:
Examples/test-suite/python/complextest_runme.py
Add ability to change the modifiers for the C# and Java
interface generated when using the %interface macros.
For C# use the 'csinterfacemodifiers' typemap.
For Java use the 'javainterfacemodifiers' typemap.
For example:
%typemap(csinterfacemodifiers) X "internal interface"
Closes#1874
Occurs when using the director class from multiple threads - a race condition
initialising block scope static variables.
Block scope static variables are guaranteed to be thread safe in C++11,
so the fix is guaranteed when using C++11. However, most modern compilers
also fix it when using C++03/C++98.
Closes#1862
