On Sun, 2 Jul 2017, Florian Klämpfl wrote:
So, we have a problem here: either the type system is broken because we can put
stuff in a type without being able to check if it actually belongs there, or
Tcgcasenode is broken because it (and _only_ it, as far as I can see) wants to
be clever by
On 02/07/17 11:59, Yury Sidorov wrote:
Indeed, I've done some tests and found out that when range checking is
enabled enums are not checked at all. Even array access with enum index
is not checked.
According to docs enums should be range checked:
On 02/07/17 18:26, Ondrej Pokorny wrote:
On 02.07.2017 18:20, Jonas Maebe wrote:
Range checking code is generated for operations involving enums if,
according to the type system, the enum can be out of range. Just like
with integer sub-range types.
Allow me a stupid question: how to convert
On 02.07.2017 18:28, Jonas Maebe wrote:
On 02/07/17 18:26, Ondrej Pokorny wrote:
Allow me a stupid question: how to convert an integer to enum with
range checking?
The current possibilities and possibly improvements have been
mentioned elsewhere in this thread already
*
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 =
On Sun, 2 Jul 2017, Tomas Hajny wrote:
On Sun, July 2, 2017 16:48, Marco van de Voort wrote:
In our previous episode, Martok said:
It is really hard to write code that interacts with the outside world
without
having a validation problem.
Then you arguing wrong. Then you don't need
On 02.07.2017 18:20, Jonas Maebe wrote:
Range checking code is generated for operations involving enums if,
according to the type system, the enum can be out of range. Just like
with integer sub-range types.
Allow me a stupid question: how to convert an integer to enum with range
checking? A
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:
Am 02.07.2017 um 19:29 schrieb Martok:
> 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.
>
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+ :)?
>So if this is a legal statement,
Well, it is a matter of definition, if a statement causing a rte
On 01/07/17 22:45, Martok wrote:
This is fine if (and only if) we can be absolutely sure that theEXPRESSIONRESULT always is between
[low(ENUM)..high(ENUM)] - otherwise %eax inthe example above may be anywhere up to
high(basetype)'th element of thejumptable, loading an address from anything
Am 02.07.2017 um 00:26 schrieb Martok:
> Depending on the number of case labels, tcgcasenode.pass_generate_code
> (ncgset.pas:1070) may choose one of 3 strategies for the "matching" task:
> jumptable, jmptree or linearlist. Jmptree and linearlist are basically "lots
> of
> if/else", while
On 02/07/17 18:43, Ondrej Pokorny wrote:
Thanks, so there is no enumeration range checking from the compiler at
all :/
Yes, there is range checking for enums. No, there is no built-in checked
conversion from integer to arbitrary enumeration types. That's why I
suggested in the bug report
In our previous episode, Tomas Hajny said:
> > Worse, tying it to range check would then have heaps of redundant checking
> > everywhere, not just enums.
>
> True. That's why I believe that Read from a (typed) file should perform
> such validation - but it doesn't at the moment, as mentioned in
On Sun, 2 Jul 2017, Tomas Hajny wrote:
By declaring it as a File of Enum, you are telling the compiler that it
contains only valid enums.
Noone can ever ensure, that a file doesn't get corrupted / tampered with
on a storage medium.
No-one can ensure a memory location cannot get corrupted
On 02.07.2017 18:49, Jonas Maebe wrote:
No, there is no built-in checked conversion from integer to arbitrary
enumeration types. That's why I suggested in the bug report that
started this thread to file a feature request for such a conversion.
Very good :)
Are there any disadvantages of the
On Sun, 2 Jul 2017, Martok wrote:
Hi all,
The only way to get data with an invalid value in an enum in Pascal is by
using an unchecked (aka explicit) typecast, by executing code without range
checking (assigning an enum from a larger parent enum type into a smaller
sub-enum type), or by
On Sun, July 2, 2017 16:48, Marco van de Voort wrote:
> In our previous episode, Martok said:
>> It is really hard to write code that interacts with the outside world
>> without
>> having a validation problem.
>
> Then you arguing wrong. Then you don't need validation everywhere, but
> something
On Sun, July 2, 2017 17:05, Michael Van Canneyt wrote:
> On Sun, 2 Jul 2017, Tomas Hajny wrote:
>
>> On Sun, July 2, 2017 16:48, Marco van de Voort wrote:
>>> In our previous episode, Martok said:
It is really hard to write code that interacts with the outside world
without
having a
Am 02.07.2017 um 20:12 schrieb Martok:
>> 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
*sigh* This is the case since pascal was iso standarized.
> the text sounds quite different
On 02.07.2017 19:39, Florian Klämpfl wrote:
So this means:
var
b : boolean;
begin
b:=boolean(3);
if b then
writeln(true)
else if not(b) then
writeln(false)
else
writeln(ord(b));
end.
writes 3 in delphi?
IMO you picked up a Delphi compiler bug/undocumented
In our previous episode, Florian Kl?mpfl said:
[ Charset UTF-8 unsupported, converting... ]
> 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
On 02.07.2017 20:23, Florian Klämpfl wrote:
And the compiler writes no warning during compilation?
It does indeed.
On 02.07.2017 20:18, Florian Klämpfl wrote:
Yes, undefined behavior.
I think I got your point :) You are right, sorry for wasting your time.
If we get a convenient way to
On 02.07.2017 19:29, Martok wrote:
- Case statements execute*precisely one* of their branches: the statements of
the matching case label, or the else block otherwise
To support your argument, the current Delphi documentation says the same:
Am 02.07.2017 um 19:51 schrieb Martok:
> Booleans are not enums in Delphi (not even ordinals),
They are:
http://docwiki.embarcadero.com/Libraries/XE5/en/System.Boolean
> but their own little
> thing. "if boolean_expr" is always a jz/jnz, no matter what.
Yes. This is an optimization which is
> 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
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 variable
contains an invalid value. I consider a value outside of the declared range as
I store record data in files with a checksum (usually a CRC). I block read
them into an array buffer and verify the checksum. If it passes, I assign
via typecast the array buffer to a variable of the record type. If I'm the
only one reading and writing the files that is usually enough to handle
Am 02.07.2017 um 19:55 schrieb Ondrej Pokorny:
> On 02.07.2017 19:29, Martok wrote:
>> - Case statements execute *precisely one* of their branches: the statements
>> of
>> the matching case label, or the else block otherwise
>
> To support your argument, the current Delphi documentation says
On Sun, July 2, 2017 18:39, Michael Van Canneyt wrote:
> On Sun, 2 Jul 2017, Tomas Hajny wrote:
>
>>> By declaring it as a File of Enum, you are telling the compiler that it
>>> contains only valid enums.
>>
>> Noone can ever ensure, that a file doesn't get corrupted / tampered with
>> on a
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
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+ :)?
That case is also documented. RTE in {$R+},
On Sun, July 2, 2017 19:15, Marco van de Voort wrote:
> In our previous episode, Tomas Hajny said:
>> > Worse, tying it to range check would then have heaps of redundant
>> checking
>> > everywhere, not just enums.
>>
>> True. That's why I believe that Read from a (typed) file should perform
>>
33 matches
Mail list logo
