On Sun, 2 Jul 2017, Tomas Hajny wrote:
By using file of enum (or any data type), you are explicitly telling the
compiler it is OK.
There isn't much difference between telling the compiler that all values
in certain file are of certain type and telling the compiler that the next
value read
Hello All,
Just... one question.
Are the items in the CASE OF statement tested linearly until one test reveals true (or if none, execute
the else condition if any) or there is some mechanism of localization like in a sorted binary tree.
Linearly: the item with a high probability are to be spec
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
d
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 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 storage
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
invalid,
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
>> suc
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+}, le
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 ordin
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 assi
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 the
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 somewhe
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 featur
> 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 wanted
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 in
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:
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/D
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 = Fals
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 2
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.
> There
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: because
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 my
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 e
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 that
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
* http://lists.freepasc
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 e
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 a
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
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:
https://www.freepascal.org/docs-html/prog/progsu
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
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 validati
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 yo
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 you can call to simply confirm an enum has correct values after
read
On Sun, 2 Jul 2017, Martok wrote:
Am 02.07.2017 um 10:40 schrieb Michael Van Canneyt:
These cases are without exception covered by the " unchecked (aka explicit)
typecast," part of Jonas's statement. Including Read(File).
Aye, that was kinda my point ;)
It is really hard to write code that
> Yes, checking the data. I can easily create a similar problem as above with
> the "range checks" for
> the jump table by reading a negative value into the enum. Unfortunately, the
> checks are unsigned ...
Actually, fun fact, *fortunately* the checks are unsigned. Having a negative
value (or ge
Am 02.07.2017 um 10:40 schrieb Michael Van Canneyt:
> These cases are without exception covered by the " unchecked (aka explicit)
> typecast," part of Jonas's statement. Including Read(File).
Aye, that was kinda my point ;)
It is really hard to write code that interacts with the outside world with
> Is this made safe by always having an else/otherwise? If so, could the
> compiler at least raise a warning if an enumeration was sparse but there
> was no else/otherwise to catch unexpected cases?
Interestingly, not in FPC.
This was also always my intuition that the else block is also triggere
On 7/2/2017 11:19 AM, Florian Klämpfl wrote:
Am 02.07.2017 um 00:26 schrieb Martok:
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
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 ha
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 om
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 tha
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 jumptabl
41 matches
Mail list logo
