introduce csize_t instead of fixing csize

[krux02]

Implement the proposal by @Araq in #12447 (comment)_

It is actually harder to maintain backwards compatibility with this change instead of #12321. Explicit conversions like csize(x) or cast[csize](x) would work no matter if csize is defined as int or uint. The new type csize_t and deprecating csize forces user of csize into one of these options:

• Ignore deprecation warnings
• Drop support for Nim versions that don't provide csize_t
• Copy the definition of csize_t into the project with some when declared condition.
• Avoid using csize/csize_t all together and use int/uint directly.

This still does break backwards compatibility, since I did change functions that return csize to return csize_t now. The alternative would be to introduce new names, for example: proc c_strlen*(a: cstring): csize and proc c_strlen2*(a: cstring): csize_t. I also didn't introduce a new type Glob2 next to Glob where the members gl_pathc and gl_offs stay cint, because then I would also need to duplicate posix.glob and posix.globfree. This basically means that every module that uses csize anywhere in the exposed symbols needs to duplicate those symbols now with another version that uses csize_t instead of csize to fix the deprecationd and also stay backwards compatible.

The alternative is to remerge #12321, but with a switch that allows csize to stay the old way.

[Araq]

This still does break backwards compatibility, since I did change functions that return csize to return csize_t now.

Yeah but the idea was not to break code. I personally would replace csize with int everywhere it comes up. No code breakage, fixes C's mistake of using wrap around arithmetic for sizes. Yeah, yeah, yeah in some alternative universe where you use 4GB sized buffers on a 32 bit system (how can you you do that? who knows) it will be "wrong" but then so is the wrap-around arithmetic.

[krux02]

Yeah, yeah, yeah in some alternative universe where you use 4GB sized buffers on a 32 bit system (how can you you do that? who knows) it will be "wrong" but then so is the wrap-around arithmetic.

Can you please stop bringing this up again and again. The c++ committee even agreen on this, happy about that? But that is totally not the point here. The issue here that I try to solve is csize type definition in Nim is an incorrect type definiton that causes incorrect behavior in Nim. I don't know what all can go wrong, but here is something that certainly goes wrong.

I personally would replace csize with int everywhere it comes up.

Does that mean that you will do it? Or is that your review advice for this PR?

[Araq]

After a long discussion, here is what we agreed on:

The changes to ansi_c.nim are too much, not required becaues it's an internal API.

[mrgaturus]

Is a bit weird how you want avoid a direct usage of unsigned types, another example is the Natural type, has a range from 0 to the maximum positive of a int instead using an unsigned int for that

[Araq]

Maybe it's because I know the semantic implications.

[ringabout]

csize_t is unsigned type and it should be named as cusize_t to be consistent with cint and cuint.
Because there is also ssize_t in c which is a signed type.

[krux02]

@xflywind the names are directly from C. And in C the type definition is called size_t and not unsigned size_t. Therefore the name is correct. Regarding ssize_t. I was thinking about exporting that one as well, but sadly, that type definiton is not ANSI C, it is POSIX and therefore not something to generally available in a C environment.

https://stackoverflow.com/questions/55190317/where-is-ssize-t-defined-in-linux

[ringabout]

@krux02
I see. Thanks!