Il 31/07/2019 08:37, thaddy ha scritto:
On 2019-07-31 08:26, Marco Borsari via fpc-devel wrote:
What
needs to be detected if all *used* labels are within the confines of the
used ordinal, but a selector without label should throw an error.
In the case of my patch it behaves like extended
On 2019-07-30 12:12, Marco Borsari via fpc-devel wrote:
On Tue, 30 Jul 2019 06:38:56 +0200
thaddy wrote:
According to what I found there is no smoking gun: I could not find
any
implementation or reference from any reputable source that implements
the case statement in the way that is
On 2019-07-30 12:26, Paul Breneman wrote:
This message thread has been interesting to read.
I just realized today that I dealt with similar issues in Delphi 19
years ago. This is discussed in the good Microsoft Press book *Code
Complete* by Steve McConnell. Using the default else block of a
On 2019-07-30 11:18, J. Gareth Moreton wrote:
Yeah, I don't find that description clear either. One shouldn't have
to be a lawyer in order to decrypt such standards!
Of course, FPC can follow its own standard, but it should be one that
everyone agrees on. While I think we shouldn't live in
On 2019-07-30 10:23, Michael Van Canneyt wrote:
Just interpreting the standard, I think that the error should be
run-time, not compile-time (although definitely keep the warning).
That's just my take on it though. If it is to be changed, it should
be simple enough by configuring the
On 2019-07-31 08:26, Marco Borsari via fpc-devel wrote:
On Wed, 31 Jul 2019 01:26:23 +0200
Martok wrote:
Of course, if you wanted a run-time error you would need to insert a
run-time
check, and 'some people' seemed to be hell-bent on saving these 2
cycles at any
cost.
The patch to switch
So as of yet I've still been unable to reproduce the internal error
that's being described, and everything else so far has been working
successfully. Wait... that SHOULD be a good thing! Still, bugs I can't
reproduce are frustrating.
This might be a lot to ask, but testing still needs to be
On Wed, 31 Jul 2019 01:26:23 +0200
Martok wrote:
> Of course, if you wanted a run-time error you would need to insert a run-time
> check, and 'some people' seemed to be hell-bent on saving these 2 cycles at
> any
> cost.
>
> The patch to switch from option a1) to a2) would be straightforward,
I submitted a patch so that iso mode behaves like extended pascal mode.
i.e.
The compile time error is gone (also in the case I showed to be a true
bug)
And a run-time error is issued as per extendedpascal.
Solves most problems I have with the "feature" and existing code written
in iso
I have the faint suspicion that the case chapter in the extended pascal
standard is a deliberate rephrasing of the one in iso 7185:1990.
Specifically adding the wording "dynamic" with regard to the error type.
___
fpc-devel maillist -
Indeed the wording between 7185 and 10206 has changed little, but
important: dynamic. Therefor note I still think the patch is acceptable.
I studied some more on the subject and here I will try and explain what
the actual behavior needs to be when one want to interpret the ISO 7185
case very
I might add to my previous post that case(2) is open for discussion
after the patch:
One might argue that also in the case of ISO 10206 the compiler should
throw a compile-time error in that particular case, because it is
already obvious that the value has no label.
Therefor I left out a
The C case block differs from Pascal's case block in that it falls
through if no return is specified.
That means a single value can trigger multiple case labels. In Pascal it
can only trigger one case label.
Because of the fall-through a default: has greater purpose than in
Pascal.
Scott Franco a.k.a. Moore says this, what makes sense, in his manual
"Rules of ISO 7185":
==
Case statement
The case statement defines an action to be executed on each of the
values of an ordinal:
case x of
c1: statement;
c2: statement;
...
end;
The "selector"
On 2019-07-30 14:04, Sven Barth via fpc-devel wrote:
thaddy schrieb am Di., 30. Juli 2019, 10:04:
On 2019-07-30 01:43, J. Gareth Moreton wrote:
As someone on the issue pointed out... on page 2, section 3.1:
3.1 Error
I have added this to the bug report. Consider that here all possible
On Tue, Jul 23, 2019 at 9:49 PM Christo Crause
wrote:
> The following test code generates a redundant mov instruction which seems
> to be related to a situation with an unused procedure parameter and the
> inc() procedure:
>
> program testRegAlloc;
> var
> a, b: byte;
> procedure
16 matches
Mail list logo
