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

21–30 of 95 posts

Re: How SerenityOS declares ssize_t

#21

Post by addaon »

dataflow wrote: post #18
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.

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.

Sure. The C standard has always erred on the side of supporting odd platforms -- see ones complement, decimal floating point, sizeof function pointer != sizeof data pointer, etc. Most platforms today have converged around an approach that doesn't require these escape hatches. But if you're trying to e.g. bring up C on CHERI [1] or other platforms that don't make the assumption that memory is all one big flat address space, it's not only nice to have flexibility in the standard, it's nice that LLVM and other tools maintain that flexibility into their implementation.

[1] https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf

Re: How SerenityOS declares ssize_t

#22

Post by riceart »

NoZebra120vClip wrote: post #3

This seems to be about defining it, not merely declaring it. ("typedef" is short for "type definition", for example.)

Definition and declaration have specific meanings in C and C++. A typedef is part of a declaration.

Declarations can be definitions but a typedef is not a definition in particular. https://en.cppreference.com/w/c/language/typedef

Re: How SerenityOS declares ssize_t

#23

Post by denysvitali »

Unrelated to the article per se, but relevant about the author: I really admire Andreas positivity and his ability to spread such joy to the audience.

This guy is awesome, and his positivity is outstanding. Just watch a few of his YouTube videos and you'll understand what I mean (:

Re: How SerenityOS declares ssize_t

#25

Post by kazinator »

I would do it like this:

  #if SIZEOF_SIZE_T == 8
  typedef int64_t ssize_t
  #elif SIZEOF_SIZE_T == 4
  typedef int32_t ssize_t
  #elif SIZEOF_SIZE_T == 2 // LOL
  typedef int16_t ssize_t
  #else
  #error port me!
  #endif
SIZEOF_SIZE_T can be obtained using a script which compiles a test program without executing it.

Over they years I used more than one approach, settling on this one:

https://www.kylheku.com/cgit/txr/tree/configure?id=1f902ca63...

Here, in the test program, a DEC macro has been defined which given a constant expression, produces two decimal digits as the initializer for a two-character array. For instance:

   DEC(42) -> { '4', '2' }  // not exactly: character constants are not used
With this trick we can use DEC(sizeof (size_t)) to get a value like { ' ', '8' } into the portion of some character data, which we can prefix with an identifying string we can look for, like:

   SIZEOF_SIZE_T= 8
That we can basically grep out. In my configure script, this data is extracted, spaces are removed from it, and it's evaluated directly as shell assignments, so then the values are available in shell variables.

Re: How SerenityOS declares ssize_t

#26

Post by dataflow »

addaon wrote: post #21
dataflow wrote: post #18

Earlier quoted context omitted.

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.

Sure. The C standard has always erred on the side of supporting odd platforms -- see ones complement, decimal floating point, sizeof function pointer != sizeof data pointer, etc. Most platforms today have converged around an approach that doesn't require these escape hatches. But if you're trying to e.g. bring up C on CHERI [1] or other platforms that don't make the assumption that memory is all one big flat address…

> see ones complement

I'm glad you brought this up because is kind of my point. C++ realized this was useless baggage and finally left it behind. [1] I don't see why ptrdiff_t is much different here. C just doesn't want to let things to, I guess. Literally any feature you put into a language will end up being used (or abused) by someone for something. "It's nice" that at some point in the future someone can pick up any random shiny thing once in a while and twirl it around doesn't seem like a reason to keep it into the standard for decades and burden everyone else with it the whole time. (Not to mention there are much nicer things that C and C++ lack, and that would make people's lives easier rather than harder...)

[1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p09...

Re: How SerenityOS declares ssize_t

#27

Post by im3w1l »

st_goliath wrote: post #9
qalmakka wrote: post #2

That'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…

There's a really neat way to express asymmetric numbers that generalizes from both unsigned numbers and standard 2's complement signed numbers.

It's easiest to explain in terms of how to interpret a particular bitpattern. As the first step, interpret the bitpattern as an unsigned int, u.

If u u. If u > T, then we interpret it as the negative number u - UINT_MAX.

T = UINT_MAX gives you the unsigned numbers, and T = INT_MAX gives you the two's complement.

Because of modulus intense handwaving it's also easy to do addition, subtraction and multiplication using this representation.

Re: How SerenityOS declares ssize_t

#28

Post by MathMonkeyMan »

makach wrote: post #20

isn't magical development where you do things just because it "works for me" building technical debt?

The C standard macro must expand to _something_. My concern would be that it expands to something like __builtin_foo_nugget instead of unsigned long...

Re: How SerenityOS declares ssize_t

#29

Post by doctor_eval »

makach wrote: post #20

isn't magical development where you do things just because it "works for me" building technical debt?

It's definitely not technical debt. The worst that can happen is that you have to go back and do it the "proper" per-arch way at some point. It's just a neat hack.

Re: How SerenityOS declares ssize_t

#30

Post by kevin_thibedeau »

MathMonkeyMan wrote: post #28
makach wrote: post #20

isn't magical development where you do things just because it "works for me" building technical debt?

The C standard macro must expand to _something_. My concern would be that it expands to something like __builtin_foo_nugget instead of unsigned long...

ssize_t isn't in the C standard. The closest substitute is ptrdiff_t.
Post reply on HN