Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How SerenityOS declares ssize_t

awesomekling.github.io

Post reply on HN
Print view View original

71–80 of 95 posts

Re: How SerenityOS declares ssize_t

#71

Post by rkangel »

dan-robertson wrote: post #65
magicalhippo wrote: post #60

Earlier quoted context omitted.

> sizeof(uint16_t) == 1 > This is all completely legal according to the C standard. Is it? I don't have access to the standard, but from secondary sources[1] it seems not? unsigned integer type with width of exactly 8, 16, 32 and 64 bits respectively (provided if and only if the implementation directly supports the type) If it is, it kinda defeats the whole purpose of uint16_t and friends. [1]: https://en.cppreferenc…

It has 16 bits but the units of sizeof are not bytes – they are ‘the minimum difference between two addressable things’ which on that architecture is two bytes.

I can't remember the precise wording in the standard , but sizeof() is effectively "how many of the minimum addressable thing do you need to store this thing".

The "minimum addressable thing" is called a byte, and on XAP that is a 16-bit value.

Storing a uint8_t wastes a 8 bits, because there isn't anything smaller than an int to put it in.

Re: How SerenityOS declares ssize_t

#72

Post by rkangel »

unwind wrote: post #62
rkangel wrote: post #49

Earlier quoted context omitted.

> #elif SIZEOF_SIZE_T == 2 // LOL Fun fact - for a while, this was true for the third most popular processor architecture in the world, one that most people haven't heard of. CSR (the bluetooth chip maker) was originally a spin-out from Cambridge Consultants, and their chips were for years based on a Cambridge Consultants processer design called XAP. As CSR had made billions of devices, XAP was likely right up there…

Cool. So on that platform CHAR_BIT was 16. I still wonder if those statements should use the plain non-typed sizes, or if no such were available. I can live with sizeof(char) == 1 sizeof(short) == 1 sizeof(void *) == 1 all being true with CHAR_BIT equal to 16, but it seems pointless to support uint8_t if it's not truly 8 bits. Too far from my language-lawyer mood now to dig deeper. :)

It turns out you're right, and that's how I've actually written these examples in the past. A sibling comment provided a citation, and that I should really have been writing uint_leastXX_t: https://en.cppreference.com/w/c/types/integer

Re: How SerenityOS declares ssize_t

#73

Post by rkangel »

magicalhippo wrote: post #60
rkangel wrote: post #49

Earlier quoted context omitted.

> #elif SIZEOF_SIZE_T == 2 // LOL Fun fact - for a while, this was true for the third most popular processor architecture in the world, one that most people haven't heard of. CSR (the bluetooth chip maker) was originally a spin-out from Cambridge Consultants, and their chips were for years based on a Cambridge Consultants processer design called XAP. As CSR had made billions of devices, XAP was likely right up there…

> sizeof(uint16_t) == 1 > This is all completely legal according to the C standard. Is it? I don't have access to the standard, but from secondary sources[1] it seems not? unsigned integer type with width of exactly 8, 16, 32 and 64 bits respectively (provided if and only if the implementation directly supports the type) If it is, it kinda defeats the whole purpose of uint16_t and friends. [1]: https://en.cppreferenc…

That's interesting. I didn't actually know the definition of uintXX_t. I was actually doing this with C90 most of the time, and using types we had defined (rather than from stdint.h). Sounds like they were more equivalent to int_leastXX_t.

I realise know when I've previously written the above examples I've done it was basic types, so sizeof(char), sizeof(int) etc.. Sounds like it would be more correct as well!

Re: How SerenityOS declares ssize_t

#75

Post by magicalhippo »

dan-robertson wrote: post #65
magicalhippo wrote: post #60

Earlier quoted context omitted.

> sizeof(uint16_t) == 1 > This is all completely legal according to the C standard. Is it? I don't have access to the standard, but from secondary sources[1] it seems not? unsigned integer type with width of exactly 8, 16, 32 and 64 bits respectively (provided if and only if the implementation directly supports the type) If it is, it kinda defeats the whole purpose of uint16_t and friends. [1]: https://en.cppreferenc…

It has 16 bits but the units of sizeof are not bytes – they are ‘the minimum difference between two addressable things’ which on that architecture is two bytes.

Right, I was assuming the bytes were 8 bits[1] given sizeof(uint8_t) == 1, ie since it had uint8_t. Seems really weird to have uint8_t but have CHAR_BIT > 8.

[1]: https://en.cppreference.com/w/c/language/sizeof

Re: How SerenityOS declares ssize_t

#76

Post by magicalhippo »

rkangel wrote: post #73
magicalhippo wrote: post #60

Earlier quoted context omitted.

> sizeof(uint16_t) == 1 > This is all completely legal according to the C standard. Is it? I don't have access to the standard, but from secondary sources[1] it seems not? unsigned integer type with width of exactly 8, 16, 32 and 64 bits respectively (provided if and only if the implementation directly supports the type) If it is, it kinda defeats the whole purpose of uint16_t and friends. [1]: https://en.cppreferenc…

That's interesting. I didn't actually know the definition of uintXX_t. I was actually doing this with C90 most of the time, and using types we had defined (rather than from stdint.h). Sounds like they were more equivalent to int_leastXX_t. I realise know when I've previously written the above examples I've done it was basic types, so sizeof(char), sizeof(int) etc.. Sounds like it would be more correct as well!

Ah yes, having char and short etc be the same size makes a lot more sense, while still being a massive trap for young players.

Re: How SerenityOS declares ssize_t

#77

Post by actionfromafar »

tjoff wrote: post #68
dan-robertson wrote: post #65

Earlier quoted context omitted.

It has 16 bits but the units of sizeof are not bytes – they are ‘the minimum difference between two addressable things’ which on that architecture is two bytes.

Isn't that a byte? So rather, a byte is 16 bits.

Sure. A byte is two octets. In cases like these it pays to be very precise.

Re: How SerenityOS declares ssize_t

#78

Post by [deleted] »

fanf2 wrote: post #64
st_goliath wrote: post #9

Earlier quoted context omitted.

To expand further on that: POSIX only says that ssize_t needs to be able to store -1, i.e. the valid range is from -1 through 0 to some implementation defined maximum. (See the link in the article) A really cursed implementation could hack up compiler support for an asymmetric integer type that treats all-bits-set as -1 and everything else as a positive number, allowing ssize_t to hold all but the largest size_t valu…

That isn’t allowed by the C standard: signed integer types have to be two’s complement, one’s complement, or sign-magnitude; they can’t be wildly asymmetrical about 0.

[deleted]

Re: How SerenityOS declares ssize_t

#80

Post by SAI_Peregrinus »

Dylan16807 wrote: post #33
addaon wrote: post #17

Earlier quoted context omitted.

I mean, a C spec compatible compiler for the MSP430 would be an example (see paragraph 7.20.3), TI has just decided to deviate from the language standard here. It's an example of a platform that would meet the requirements, and chooses to not offer a (compliant) C compiler instead.

I don't understand how it's an example. It sounds like ssize_t and ptrdiff_t need the same number of bits on this architecture. And if ptrdiff_t is wrong, they'd probably make ssize_t wrong too. Also I don't think "we need more distinct constants because then if a compiler author deliberately makes one wrong they might leave the other one alone" is enough justification to have two.

ssize_t isn't standard C. It's just POSIX, which uses undefined behavior of the C standard to create an almost but not quite C language used on all Unix systems. POSIX C is not strictly conforming C, but it is conforming C. The same goes for GNU C, Visual C, etc.
Post reply on HN