C over the years

Does anyone know why did the definitions of many functions in the C standard library got changed to return ssize_t instead of int? For instance read and write, both returning -1 in case of error, whilst all declarations of ssize_t I've seen are unsigned. What is this crazyness?

read(2) and write(2) were never in the C standard library; those niggas been rollin' POSIX since it got borned.

>>2
Yes I'm sorry I didn't mean the standard library; they are identified as important system calls in the ANSI standard, how is a thing like that changed with an unsigned return type??!

>>3
Where I'm sitting, ssize_t is defined in terms of __SWORD_TYPE, which is int for 32-bit and long int for 64-bit platforms. So it's signed; materially the only change from returning int is that there may be large return values on 64-bit plats. This is reasonable because the size parameter can also be large on 64-bit.

>>4
How can DA STANDARD enumerate sword types when C doesn't have any support for symbolic programming?

>>5
Dude, my katana can cut through all your symbols.

>>3

they are identified as important system calls in the ANSI standard

What?

how is a thing like that changed with an unsigned return type??!

I have never seen a implementation where ssize_t is a unsigned.

Personally I never understood what is the point of ssize_t if SSIZE_MAX is less than SIZE_MAX (line in the most systems).

>>7
I think >>1 could actually be super-dyslexic. Unless she copy-pasted all mentions of ssize_t, it means that she somehow managed to write it correctly despite reading it incorrectly. As if her mind exists in the mind of another being, or maybe contains another parasitic mind with root access, that filters certain aspects of reality from her while still ensuring perfect roundtripping.

>>1,7-8
ssize_t literally stands for "signed size type".

I suspect the lack of any requirement that it be able to represent any value that can be represented by a size_t is a historical artifact. In the beginning, there was no ssize_t, everyone just used long instead. Hence, any functions that were subsequently redefined to use ssize_t have to use a type that is compatible with long, to avoid breaking existing applications. Since the POSIX standard also has no requirement that a long be able to represent all values that can be represented with a size_t, the standard is stuck at this impasse forever.

>>9

everyone just used long instead

everyone just used int instead

Hence, any functions that were subsequently redefined to use ssize_t have to use a type that is compatible with long

ssize_t is 32 bits in 32 bit linux, unlike long if I am not mistaken.

>>10
You are mistaken. Historically, Unix used long for the return values of read and write, not int.

long on Linux i386 is 32 bits, not 64 bits. If you want a 64 bit signed type on i386, you must use long long.

>>11
Nice dubs dubs

>>11
You are right, I am mistaken. I was confused with windows where even at x86-64 long is still 32 bit.

>>13
On linux every target architecture with 64bit addresses have long and long long the same size, 64 bits. Anyways you have fixed length integer types in the C99 standard, the same standard that introduced long longs.

>>14
I was aware of that.

>>15
But were you aware of this?
*unzips dick*

>>16
Why do you have a zipper on your dick?

>>16
I hope it was LZMA encoded.

>>17
Oh god I'm laughing so hard at this. I should probably kill myself right now.

>>19
XML makes Java the "acceptable lisp"

>>21
*unzips vagina*

>>22
*checks dubs*

Zipping dicks considered harmful

*quickly zips up anus*

ZIP MY ANUS