Good morning!
Am 02.07.2017 um 22:02 schrieb Florian Klämpfl:
> Am 02.07.2017 um 21:40 schrieb Martok:
>> Honestly, I still don't understand why we're even having this discussion.
>
> Because it is a fundamental question: if there is any defined behavior
> possible if a v
Am 02.07.2017 um 19:47 schrieb Florian Klämpfl:
> Am 02.07.2017 um 19:29 schrieb Martok:
>>type Percentile = 1..99;
>>var I: Percentile;
>>begin
>> I:= 99;
>> inc(I); // I is now 100
>
> Forgot the mention:
> Tried with $r+ :)
Am 02.07.2017 um 20:29 schrieb Ondrej Pokorny:
> On 02.07.2017 20:23, Florian Klämpfl wrote:
>> And the compiler writes no warning during compilation?
>
> It does indeed.
But about something else.
Can we please stop derailing from the main issue here?
> If we get a convenient way to assign
> They are:
> http://docwiki.embarcadero.com/Libraries/XE5/en/System.Boolean
That prototype is a recent invention, it wasn't there in older versions. Also
the text sounds quite different somewhere else:
http://docwiki.embarcadero.com/RADStudio/XE5/en/Simple_Types#Boolean_Types
> Yes. What I
Booleans are not enums in Delphi (not even ordinals), but their own little
thing. "if boolean_expr" is always a jz/jnz, no matter what. They are defined as
0=FALSE and "everything else"=TRUE
However:
var
b : boolean;
begin
b:=boolean(3);
if b = True then
writeln(true)
else if b =
Addendum to this:
> This was also always my intuition that the else block is also triggered for
> invalid enum values (the docs even literally say that, "If none of the case
> constants match the expression value") - and it *is* true in Delphi.
There is a reason why this is true in Delphi:
ld prefer discussing these instead of having to
prove that "not-as-defined"-behaviour is not the same as "undefined behaviour".
Kind regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
about something that
breaks input sanitation code (but only sometimes) is just... wow.
If anybody wants it, here's the patch I'll be rolling on the windows snapshots
from now on.
Have a good weekend,
Martok
Index: compiler/ncgset.pas
e discussed
here.
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
week-long discussion here
never happened anyway.
Martok
Am 10.05.2017 um 08:38 schrieb Mattias Gaertner:
> On Tue, 9 May 2017 14:59:16 +0200
> Michael Schnell <mschn...@lumino.de> wrote:
>
>> On 06.05.2017 09:39, Sven Barth via fpc-devel wrote:
>>> That might be
php?id=31758> for
reference.
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
tibility (yes it does
> matter)
> and we also ensure a uniform set of string tables.
If that was what happened, ok. But from the error message Matthias listed as (1)
I would assume that the actual string type is UCS2String, at least at some point
in the process.
Just my 2 cents...
Martok
>> Does it is possible that the LineInfo trace (-gl option) are broken (no
>> output)
>> in 3.0.2 version on Linux (at least)?
>
> Hm. Indeed. I can reproduce the issue :/
AFAIR lineinfo.pp only works with Stabs? Didn't the default c
ut then just
pointlessly add the second-most expensive operation in between ;-)
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
each time), so I have a feeling this may be a side effect of some other part of
the code.
Does this sound familiar to anyone? If so, what could I do about it?
Regards,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.free
cident
but really are the same type.
Do you have any idea what could be done to work around this?
Thank you in advance,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> I have committed a patch. Please test and report if it is fixed.
> I don't have a 32-bit system available to test on...
Tested on win32: the overflow is fixed, 500M gets incremented by 125M.
I think the RunError is caused by the way ReallocMem works: growing from 869M to
1086M seems to be done
herited from Delphi...
I don't have RTL built with full symbols right now, maybe someone else can
investigate?
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
101 - 118 of 118 matches
Mail list logo
