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

61–70 of 95 posts

Re: How SerenityOS declares ssize_t

#61

Post by rkangel »

mid-kid wrote: post #59
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…

It's also 16 bit for the AVR architecture used on Arduino devices.

Is it? Cool! I haven't done anything with an Arduino for a while, and only used larger AVRs.

Re: How SerenityOS declares ssize_t

#62

Post by unwind »

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…

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. :)

Re: How SerenityOS declares ssize_t

#63

Post by pjmlp »

williamvds wrote: post #47
nine_k wrote: post #31

This is a great illustration why C is, on one hand, terrible, and, on the other hand, staunchly practical. Here the trivial, unthinking preprocessor allows to do a pretty crazy (though very understandable and predictable) thing, which allows to acceptably solve a problem which would take years and a ton of effort to be solved "properly" (with standardization and compiler support).

I agree on the practicality aspect. When programmimg in C, one learns to accept these preprocessor hacks. When programming in C++, where limited compile and type metaprogramming exists, one is constantly hitting the limits and it causes endless frustration. I go through a mini cycle of grief until I give in and use a macro, or an otherwise less elegant implementation. You're right in that it has taken years (decades,…

Most likely people would be using awk and sed for the same purposes.

Re: How SerenityOS declares ssize_t

#64

Post by fanf2 »

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…

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.

Re: How SerenityOS declares ssize_t

#65

Post by dan-robertson »

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…

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.

Re: How SerenityOS declares ssize_t

#66

Post by defrost »

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…

> On every modern processor design I know of, that is an 8 bit quantity,

Serious throughput DSP chips don't sully themselves with a mere 8 bits, they're designed to do 32 bit and more FFT pipelines that modular index multiple vectors, fetch, multiply, add, and store every clock cycle.

Eg: the Texas Instruments TMS320C54x has CHAR_BIT 16 ( Table 7-1 page 192 [1] )

Other modern DSP family chips have CHAR_BIT 32 .. they're for numerics not ASCII text processing.

[1] https://www.ti.com.cn/cn/lit/ug/spru103g/spru103g.pdf

Re: How SerenityOS declares ssize_t

#67

Post by roger10-4 »

williamvds wrote: post #47
nine_k wrote: post #31

This is a great illustration why C is, on one hand, terrible, and, on the other hand, staunchly practical. Here the trivial, unthinking preprocessor allows to do a pretty crazy (though very understandable and predictable) thing, which allows to acceptably solve a problem which would take years and a ton of effort to be solved "properly" (with standardization and compiler support).

I agree on the practicality aspect. When programmimg in C, one learns to accept these preprocessor hacks. When programming in C++, where limited compile and type metaprogramming exists, one is constantly hitting the limits and it causes endless frustration. I go through a mini cycle of grief until I give in and use a macro, or an otherwise less elegant implementation. You're right in that it has taken years (decades,…

I wouldn’t call meta- and compile-time programming limited in modern C++ (C++17 and above).

With the addition of “constexpr” and “consteval” compile time programming is the same as runtime for many cases. Templates are obtuse for meta programming but usually can get the job done.

The need for macros much less common in modern code.

Re: How SerenityOS declares ssize_t

#68

Post by tjoff »

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.

Isn't that a byte?

So rather, a byte is 16 bits.

Re: How SerenityOS declares ssize_t

#70

Post by williamvds »

roger10-4 wrote: post #67
williamvds wrote: post #47

Earlier quoted context omitted.

I agree on the practicality aspect. When programmimg in C, one learns to accept these preprocessor hacks. When programming in C++, where limited compile and type metaprogramming exists, one is constantly hitting the limits and it causes endless frustration. I go through a mini cycle of grief until I give in and use a macro, or an otherwise less elegant implementation. You're right in that it has taken years (decades,…

I wouldn’t call meta- and compile-time programming limited in modern C++ (C++17 and above). With the addition of “constexpr” and “consteval” compile time programming is the same as runtime for many cases. Templates are obtuse for meta programming but usually can get the job done. The need for macros much less common in modern code.

You can mostly avoid macros now, thankfully. I'm particularly thinking of things like compile-time reflection, some more complex type introspection. Things that would let you get rid of some code generation like D's mixins perhaps.

Existing c++ reflection has mostly been done with macros, which you sacrifice readability for by declaring your class with macros instead, and I believe is often a runtime thing anyway. Complex type metaprogramming is possible, sure, but often so obtuse and illegible I'd dare say the preprocessor is a better alternative if it works.

Post reply on HN