debug-engine: fix a few type mismatches

[yamt]

debug-engine: fix a few type mismatches

Note: on some targets, int32_t is a long.
for example, GCC shipped with the recent ESP-IDF has such a
configuration. [1]

[1] apache/nuttx#15755 (comment)

cf.
apache/nuttx#16022
https://docs.espressif.com/projects/esp-idf/en/stable/esp32/migration-guides/release-5.x/5.0/gcc.html#espressif-toolchain-changes

also, use strict prototypes as it's complained by the same version of GCC.

[lum1n0us]

Note: on some targets, int32_t is a long.

How about uint32? will it be a problem too ?

[yamt]

Note: on some targets, int32_t is a long.

How about uint32? will it be a problem too ?

uint32 is an alias of uint32_t. the code this PR fixes is using uint32/int32.

theoretically, it's possible to make uint32 and uint32_t different. but i guess it causes far more issues than fixes.

[lum1n0us]

So, should we use unsigned int to replace uint32 in the function signatures in files located in core/iwasm/libraries/debug-engine/?

Plus, I noticed some int32 in function signatures have been replaced and some are not, including several static variables.

[yamt]

So, should we use unsigned int to replace uint32 in the function signatures in files located in core/iwasm/libraries/debug-engine/?

why do you think so?

Plus, I noticed some int32 in function signatures have been replaced and some are not, including several static variables.

are you suggesting it's a problem? how?

[lum1n0us]

I suspect the issue arose when I saw the changes in core/iwasm/libraries/debug-engine/gdbserver.*. It appears to be an incomplete modification. Please help to me to understand the situation.

• If treating "int32 like a long" is the problem, then by the same reasoning, "uint32" could also be problematic.
• Plus, some int32 in function signatures have been replaced and some are not, including several static variables.

$ egrep -rnc "uint32|int32" core/iwasm/libraries/debug-engine
core/iwasm/libraries/debug-engine/packets.c:1
core/iwasm/libraries/debug-engine/debug_engine.cmake:0
core/iwasm/libraries/debug-engine/utils.c:3
core/iwasm/libraries/debug-engine/handler.c:20
core/iwasm/libraries/debug-engine/handler.h:1
core/iwasm/libraries/debug-engine/gdbserver.c:4
core/iwasm/libraries/debug-engine/debug_engine.h:15
core/iwasm/libraries/debug-engine/debug_engine.c:48
core/iwasm/libraries/debug-engine/gdbserver.h:2
core/iwasm/libraries/debug-engine/utils.h:5
core/iwasm/libraries/debug-engine/packets.h:0

[yamt]

we should not assume int32 or int32_t is int because they can be long or even other types.

for example, os_socket_bind takes int *port. so i changed port to int.

[lum1n0us]

we should not assume int32 or int32_t is int because they can be long or even other types.

Totally agree. If treating "int32 like a long" is the problem, then by the same reasoning, "uint32" could also be problematic. Right?

[yamt]

we should not assume int32 or int32_t is int because they can be long or even other types.

Totally agree. If treating "int32 like a long" is the problem, then by the same reasoning, "uint32" could also be problematic. Right?

yes.

[lum1n0us]

we should not assume int32 or int32_t is int because they can be long or even other types.

Totally agree. If treating "int32 like a long" is the problem, then by the same reasoning, "uint32" could also be problematic. Right?

yes.

Then, two problems:

• should we use unsigned int to replace uint32 in the function signatures in files located in core/iwasm/libraries/debug-engine?
• There are still int32 in function signatures in core/iwasm/libraries/debug-engine should we leave them as they are or use int to replace them as well?

[yamt]

we should not assume int32 or int32_t is int because they can be long or even other types.

Totally agree. If treating "int32 like a long" is the problem, then by the same reasoning, "uint32" could also be problematic. Right?

yes.

Then, two problems:

* should we use unsigned int to replace uint32 in the function signatures in files located in core/iwasm/libraries/debug-engine?

* There are still `int32` in function signatures in _core/iwasm/libraries/debug-engine_ should we leave them as they are or use `int` to replace them as well?

i don't see any reasons to replace them all.
they are not problems as far as they are used consistently.

[lum1n0us]

Certainly. Just out of curiosity, if the next contributor intends to add a new function in core/iwasm/libraries/debug-engine/gdbserver.h, should they use int/unsigned int or int32/uint32? What's the general guideline here?

[yamt]

Certainly. Just out of curiosity, if the next contributor intends to add a new function in core/iwasm/libraries/debug-engine/gdbserver.h, should they use int/unsigned int or int32/uint32? What's the general guideline here?

nothing specific to debug-engine.
the common problematic pattern is int32 * vs int *.

[lum1n0us]

LGTM

[xiaoxiang781216]

LGTM

[xiaoxiang781216]

@no1wudi could you merge this patch to unblock ci on nuttx side?

[TianlongLiang]

LGTM