Skip to content

Commit 856fcff

Browse files
committed
fix up links broken by moving sections
1 parent f037f32 commit 856fcff

5 files changed

Lines changed: 19 additions & 16 deletions

File tree

site/source/docs/index.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ Documentation Home (under-construction)
88

99
introducing_emscripten/index
1010
getting_started/index
11-
coding/index
11+
porting/index
1212
optimizing/index
1313
compiling/index
1414
packaging/index

site/source/docs/porting/guidelines/Asm-pointer-casts.rst

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,16 @@
1+
=======================================
2+
Function Pointer Issues (wiki-import)
3+
=======================================
4+
5+
There are three general issues with function pointers:
6+
7+
#. clang generates different code for C and C++ calls when a structure is passed **by value**. The two formats are incompatible in how we generate code in Emscripten, but each is compatible with itself. You should see a warning during compilation about this, and the workaround is to either not mix C and C++ in that location (just renaming a **.c** file to **.cpp** for example) or to pass the structure by reference. (More specifically, one convention is ``struct byval`` and the other is ``field a, field b``.)
8+
9+
#. In **asm.js** mode, there is an additional concern, with function tables. Without **asm.js**, all function pointers use a single table, but in **asm.js** each function pointer type has its own table (this allows the JavaScript engine to know the exact type of each function pointer call, and optimize those calls much better than normally). As a consequence though, if you have a function that is say ``int (int)`` (return int, receive int) and you cast it to ``void (int)`` (no return, receive int), then the function pointer call will fail because we are looking in the wrong table. This is undefined behavior in C in any case, so it is recommended to refactor code to avoid this type of situation. You should see compilation warnings about these things. See :ref:`Asm-pointer-casts` for more information.
10+
11+
#. A related issue to do with function pointers is that in ``-O2`` and above we optimize the size of the separate function tables. That means that two functions can have the same function pointer so long as their type is different, and so potentially comparing function pointers of different types can give false positives. Also, it makes bugs with incorrect function pointers potentially more misleading, since there are fewer "holes" in function tables (holes would throw an error instead of running the wrong code). To check if this is causing issues, you can compile with ``-s ALIASING_FUNCTION_POINTERS=0``.
12+
13+
114
.. _Asm-pointer-casts:
215

316
===============================

site/source/docs/porting/guidelines/CodeGuidelinesAndLimitations.rst

Lines changed: 1 addition & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
.. _CodeGuidelinesAndLimitations:
22

33
=========================================================
4-
Code Guidelines and Limitations (under-construction)
4+
Portability Guidelines (under-construction)
55
=========================================================
66

77
This article describes the types of code that are more difficult to compile, code which compiles but may run more slowly, and issues and limitations with specific APIs. Developers will find it useful for evaluating the effort to port and re-write code.
@@ -50,13 +50,3 @@ Networking
5050
- Emscripten supports libc networking functions, but since JavaScript networking is asynchronous, you must limit yourself to asynchronous (nonblocking) operations.
5151

5252

53-
Function pointer issues
54-
=======================
55-
56-
There are three general issues with function pointers:
57-
58-
#. clang generates different code for C and C++ calls when a structure is passed **by value**. The two formats are incompatible in how we generate code in Emscripten, but each is compatible with itself. You should see a warning during compilation about this, and the workaround is to either not mix C and C++ in that location (just renaming a **.c** file to **.cpp** for example) or to pass the structure by reference. (More specifically, one convention is ``struct byval`` and the other is ``field a, field b``.)
59-
60-
#. In **asm.js** mode, there is an additional concern, with function tables. Without **asm.js**, all function pointers use a single table, but in **asm.js** each function pointer type has its own table (this allows the JavaScript engine to know the exact type of each function pointer call, and optimize those calls much better than normally). As a consequence though, if you have a function that is say ``int (int)`` (return int, receive int) and you cast it to ``void (int)`` (no return, receive int), then the function pointer call will fail because we are looking in the wrong table. This is undefined behavior in C in any case, so it is recommended to refactor code to avoid this type of situation. You should see compilation warnings about these things. See :ref:`Asm-pointer-casts` for more information.
61-
62-
#. A related issue to do with function pointers is that in ``-O2`` and above we optimize the size of the separate function tables. That means that two functions can have the same function pointer so long as their type is different, and so potentially comparing function pointers of different types can give false positives. Also, it makes bugs with incorrect function pointers potentially more misleading, since there are fewer "holes" in function tables (holes would throw an error instead of running the wrong code). To check if this is causing issues, you can compile with ``-s ALIASING_FUNCTION_POINTERS=0``.

site/source/docs/porting/index.rst

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,8 +1,8 @@
11
.. _integrating-porting-index:
22

3-
==================================================
4-
Integrating/Porting (under-construction)
5-
==================================================
3+
================================
4+
Porting (under-construction)
5+
================================
66

77
This section is for articles explaining the integration points with Emscripten, and general coding guidelines to help you with porting.
88

site/source/index.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -33,7 +33,7 @@ News
3333

3434
docs/introducing_emscripten/index
3535
docs/getting_started/index
36-
docs/coding/index
36+
docs/porting/index
3737
docs/optimizing/index
3838
docs/compiling/index
3939
docs/packaging/index

0 commit comments

Comments
 (0)