Re: [fpc-pascal] Range checks

[Adriaan van Os]

Jonas Maebe wrote:


Actually, it won't help because "qword - 1" will still be evaluated as
qword. The issue is that there is no safe way to evaluate this with
range checking that is correct in all cases without a 128 bit integer type:
1) if you evaluate it as qword, you get a range error if count is 0 (as
above)
2) if you evaluate it as int64, then if count is high(int64)+1 you will
get a range error even though the result could be represented in int64


Without type inclusion, that is in a language that allows mixing typed an untyped numbers, there is 
no anambiguous solution, as Jonas points out. So, I suggest to choose the next best solution, which 
is to let result type of the expression decide whether to apply 1) or 2). In this case, it would be 
2) as the result type is signed.


Regards,

Adriaan van Os

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] _Release call location for unused function results

[Maciej Izak]

2018-01-30 8:34 GMT+01:00 Michael Van Canneyt :

> The question is whether Delphi's behaviour is intentional.


Sadly it is intentional (but undocumented), the facts:

* Barry Kelly compiler guy post
* Works with all known Delphi versions
* I've checked this for NG compiler - also works like in classic Delphi
(especially this point means that the "feature" is intentional )

Seems like the SCOPEDINTERFACEDESTROY mode-switch is necessary. The
question is:

would we like to enabling this for all Delphi modes?

the approach with "with" for "scoping" seems more proper even in Delphi
mode. Probably SCOPEDINTERFACEDESTROY should stay off for all modes
including Delphi modes.

-- 
Best regards,
Maciej Izak
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] _Release call location for unused function results

[Marco van de Voort]

In our previous episode, Maciej Izak said:
> > The question is whether Delphi's behaviour is intentional.
> Sadly it is intentional (but undocumented), the facts:
> 
> * Barry Kelly compiler guy post
> * Works with all known Delphi versions
> * I've checked this for NG compiler - also works like in classic Delphi
> (especially this point means that the "feature" is intentional )

Have you tested this with large methods? The trouble is we only get
reports/code from people for whom the hack succeeded, not from ones that
tried and failed.

I can remember from one of the bugreports or mail threads about very large
procedure bodies (where FPC hit virtual register numbers) that Delphi starts
to deallocate temps earlier depending on procedure size and maybe used
language constructs.  (number of structured temps?) That was mostly strings,
but might also go for interfaces. I can also imagine that one would like
to disable this in case recursion is detected.

> Seems like the SCOPEDINTERFACEDESTROY mode-switch is necessary. 

No, one could also simply fix the relevant code.

> question is: would we like to enabling this for all Delphi modes?

Everything that needs this is essentially feature abuse. I would not enable
it by default, but IF for some reason this needs to be added, when enabled
add a permanent note/warning that this is a workaround for broken code.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] _Release call location for unused function results

[Maciej Izak]

2018-01-30 14:40 GMT+01:00 Marco van de Voort :

> Have you tested this with large methods? The trouble is we only get
> reports/code from people for whom the hack succeeded, not from ones that
> tried and failed.
>
> I can remember from one of the bugreports or mail threads about very large
> procedure bodies (where FPC hit virtual register numbers) that Delphi
> starts
> to deallocate temps earlier depending on procedure size and maybe used
> language constructs.  (number of structured temps?) That was mostly
> strings,
> but might also go for interfaces. I can also imagine that one would like
> to disable this in case recursion is detected.
>

Yes I am aware of this. In the case of interfaces for large methods all
seems works as presented for simple example. I was not able to reproduce
this problem for interfaces.


> > Seems like the SCOPEDINTERFACEDESTROY mode-switch is necessary.
>
> No, one could also simply fix the relevant code.
>

I am not the fan of SCOPEDINTERFACEDESTROY. My first impression about this
was : WTF. In some cases is almost impossible to fix large legacy (and
often wrong) code base.


> > question is: would we like to enabling this for all Delphi modes?
>
> Everything that needs this is essentially feature abuse. I would not enable
> it by default


+1 . Anyway I am still considering : commit or not :P.

-- 
Best regards,
Maciej Izak
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] _Release call location for unused function results

[Sven Barth via fpc-pascal]

Am 30.01.2018 15:07 schrieb "Maciej Izak" :



> > question is: would we like to enabling this for all Delphi modes?
>
> Everything that needs this is essentially feature abuse. I would not enable
> it by default


+1 . Anyway I am still considering : commit or not :P.


While I still don't want to have this switch no matter the legacy codebase
affected by it, if we add it we definitely don't add it enabled anywhere.
And please, maybe it "ScopedInterfaceRelease", not "-Destroy" as that is
what the functionality does.

Also I remember from some time back that someone (maybe even Jonas)
presented an example where Delphi does in fact behave different. I'd need
to find that again however. :/

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Initialize records C style

[Darius Blaszyk]

I have this code in C, the variable p is a 20 element array. However 
only the first two items are initialized. Is this possible in pascal as 
well?


TIA, Darius

struct point {
   intx;
   inty;
};

struct point p[20]= {
{0, 100},
{3,1}
};
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Initialize records C style

[Marco van de Voort]

In our previous episode, Darius Blaszyk said:
> I have this code in C, the variable p is a 20 element array. However 
> only the first two items are initialized. Is this possible in pascal as 
> well?

No, all or nothing.
 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] _Release call location for unused function results

[Florian Klämpfl]

Am 30.01.2018 um 15:07 schrieb Maciej Izak:
> 2018-01-30 14:40 GMT+01:00 Marco van de Voort  >:
> 
> Have you tested this with large methods? The trouble is we only get
> reports/code from people for whom the hack succeeded, not from ones that
> tried and failed.
> 
> I can remember from one of the bugreports or mail threads about very large
> procedure bodies (where FPC hit virtual register numbers) that Delphi 
> starts
> to deallocate temps earlier depending on procedure size and maybe used
> language constructs.  (number of structured temps?) That was mostly 
> strings,
> but might also go for interfaces. I can also imagine that one would like
> to disable this in case recursion is detected.
> 
> 
> Yes I am aware of this. In the case of interfaces for large methods all seems 
> works as presented for
> simple example. I was not able to reproduce this problem for interfaces.
>  
> 
> > Seems like the SCOPEDINTERFACEDESTROY mode-switch is necessary.
> 
> No, one could also simply fix the relevant code.
> 
> 
> I am not the fan of SCOPEDINTERFACEDESTROY. My first impression about this 
> was : WTF. In some cases
> is almost impossible to fix large legacy (and often wrong) code base.
>  
> 
> > question is: would we like to enabling this for all Delphi modes?
> 
> Everything that needs this is essentially feature abuse. I would not 
> enable
> it by default
> 
> 
> +1 . Anyway I am still considering : commit or not :P.

If is implemented, it needs to be clearly documented how it works.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal