ESP32-C3 printout of #Ref seems wrong about atomvm HOT 7 CLOSED

There was a bug, as you mentioned the format string was wrong, the correct portable format string is: "#Ref<0.0.0.%" PRIu64 ">" which is specific for uint64_t.

%lu is usually good for unsigned 64-bit integers on 64-bit archs, but that's not the case for ESP32.

#1113 fixes this.

from atomvm.

It looks like this might be an issue that came up with ESP-IDF version 5.0 that we just haven't caught yet. There were changes to some of the default types. This is documented in the migrating 4.4 to 5.0 guide:

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

from atomvm.

If you have a 4.4 version of ESP-IDF available could you try building with the unmodified nifs.c and term.c and see if it works as expected with a v4.4 build?

from atomvm.

The Socket={<<"">>,#Ref<0.0.0.16>} is the (opaque) socket -- you are not (generally) supposed to peek inside the contents of this type. The ref part of the opaque type is due to an internal implementation detail, but it is used to uniquely identify different socket instances.

Are you saying that something like:

erlang:display(erlang:make_ref()),
erlang:display(erlang:make_ref()),
erlang:display(erlang:make_ref()),
erlang:display(erlang:make_ref()),
erlang:display(erlang:make_ref()),

all print the same values?

from atomvm.

I think you have a similar ifdef in term.c function term_funprint.

from atomvm.

I think you have a similar ifdef in term.c function term_funprint.

yes, you are right, I started working on that, but also I need to remove some hardcoded information. I will try to make that fix by v0.6.1.

from atomvm.

I reported on main branch but I will close this one since it is now merged to release branch. Thanks!

from atomvm.