I fail to see how their overly clever solution is in any shape or form better than the regular approach shown under "How others declare them" – except for being a "cute" "hack".
[deleted]
How SerenityOS declares ssize_t
11–20 of 95 posts
Re: How SerenityOS declares ssize_t
#12I fail to see how their overly clever solution is in any shape or form better than the regular approach shown under "How others declare them" – except for being a "cute" "hack".
My thoughts exactly. What if __SIZE_TYPE__ stops being a macro someday? Also double-underscore prefixed symbols are compiler reserved, so any other compiler can use the same symbol for entirely different purpose, so compiler guards are needed when using it.
I understand doing hacks when there's no other way around something, or when a hack is much cheaper than the proper solution, but in this case, I think those guys have chosen a more complicated, more expensive, less functional hack than a cheap and more complete proper solution (in "how others are doing it").
Re: How SerenityOS declares ssize_t
#13Earlier quoted context omitted.
Yes -- anything that uses fat pointers and defines ptrdiff_t to be a fat pointer type that is larger than size_t/ssize_t.
What actual system is currently like this?
I'm sure they're out there. The closest that comes to mind is the MSP430, but not quite -- although it has 20 bit pointers (with sizeof ptr being... 4, since they're padded to 4 bytes for storage) and has a 16 bit size_t, my recollection is that ptrdiff_t is also defined at 16 bits (which I think violates the C spec, which requires at least 17 bits?). I haven't worked with many other segmented architectures recently, but either there or capability machines are where I'd look.
Re: How SerenityOS declares ssize_t
#14I fail to see how their overly clever solution is in any shape or form better than the regular approach shown under "How others declare them" – except for being a "cute" "hack".
well, obviously the advantage is that you don't have to enumerate all the architectures you support manually. Is it worth it? Ehhh, probably not, but the author isn't exactly advocating for it either
Re: How SerenityOS declares ssize_t
#15I fail to see how their overly clever solution is in any shape or form better than the regular approach shown under "How others declare them" – except for being a "cute" "hack".
Well, he sorta says it at the end:
>Other C libraries typically use more careful techniques, such as wrapping the declarations in architecture-specific #ifdefs
They don't have to define it multiple times for different architectures. This is theoretically platform agnostic and saves a few lines. Not really that significant, but then again it's not like he's recommending people do it.
Re: How SerenityOS declares ssize_t
#16Earlier quoted context omitted.
What actual system is currently like this?
I'm sure they're out there. The closest that comes to mind is the MSP430, but not quite -- although it has 20 bit pointers (with sizeof ptr being... 4, since they're padded to 4 bytes for storage) and has a 16 bit size_t, my recollection is that ptrdiff_t is also defined at 16 bits (which I think violates the C spec, which requires at least 17 bits?). I haven't worked with many other segmented architectures recently,…
The entire purpose of my question was that "I'm sure they're out there" is as close as I've ever found an answer to this, so I was looking for an actual example, not a hypothetical one.
Re: How SerenityOS declares ssize_t
#17Earlier quoted context omitted.
I'm sure they're out there. The closest that comes to mind is the MSP430, but not quite -- although it has 20 bit pointers (with sizeof ptr being... 4, since they're padded to 4 bytes for storage) and has a 16 bit size_t, my recollection is that ptrdiff_t is also defined at 16 bits (which I think violates the C spec, which requires at least 17 bits?). I haven't worked with many other segmented architectures recently,…
The entire purpose of my question was that "I'm sure they're out there" is as close as I've ever found an answer to this, so I was looking for an actual example, not a hypothetical one.
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.
Re: How SerenityOS declares ssize_t
#18Earlier quoted context omitted.
The entire purpose of my question was that "I'm sure they're out there" is as close as I've ever found an answer to this, so I was looking for an actual example, not a hypothetical one.
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.
But that's not a counterargument; if anything, it's kind of my point. The standard seems to be catering to a hypothetical machine that seems to lack real-world demand/usage/market/utility/etc.
If an abstraction is placed into a standard, its answer to "how many people are benefiting from this headache we're giving everybody" really ought to be noticeably greater than zero.
Re: How SerenityOS declares ssize_t
#19That's cursed just the way I like it.
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…
This isn’t particularly uncommon or without precedent. This is just treating SIZE_MAX as the sentinel value of an otherwise unsigned type. This is what is done for std::dynamic_extent in C++ for instance.
Re: How SerenityOS declares ssize_t
#20isn't magical development where you do things just because it "works for me" building technical debt?