I always wondered why I get a compiler message for the following code snipped:

----------------------------------------------------------------------------
function Match(M,F : UTF8String) : boolean;
var i : Cardinal;

...

if i+length(M)<length(F) then
...

----------------------------------------------------------------------------

For the last code line I get:

unit1.pas(1097,14) Hint: Mixing signed expressions and longwords gives a 64bit result

But where are signed expressions involved?
i is Cardinal (so it cannot be negative) and
the two length-statements can also never be negative. There is no substraction so why this message?
Anybody knows?

Length is declared in the compiler/RTL to return an integer result.

Howard

Realy?
But why that?
It cannot be negative.
Using integer instead of unsigned values reduces the possible (positive) range and produces such illogical (to me) compiler warnings.

Jürgen Hestermann wrote

Delphi compatibility and maximum data size limitation AFAIK (2 GB).

Sigh... all the bad things in FPC crept in from Delphi it seems...

Why did they artifically limit the max number of array elements to 2^31when it would have been very easy to have a maximum of 2^32 instead?

... which is not true in this case.
- The unsigned types are something very unpascalish.
- Extended Pascal defines the result of length as integer
- Expressions like length(s)-1 are very common and would cause a lot of trouble if length(s) would be unsigned.

Why did they artifically limit the max number of array elements to 2^31when it would have been very easy to have a maximum of 2^32 instead?

It is even easier to use a 64 bit OS in this case. Even more having a data segment >2 GB might be a problem for 32 Bit OSes.

You have to think back at that time. 64-bit was in the far future, on Windows you only had 2 GB RAM available to user mode (the 3GB switch was added with XP AFAIK). So you *could not* allocate more than 2 GB of RAM even if you wanted to. And you couldn't even reach that, because you still have other memory in use by the RTL.

The rest is history...

Regards,
Sven

it goes back much further than that... IIRC, Turbo Pascal was the first to introduce the string type... i don't remember if it was in TP1 or TP2... i do know if it was in TP3 because i was using them in my code then...

Why did they artifically limit the max number of array elements to 2^31when it would have been very easy to have a maximum of 2^32 instead?

64k stack limitation is the first thing that comes to mind...

the string type is/was a 256 character array with the 0th (zero-th) element containing the length of the string... this allowed one to immediately know how many characters to read at once... it was much faster than iterating thru the array looking for a nul byte as done in other languages...

it was quite innovative at the time and actually lead to the Hudson Message Base format being developed by Adam Hudson of QuickBBS fame when he was in high school (grades 10-12)... this message base format was the greatest thing since sliced bread when it came out and many other BBS packages adopted it because of its amazing speed and the large number of messages that could be stored with it...

255 maximum areas
32k total messages
16M maximum size of message data file

in the days of 10M and new 20M hard drives, this was huge and message oriented BBSes sprung up all over the world along with evolving message oriented store and forward packet networks like fidonet, WWIVNet, RIME/PCRelay and others...

all because of the string type ;)

2014/1/22 waldo kitty

What was innovative? Storing the length as byte 0? I believe old Basic had been doing it for years before. Basic is not a language I like, but still...

the type, itself... it did not exist previously and if there was anything like it, it was written specially by coders needing... this is likely how it came to be included, too... i simply do not recall since that was what? some 35+ years ago?

Storing the length as byte 0? I believe old Basic had been doing it for years before. Basic is not a language I like, but still...

i don't know how BASIC (which BASIC??) did it... each implementation, like the various pascals, could do things their own way behind the scenes as long as the results were the same... witness FPC with what it does to achieve the same results as other pascal languages ;)

as for not liking BASIC, when i found TP and actually learned ASM, i left BASIC in the dust and never looked back... when i had to start writing dBase II code, it was like a huge step backwards to BASIC for me... i tended to write my dBase II code like i did my pascal code... going as low level as i could... oh well... that was then and dBase is not even around any more AFAIK...

Florian Klämpfl wrote

- The unsigned types are something very unpascalish.

Maybe. I started with UCSD-Pascal but I do not remember whether it already had unsigned integer types. I just searched for its Length result type on the net and found that it was integer too.

- Expressions like length(s)-1 are very common and would cause a lot of trouble if length(s) would be unsigned.

That's true.
But this only causes problems on zero-based arrays (strings are one-based and don't have this problem).

It is even easier to use a 64 bit OS in this case. Even more having a data segment >2 GB might be a problem for 32 Bit OSes.

True again. Thought it seems to bother others too: http://stackoverflow.com/questions/12781434/why-do-delphi-and-free-pascal-usually-prefer-a-signed-integer-data-type-to-unsig But on this link some other reasons for signed integers are given..