How SerenityOS declares ssize_t
awesomekling.github.io
How SerenityOS declares ssize_t
1–10 of 95 posts
Re: How SerenityOS declares ssize_t
#2That's cursed just the way I like it.
Re: How SerenityOS declares ssize_t
#3This seems to be about defining it, not merely declaring it. ("typedef" is short for "type definition", for example.)
Re: How SerenityOS declares ssize_t
#4Is there any real-world system on which defining ssize_t to be ptrdiff_t would break actual programs that exist? (i.e. I'm not asking for hypotheticals here)
Re: How SerenityOS declares ssize_t
#5I 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".
Re: How SerenityOS declares ssize_t
#6Is there any real-world system on which defining ssize_t to be ptrdiff_t would break actual programs that exist? (i.e. I'm not asking for hypotheticals here)
Yes -- anything that uses fat pointers and defines ptrdiff_t to be a fat pointer type that is larger than size_t/ssize_t.
Re: How SerenityOS declares ssize_t
#7Is there any real-world system on which defining ssize_t to be ptrdiff_t would break actual programs that exist? (i.e. I'm not asking for hypotheticals here)
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?
Re: How SerenityOS declares ssize_t
#8> I don’t recommend doing this in your codebase, but it has worked for us so far. :^)
The story of my life . . .
Re: How SerenityOS declares ssize_t
#9That'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 values. While perfectly standards compliant, I guess this might break a bunch of implicit assumptions across various existing programs.
Re: How SerenityOS declares ssize_t
#10I 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".
I find it neat that the code doesn't have to enumerate all the possible platforms it might be compiled on, and instead just takes something the compiler already provides and tweaks it.
But yes, the "cute" "hack" aspect is the primary endearing factor :^)