Skip to content
This repository has been archived by the owner on Sep 22, 2022. It is now read-only.

[mdbx::byte] better forgo char8_t and always use unsigned char #263

Open
yperbasis opened this issue Jan 19, 2022 · 1 comment
Open

[mdbx::byte] better forgo char8_t and always use unsigned char #263

yperbasis opened this issue Jan 19, 2022 · 1 comment
Labels
not-a-bug external issue and/or not a libmdbx's bug proposal question

Comments

@yperbasis
Copy link
Contributor

Currently mdbx::byte is defined as either char8_t or unsigned char. However, char8_t is much more narrow in scope by design and is intended only to help with UTF8 encoding: https://stackoverflow.com/a/57453713. I suggest to always define mdbx::byte as unsigned char.

P.S. In Silkworm we use uint8_t (= unsigned char) as our byte type; so making mdbx::byte always equal to unsigned char would allow us to use slice::byte_ptr() instead of slice::data() + cast.

@erthink
Copy link
Owner

erthink commented Jan 19, 2022

This topic is somewhat confusing, but let me try to explain why libmdbx using char8_t as mdbx::byte.

Essentially I need just the unsigned char * restrict type in C99 terms, i.e. the non-aliasing pointer to unsigned char. However, C++ still doesn't have restrict keyword, but also a char-pointers may be aliased.

On the other hand, while/where uint8_t is defined/provided and CHAR_BIT = 8 the char8_t * actually act the same as the C99' unsigned char * restrict. Both the CHAR_BIT = 8 and uint8_t are prerequirements for libmdbx, so I don't expect any issues, including intentional injection of UB-errors by "extra strict" compilers.

At the same time, the approach of using char8_t has several advantages:

  • the restrict attribute is defined on level of the base type and is inherited by any derived pointer type;
  • some compilers treat __restrict as an attribute of an instance of a type ( i.e. a variable, a specific pointer), but not a type attribute.

Nonetheless, I should think about switching to the uint8_t * __restrict__ for byte pointers.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
not-a-bug external issue and/or not a libmdbx's bug proposal question
Projects
None yet
Development

No branches or pull requests

2 participants