bug 3626 is marked as "Not a bug". This is wrong! The comment is also wrong!
-
BR.
Mailing lists / fpc-devel / 2005-02
bug 3626
10 messages · 7 people · –
- Unknown author 4
- Florian Klaempfl 1
- Jonas Maebe 1
- Konstantin Münning 1
- peter green 1
- Peter Vreman 1
- +1 more
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
bug 3626 is marked as "Not a bug". This is wrong! The comment is also wrong!
Why? 90000000000000000 is a valid int64...
Vincent.
int64 integer ???
Vincent Snijders wrote 15 lines
wrote:
> bug 3626 is marked as "Not a bug". This is wrong! The comment is also
> wrong!
Why? 90000000000000000 is a valid int64...
Vincent.
_______________________________________________
fpc-devel maillist -
http://lists.freepascal.org/mailman/listinfo/fpc-devel
int64 integer ???
The compiler reports a range check error depending on $R as warning or error. So where is the problem? What do you expect to happen?
Show quoted text 23 lines
Vincent Snijders wrote:
> wrote:
>
>> bug 3626 is marked as "Not a bug". This is wrong! The comment is also
>> wrong!
>
>
>
> Why? 90000000000000000 is a valid int64...
>
> Vincent.
>
> _______________________________________________
> fpc-devel maillist -
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
>
_______________________________________________
fpc-devel maillist -
http://lists.freepascal.org/mailman/listinfo/fpc-devel
int64 integer ???
int64 integer ???
They are assignment-compatible. If the value doesn't fit in the range of the destination type, you get either a warning (if range checking is off) or an error (if range checking is on).
Jonas
The compiler reports a range check error depending on $R as warning or error. So where is…
I expect a "out of bounds error" messeage. Independent from $R.
Florian Klaempfl wrote 40 lines
wrote:
> int64 integer ???
The compiler reports a range check error depending on $R as warning or
error. So where is the problem? What do you expect to happen?
>
> Vincent Snijders wrote:
>
>> wrote:
>>
>>> bug 3626 is marked as "Not a bug". This is wrong! The comment is
>>> also wrong!
>>
>>
>>
>>
>> Why? 90000000000000000 is a valid int64...
>>
>> Vincent.
>>
>> _______________________________________________
>> fpc-devel maillist -
>> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>>
>>
>
> _______________________________________________
> fpc-devel maillist -
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist -
http://lists.freepascal.org/mailman/listinfo/fpc-devel
The compiler reports a range check error depending on $R as warning or error. So where is…
Show quoted text 6 lines
wrote:
> int64 integer ???
The compiler reports a range check error depending on $R as
warning or error. So
where is the problem? What do you expect to happen?
im not going to argue whether this is right or wrong but in delphi at least $R only affects run time range checking. In delphi that code will give an error (constant expression violates subrange bounds) even with range checking off.
Show quoted text 7 lines
wrote:
>int64 integer ???
The compiler reports a range check error depending on $R as
warning or error. So
where is the problem? What do you expect to happen?
If I got it right the question is about a comparison statement of two integer numbers. IMHO from the logocal view this should not produce a compiler error or a runtime error as you can compare any two numbers even if the underlying data types are not the same. Logically it's OK to check if 600000000000000 3. So the production of range check errors (runtime or compiletime) is IMHO logically wrong. Warnings are OK as it may be an unintentional error but if the compiler compiles
int64 integer
as
int64temp := integer;
int64 int64tempit would be just the intended behaviuor in any 'normal' situation I can imagine.
Have a nice day,
Konstantin Münning ,,,
-------------------------------/'^'\------------------------------------
www.muenning.com ( o o )
--------------------------oOOO--(_)--OOOo-------------------------------
Beware of Programmers who carry screwdrivers.
-- Leonard Brandwein
(-O-)
The man who follows the crowd will usually get no further than the crowd.
The man who walks alone is likely to find himself in places no one has
ever been. -- Alan Ashley-Pitt
im not going to argue whether this is right or wrong but in delphi at least $R only…
can agree.
peter green wrote 12 lines
im not going to argue whether this is right or wrong but in delphi at least
$R only affects run time range checking. In delphi that code will give an
error (constant expression violates subrange bounds) even with range
checking off.
_______________________________________________
fpc-devel maillist -
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Show quoted text 6 lines
> im not going to argue whether this is right or wrong but in delphi at
> least
> $R only affects run time range checking. In delphi that code will give
> an
> error (constant expression violates subrange bounds) even with range
> checking off.
I think this is a special case with for-loops. Delphi also doesn't allow the loop-variable to be int64. I'll add a check to test for the 32bit range. Ofcourse this is a 32bit target only issue. The code is legal on 64bit targets.