Details
-
Task
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
-
None
Description
People use unsigned char as a stand-in for "byte" in practice (though uint8_t is more explicit).
Thus I heard that uchar* (meaning "pointer to bytes") was once a stand-in for void* back before, well, void* was standardized.
But technologies have evolved since that time immemorial.
Now more often than not uchar* is a requirement for explicit (uchar *), specifically reinterpret_cast<uchar *>.
As a C++ newb, all I know about reinterpret_cast is that it's abused more often than not.
void* not only comes with implicit casts, but this cast is also standardized.
In comparison, I recall UBSAN complained about non-explicit uchar* casting before.
Our in-house HASH set is a significant user of uchar*.
Unless we replace all our hash-collections with C++ std::(unordered_)map/set (which pure-C instances might not), this discrepancy is bound to continue causing inconveniences.
Attachments
Issue Links
- relates to
-
MDEV-35460 Phase out integer typedefs and macros in favor of C/C++ Standard ones
-
- Open
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Description |
People use {{unsigned char}} as a stand-in for "byte" in practice (though {{uint8_t}} is more explicit).
Thus I heard that {{uchar*}} (meaning "pointer to bytes") was once a stand-in for {{void*}} back before, well, {{void*}} was standardized. But technologies have evolved since that time immemorial. Now more often than not {{uchar*}} is a requirement for explicit {{(uchar *)}}, specifically {{reinterpret_cast<uchar *>}}. As a C++ newb, all I know about {{reinterpret_cast}} is that it's abused more often than not. {{void*}} not only comes with implicit casts, but this cast is also standardized. In comparison, I recall UBSAN complained about non-explicit {{uchar*}} casting before. Our in-house {{HASH}}set is a significant user of {{uchar*}}. Unless we replace all our hash-collections with C++ {{std::}}({{unordered_}}){{map}}/{{set}}s (which pure-C instances might not), this discrepancy is bound to continue causing inconveniences. |
People use {{unsigned char}} as a stand-in for "byte" in practice (though {{uint8_t}} is more explicit).
Thus I heard that {{uchar*}} (meaning "pointer to bytes") was once a stand-in for {{void*}} back before, well, {{void*}} was standardized. But technologies have evolved since that time immemorial. Now more often than not {{uchar*}} is a requirement for explicit {{(uchar *)}}, specifically {{reinterpret_cast<uchar *>}}. As a C++ newb, all I know about {{reinterpret_cast}} is that it's abused more often than not. {{void*}} not only comes with implicit casts, but this cast is also standardized. In comparison, I recall UBSAN complained about non-explicit {{uchar*}} casting before. Our in-house {{HASH}} set is a significant user of {{uchar*}}. Unless we replace all our hash-collections with C++ {{std::}}({{unordered_}}){{map}}/{{set}} (which pure-C instances might not), this discrepancy is bound to continue causing inconveniences. |
| Link | This issue relates to MDEV-35460 [ MDEV-35460 ] |