5 ms·

As an array of uint8_t? I'm pretty sure that's wrong, and that it should be char instead. Usual OS network APIs are char based, and the fact that the network is

As an array of uint8_t? I'm pretty sure that's wrong, and that it should be char instead. Usual OS network APIs are char based, and the fact that the network is technically about "octets" shouldn't matter behind those APIs. Or is my thinking wrong?

ambrop7 8y ago
On virtually all modern computers chars are 8-bit and casting the address to uint8_t* is perfectly fine (due to specific provisions in the standards that I am too lazy to find). And you need unsigned so that expressions like x + (y << 16) do the right thing. With that in mind, I use uint8_t as opposed to unsigned char to emphasize that it is 8-bit and also for less typing :)
- saagarjha 8y ago
  > On virtually all modern computers chars are 8-bit and casting the address to uint8_t* is perfectly fine (due to specific provisions in the standards that I am too lazy to find). Are you sure the provision doesn't say "char *"?
  - ambrop7 8y ago
    Yeah that may be true, see the comment from amluto.
alxlaz 8y ago
uint8_t is guaranteed to always be an octet, and stdint types (uint8_t, int32_t, uint32_t etc.) are also the recommended types to use when you want to make the size and signedness of the data clear. An array of uint8_t is definitely correct, and it's also the right thing to do in 2018. An array of char is something you should only use to store human-readable character in array form. Many OS network APIs are "char based" because the C standard requires that sizeof char be exactly one byte, so it used to be a convenient shorthand, but that's not the case anymore.
- viraptor 8y ago
  > the C standard requires that sizeof char be exactly one byte That's at least 1, not exactly 1. It's POSIX that requires char to be 8bit.
  - evincarofautumn 8y ago
    It’s “exactly one byte” in the sense that by definition, sizeof(char) = 1, but it’s “at least one byte” in the sense that CHAR_BIT ≥ 8.
  - alxlaz 8y ago
    Nope, the C standard requires that sizeof char = 1, regardless of the width of a byte :-).
    - jstimpfle 8y ago
      One of the things I was not sure about is whether the size of uint8_t is guaranteed to be 1 as well. And whether that means the both are pointer-compatible. And if so, where is this specified?
      - alxlaz 8y ago
        As far as I know, C99 makes no requirements about the byte width of int8_t, only about its bit width. The relevant bits are in section 7.18.1.1 . There are few architectures and runtimes where this is relevant anymore, and the answer is really best given on a case-by-case basis. I think it's technically possible to make the two pointer-compatible on architectures with wider bytes. Last time I used one it was Analog Devices' SHARC, and I think they were pointer-compatible, but that was a long time ago, so take it with a grain of salt.
- deleted 8y ago
  [deleted]
jstimpfle 8y ago
Downvoters, my question was wether int8_t* and char* are interchangeable. I can't see why that's a bad question to ask. Given "char* buf", there might well be a difference between "(uint8_t) buf[1]" and "((uint8_t* )buf)[1]". Now, upon further researching it looks like uint8_t always has size 1 (as does char), but I'm still not positive that the second expression is technically valid.
- topspin 8y ago
  > my question was whether int8_t* and char* are interchangeable They are not. Not every "C" compiler complies with whatever standard you care to cite. There are DSP platforms[1], for instance, where char is 16 bits. Obviously any hypothetical pointer arithmetic on such a platform must differ between (u)int8_t and char. The intent of (u)int8_t is that such a platform will either a.) correctly implement (u)int_8 and operate on exactly 8 bits as intended or b.) fail to compile. This is demonstrably different than assuming char is 8 bits and yet compiling when it is not. [1] for sale here: https://www.digikey.com/en/product-highlight/t/texas-instruments/c2000 https://www.digikey.com/en/product-highlight/t/texas-instrum...
amluto 8y ago
There's a different consideration: as far as I know, it's an open question whether uint8_t* and int8_t* have the same special aliasing rules that apply to char* and unsigned char. A strict reading suggests that they do not. So there may be cases where using uint8_t is UB but using unsigned char* is not. I think that all compilers consider this to be a bit of defect in the relevant standards, and they'll compile your code the way you expect.

ambrop7 8y ago

On virtually all modern computers chars are 8-bit and casting the address to uint8_t* is perfectly fine (due to specific provisions in the standards that I am too lazy to find). And you need unsigned so that expressions like x + (y << 16) do the right thing. With that in mind, I use uint8_t as opposed to unsigned char to emphasize that it is 8-bit and also for less typing :)

saagarjha 8y ago
> On virtually all modern computers chars are 8-bit and casting the address to uint8_t* is perfectly fine (due to specific provisions in the standards that I am too lazy to find). Are you sure the provision doesn't say "char *"?
- ambrop7 8y ago
  Yeah that may be true, see the comment from amluto.

alxlaz 8y ago

uint8_t is guaranteed to always be an octet, and stdint types (uint8_t, int32_t, uint32_t etc.) are also the recommended types to use when you want to make the size and signedness of the data clear. An array of uint8_t is definitely correct, and it's also the right thing to do in 2018. An array of char is something you should only use to store human-readable character in array form. Many OS network APIs are "char based" because the C standard requires that sizeof char be exactly one byte, so it used to be a convenient shorthand, but that's not the case anymore.

viraptor 8y ago
> the C standard requires that sizeof char be exactly one byte That's at least 1, not exactly 1. It's POSIX that requires char to be 8bit.
- evincarofautumn 8y ago
  It’s “exactly one byte” in the sense that by definition, sizeof(char) = 1, but it’s “at least one byte” in the sense that CHAR_BIT ≥ 8.
- alxlaz 8y ago
  Nope, the C standard requires that sizeof char = 1, regardless of the width of a byte :-).
  - jstimpfle 8y ago
    One of the things I was not sure about is whether the size of uint8_t is guaranteed to be 1 as well. And whether that means the both are pointer-compatible. And if so, where is this specified?
    - alxlaz 8y ago
      As far as I know, C99 makes no requirements about the byte width of int8_t, only about its bit width. The relevant bits are in section 7.18.1.1 . There are few architectures and runtimes where this is relevant anymore, and the answer is really best given on a case-by-case basis. I think it's technically possible to make the two pointer-compatible on architectures with wider bytes. Last time I used one it was Analog Devices' SHARC, and I think they were pointer-compatible, but that was a long time ago, so take it with a grain of salt.
deleted 8y ago
[deleted]

jstimpfle 8y ago

Downvoters, my question was wether int8_t* and char* are interchangeable. I can't see why that's a bad question to ask. Given "char* buf", there might well be a difference between "(uint8_t) buf[1]" and "((uint8_t* )buf)[1]". Now, upon further researching it looks like uint8_t always has size 1 (as does char), but I'm still not positive that the second expression is technically valid.

topspin 8y ago
> my question was whether int8_t* and char* are interchangeable They are not. Not every "C" compiler complies with whatever standard you care to cite. There are DSP platforms[1], for instance, where char is 16 bits. Obviously any hypothetical pointer arithmetic on such a platform must differ between (u)int8_t and char. The intent of (u)int8_t is that such a platform will either a.) correctly implement (u)int_8 and operate on exactly 8 bits as intended or b.) fail to compile. This is demonstrably different than assuming char is 8 bits and yet compiling when it is not. [1] for sale here: https://www.digikey.com/en/product-highlight/t/texas-instruments/c2000 https://www.digikey.com/en/product-highlight/t/texas-instrum...

amluto 8y ago

There's a different consideration: as far as I know, it's an open question whether uint8_t* and int8_t* have the same special aliasing rules that apply to char* and unsigned char. A strict reading suggests that they do not. So there may be cases where using uint8_t is UB but using unsigned char* is not. I think that all compilers consider this to be a bit of defect in the relevant standards, and they'll compile your code the way you expect.