1. 9
    1. 17

      The code blocks’ font color seems to be the same as their background color?

      1. 1

        Same here, I’m only able to read them when highlighting them: https://p.mort.coffee/srf.png

        Reader mode works well enough though.

        EDIT: outline.com works even better: https://www.outline.com/https://subethasoftware.com/2021/04/27/c-printf-and-pointers/

        1. 3

          That is a really nice image upload service you have there. Nice frontpage / manpage as well!

          1. 2

            Thanks! I wrote it because I wasn’t really happy with other hosts. (And to learn rust.) It handles code really well too.

    2. 3

      This is particularly important if you might run on architectures with unusual pointer sizes. Some microcontrollers have smaller address registers than data registers so the integer type that is the same size as a pointer might not be obvious. This is also true on some mainstream systems: on Win64, long is 32 bits, but pointers are 64 and so you will get truncation if you try to print a pointer as a long or int. On CHERI, a pointer is a 128-bit quantity carrying some metadata. In our current libc, %p will print the address as it would a 64-bit pointer but %#p will print the address and all of the metadata as well.

      1. 1

        Segmented x86 will cause another thorn your side for pointer types.

    3. 3

      If you’re printing a pointer, you should probably use the pointer specifier, %p… That’ll work with pointers, regardless of your architecture, without messing with uintptr_t or inttype.h macros.

      1. 2

        The article mentions %p, and how it’s not available on their target architecture.