Sizes and SizeInt

[LemonParty]

I have notice that SetLength's Len parameter is declared as SizeInt. Also properties Size and Position of TStream are declared as Int64. Why this things are signed? Isn't a negative length is an absurd?

[LeP]

I think, but I'm certainly wrong, that it's simply for general compatibility.
The vast majority of function arguments have historically been integers, although in many a negative value makes no sense.
However, this avoids the compiler having to perform uint/int conversions.

P.S.: I asked myself the same question, and I continue to ask it, when I have to remove all the warnings and hints from the code; here you can see how much this problem actually exists (I'm talking about Delphi, where the hints and warnings are always more or less zero).

[marcov]

I have notice that SetLength's Len parameter is declared as SizeInt. Also properties Size and Position of TStream are declared as Int64. Why this things are signed? Isn't a negative length is an absurd?

Pascal has a signed type as the base type. The highest unsigned number has some caveats in its use.

[ALLIGATOR]

The highest unsigned number has some caveats in its use.

https://graphitemaster.github.io/aau/
 

[Thaddy]

Memory allocations over UINT64 range are unlikely possible for many IONS, not centuries.
Then again, that might be a Bill Gates' 640k is enough trap.
A signed type makes the calculations safe.

It is still possible to allocate ridiculous amounts of memory, though, even High(Uint64), Just not for the classes and the standard compiler uses. Do you know how much high(Uint64) is? Not feasable, even on super computers. Missing hardware support....?

Answer: 1.8×10¹⁹ bytes, i.e. 16 exabytes. Not possible on any known hardware. 0.0092%, which is actually closer than I thought.... Then again: high (UINT64) is actually 1/12000 of all memory available worldwide.
If you compare High(UInt64) bytes (~16 EB) to the estimated total digital data on Earth (~200 ZB), that’s on the order of 0.01%. So it’s huge for a single process, but still tiny compared to what’s stored globally.

I copiloted the latter to be sure.

So IONS might be wrong, just wait a few years. Then we need a change to OctInt which will keep us happy for many moons...while maintaining integer calculations. 

[LemonParty]

ALLIGATOR, good article.

Thaddy, on 64-bit platforms you probably don't need close to High(UInt64) memory chunks. But what about a 32-bit platform?

Anyway that feel illegal for me that you can pass a negative values to things that represent size.

[ASerge]

Isn't a negative length is an absurd?

What unsigned value for Length -1 when Length = 0?
A frequently used loop "for i :=0 to Some.Length - 1 do" will take a very long time to execute for an unsigned length.

[440bx]

I have notice that SetLength's Len parameter is declared as SizeInt. Also properties Size and Position of TStream are declared as Int64. Why this things are signed? Isn't a negative length is an absurd?

Yes, a negative length is, indeed, absurd.

The real answer to your question is in the very undesirable subtleties involved in expressions that include a mix of the most encompassing unsigned type and the most encompassing signed data type.  Stated in simple terms and, specifically in FPC, the problems the compiler faces when dealing with expressions that involve both, a qword type and an int64 type.  Mixing those two can potentially be quite problematic for the compiler.  The simple solution ? ... most compilers try "encouraging" programmers to "avoid the top unsigned type" in expressions, in the case of FPC, do whatever you can to avoid ending up with expressions that involve a mix of qword and int64. 

That implicit "encouragement" to avoid the mixing of those two types is the reason many types that are naturally unsigned are declared as being the signed int64.  The alternative would have been to have them as DWORD types but, that imposes a limit which, in a 64 bit world, is kind of low, only 4 billion elements out of 2^64 - 1 is actually small.  Making it a qword certainly solves that problem but, opens the door to the qword/int64 type mix the compiler wants to avoid, that leaves the signed int64 as the alternative.  That alternative allows the compiler to support a number of elements that is much larger than 2^32 while not opening the door to creating the problem the compiler wants to avoid.

Neither the compiler writers nor those who document the compiler have any desire to attempt explaining the reason for the "absurd" choice because understanding the real reason requires knowledge that isn't as common as you'd think in the average programmer.  The result is, just make the type a signed type and leave it at that.

Notice how I've also avoided explaining the reason.  I've simply stated that mixing qword and int64 in expressions causes problems for the compiler, which is indeed the real reason but, I've purposely avoided stating why.   if you want to know why, a good A.I model, such as Claude, can give you accurate answers to all of the questions you'll probably have as a result along with a few examples of the problems faced by the compiler in cases where qword and int64 are mixed.  Bottom line: if you want a full detailed explanation, ask AI to give it to you.   Otherwise, the reason is, mixing qword and int64 causes problems most compilers want to _silently_ avoid.

HTH.

[mas steindorff]

<snip>
Anyway that feel illegal for me that you can pass a negative values to things that represent size.

How do you feel about complex numbers?  their imagery elements are a needed part of this world.   
Perhaps negative sizes for allocations are reserved to indicate grabbing the memory from another dimension
imagery run amuck ...

[marcov]

It also depends on how the language handles mixed expressions.  An expression unsigned+signed has 1.5 times the range of either type(min(signed)..max(unsigned)) . Pascal solves that by promoting it to a higher signed type that covers the range, comparisons with languages that don't solve it that way are therefore lopsided.  Similarly Pascal is big on range checking (runtime too)

This is why the highest unsigned type in Pascal is a bit odd. If you accidentally combine it with a signed type, there is no type that can hold the range of the combined expression.

[Martin_fr]

I have notice that SetLength's Len parameter is declared as SizeInt. Also properties Size and Position of TStream are declared as Int64. Why this things are signed? Isn't a negative length is an absurd?

There is a very good example for the "mixed expressions" mentioned...

From memory ...

Code: Pascal  [Select][+][-]

1. var i: cardinal;
2. begin
3. for i := 0 to length(foo)-1 do {};

If "length" was cardinal/qword, and it returned 0 then the expression would overflow to high(cardinal). And the loop would run a long time (or you get a range check error.

I haven't tested, if that changes with the type of "i" or "length" => but in either case you want a signed result for "length(foo)-1". So the loop runs zero times from 0 to -1.

[Thaddy]

Thaddy, on 64-bit platforms you probably don't need close to High(UInt64) memory chunks. But what about a 32-bit platform?

You are still using 32 bit code on Windows Intel/Amd while Microsoft has no support for it?
Think again. Think about what is feasible now. 

[Thaddy]

A frequently used loop "for i :=0 to Some.Length - 1 do" will take a very long time to execute for an unsigned length.

Try these full programs:

Code: Pascal  [Select][+][-]

1. var I: cardinal;
2. begin for i := i-1 to 9 do;end.

Code: Pascal  [Select][+][-]

1. var I: cardinal = 0;
2. begin for i := i-1 to 9 do;end.

[LemonParty]

Mixing singned and unsigned variables is bad.

Uderstood.

[440bx]

Mixing singned and unsigned variables is bad.

Uderstood.

Just to be a bit more precise, in FPC, it's when you mix int64 with qword, that's the problematic part.

As long as the unsigned types don't use more than 32 bits, the compiler will have no problem handling that because it can promote the unsigned types all the way to int64 if necessary to avoid problems, i.e, use the signed superset of the unsigned type.

The moment you have int64 and qword together, the compiler has a problem because it does not have an int128 it can use to promote the qword and keep all the calculation in "signed integer" space.

HTH.