Sergei Gorelkin wrote / napísal(a):
29.02.2012 18:21, LacaK пишет:
It cannot be fixed for Delphi mode only because a single copy of RTL
is used for all compiler modes.
The current situation where out of range 'length' parameter is
adjusted but 'index' out of range
raises exception is simply se
In our previous episode, Graeme Geldenhuys said:
> I'm busy setting up a new development system using FreeBSD 9.0
> (32-bit) on i386 hardware. I downloaded the FPC 2.6.0 binary release
> for FreeBSD 8.0, which works fine. But due to the thread / semaphore
> bug in FPC 2.6.0 (no threaded apps can ru
>
> I guess there must be an outdated Makefile or something in Trunk, for FreeBSD.
I managed to figure this out, and amend the Makefile.fpc and
regenerate the Makefile.
Attached is a patch for the ide/Makefile.fpc
--
Regards,
- Graeme -
___
fpGU
Hi,
I'm busy setting up a new development system using FreeBSD 9.0
(32-bit) on i386 hardware. I downloaded the FPC 2.6.0 binary release
for FreeBSD 8.0, which works fine. But due to the thread / semaphore
bug in FPC 2.6.0 (no threaded apps can run) I am forced to use FPC
2.7.1
Anyway, I checked o
Am 29.02.2012 14:31, schrieb Sergei Gorelkin:
The current situation where out of range 'length' parameter is adjusted
but 'index' out of range raises exception is simply self-inconsistent.
It is also inconsistent with behavior of Copy for strings.
Adjusting index will neither cause any buffer ov
Il 28/02/2012 23:34, Tomas Hajny ha scritto:
Jonas is right, it is no bug. The difference you get between the case
of having LFN enabled or not is most likely related to the fact that
you search for '*' mask rather than '*.*' in your example. As you
might know, '*' matches
I missed that, than
ik schrieb:
I think it's a Delphi bug to act like that. You must provide a length
that is not bigger in size. It's up to you the developer.
Otherwise you might have more then one type of buffer overflows in your code !
The way Delphi solved it, is by taking the responsibility from the
developer
Paul Ishenin schrieb:
You found some bug in the compiler. Property can only be declared inside
a structure but compiler allowed to do this in a unit level.
AFAIK unit-properties are an intentional FPC extension over Delphi.
I already used it for debugging purposes, replacing global variables
29.02.2012 18:21, LacaK пишет:
It cannot be fixed for Delphi mode only because a single copy of RTL is used
for all compiler modes.
The current situation where out of range 'length' parameter is adjusted but
'index' out of range
raises exception is simply self-inconsistent. It is also inconsist
Sergei Gorelkin wrote / napísal(a):
29.02.2012 17:05, Sven Barth пишет:
It's not a bug in Delphi if they write it in the documentation.
Whether we should copy this behavior
is the question (maybe only in Delphi mode).
It cannot be fixed for Delphi mode only because a single copy of RTL
is
Am 29.02.2012 14:31, schrieb Sergei Gorelkin:
29.02.2012 17:05, Sven Barth пишет:
It's not a bug in Delphi if they write it in the documentation.
Whether we should copy this behavior
is the question (maybe only in Delphi mode).
It cannot be fixed for Delphi mode only because a single copy of
> In the mean time there is tons of code that relies on copy() copying until
> end of string or dynamic array. Constructions like
> param=copy(s,pos('=')+1,length(s)) are plenty. Just do a grep in the fpc
> compiler dir for "copy(" and you'l find plenty of copy(s,p+1,255) and the
> like.
Second th
29.02.2012 17:05, Sven Barth пишет:
It's not a bug in Delphi if they write it in the documentation. Whether we
should copy this behavior
is the question (maybe only in Delphi mode).
It cannot be fixed for Delphi mode only because a single copy of RTL is used
for all compiler modes.
The curre
> > Delphi documentation says:
> > "If Index is larger than the length of S, Copy returns an
> empty string
> > or array." http://docwiki.embarcadero.com/VCL/en/System.Copy
> >
> > Can it be fixed also in FPC?
>
> I think it's a Delphi bug to act like that. You must provide
> a length that is
On Wednesday 29 of February 2012 13:54:40 ik wrote:
> On Wed, Feb 29, 2012 at 14:44, LacaK wrote:
> > Hi *,
> > I found small incompatibility between Delphi and FPC.
> >
> > This code:
> > var a,b: array of byte;
> > begin
> > 适适 setlength(a,2);
> > 适适 b:=copy(a,2,1); //<--HERE "Range check error
Am 29.02.2012 13:54, schrieb ik:
On Wed, Feb 29, 2012 at 14:44, LacaK wrote:
Hi *,
I found small incompatibility between Delphi and FPC.
This code:
var a,b: array of byte;
begin
适适 setlength(a,2);
适适 b:=copy(a,2,1); //<--HERE "Range check error" in FPC, Delphi returns
empty array
end;
Delphi
On Wed, Feb 29, 2012 at 14:44, LacaK wrote:
> Hi *,
> I found small incompatibility between Delphi and FPC.
>
> This code:
> var a,b: array of byte;
> begin
> 适适 setlength(a,2);
> 适适 b:=copy(a,2,1); //<--HERE "Range check error" in FPC, Delphi returns
> empty array
> end;
>
> Delphi documentation
Hi *,
I found small incompatibility between Delphi and FPC.
This code:
var a,b: array of byte;
begin
setlength(a,2);
b:=copy(a,2,1); //<--HERE "Range check error" in FPC, Delphi
returns empty array
end;
Delphi documentation says:
"If Index is larger than the length of S, *Copy* returns
Sven Barth wrote:
Am 29.02.2012 00:31, schrieb Tomas Hajny:
To let Mark (and Sven) know - I tried to add support for this to the
compiler but I couldn't make it to work for OPT. The approach is OK
in general (apart from the limitation that the compiler may also be
compiled without Makefiles an
Am 29.02.2012 00:31, schrieb Tomas Hajny:
On 9 Feb 12, at 23:09, Sven Barth wrote:
On 09.02.2012 22:14, Mark Morgan Lloyd wrote:
Sven Barth wrote:
On 09.02.2012 18:59, Mark Morgan Lloyd wrote:
Tomas Hajny wrote:
Yes, this is what I suggested to do above; for -an, not in general,
because I d
Hi all,
the other day i had to do a utility to talk with a delphi written app
via its web services api. In no time i had build a prototype with WST
which worked perfectly.
Now because the result sets was midas's datapacket i added a
bufdataset and used the xmldatapacketreader unit. The only
21 matches
Mail list logo