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

91–95 of 95 posts

Re: How SerenityOS declares ssize_t

#91

Post by Dylan16807 »

addaon wrote: post #90
jabl wrote: post #55

Earlier quoted context omitted.

C23 follows C++ in requiring signed integers to have two's complement representation. I think by this point it's pretty much settled that it's the "optimal" way to implement signed integers. Now if we change to non-binary architectures (or something radically different) things might change, but at that point quite a lot of the C standard will have to be thrown out as well.

I /mostly/ agree -- it's hard for me to think of a modern or future platform that would use ones complement integers... with one possible exception. Integers represented on top of IEEE floating point are inherently ones-complement (sign+magnitude), and I can definitely imagine potential future platforms that use 64-bit floats as their primary primitive, restricting them to integer representations for certain tasks. T…

I know I'm being picky but sign+magnitude and ones's complement are a good bit different from each other despite both having negative zero.

Re: How SerenityOS declares ssize_t

#92

Post by MathMonkeyMan »

kevin_thibedeau wrote: post #30
MathMonkeyMan wrote: post #28

Earlier quoted context omitted.

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.

I was referring to __SIZE_TYPE__, but that isn't in the standard either. Whoops.

Re: How SerenityOS declares ssize_t

#93

Post by tredre3 »

0xfedbee wrote: post #53
Cthulhu_ wrote: post #41

I'm not a C developer at all, but this looks like bragging about a clever trick; when it comes to these things (and most code for that matter), I'd avoid clever tricks like the plague. Just write it out logically and as simple as possible. You're not saving much time / effort by writing out, and clear is better than clever. Code size is never an issue.

You’d understand it if you were a C developer.

> You’d understand it if you were a C developer.

Counterpoint: I'm a C developer and a big fan of Andreas and I prefer mildly clever code over longer explicit code. But even then I was still surprised by his choice to keep this specific hack. It feels very brittle to me.

Re: How SerenityOS declares ssize_t

#95

Post by kazinator »

rkangel wrote: post #49
kazinator wrote: post #25

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?…

> #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…

I have worked with such things myself; for instance most recently, at, Broadcom I had worked on ARM-based VoIP phones which had a Ceva Teaklite DSP, which has 16 bit bytes (and memory access with weird byte order that is neither big nor little endian).

If we had to be a bit more portable to include such systems, we could test on bit instead of byte sizes, e.g.

  #if SIZEOF_SIZE_T * CHAR_BIT == 16
Post reply on HN