Re: [fpc-devel] Copy function and dynamic array
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 self-inconsistent. It is also inconsistent with behavior of Copy for strings. Adjusting index will neither cause any buffer overflows nor make code slower, so it should be fixed. Will you do it or should I register bug in bug tracker? Please create a Mantis issue, so it won't be forgotten. http://bugs.freepascal.org/view.php?id=21396 TIA -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Copy function and dynamic array
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 overflows nor make code slower, so it should be fixed. Agreed, please fix it. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Copy function and dynamic array
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, and made the code a bit slower. Delphi specified Copy as *not* requiring exact parameters. The length always could be bigger than the string length, in which case the copy stops at the end of the source string. Likewise the starting index can be past the length of the source string, resulting in an empty string. Performance is not affected, and the overall code size decreases, when the user doesn't have to calculate and check everything, every time before calling Copy. Please understand that even throwing an exception requires an check before, so that it's only a simple decision whether to fix an improper parameter value silently, or to throw an exception. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Copy function and dynamic array
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 inconsistent with behavior of Copy for strings. Adjusting index will neither cause any buffer overflows nor make code slower, so it should be fixed. Will you do it or should I register bug in bug tracker? Please create a Mantis issue, so it won't be forgotten. Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Copy function and dynamic array
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 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 inconsistent with behavior of Copy for strings. Adjusting index will neither cause any buffer overflows nor make code slower, so it should be fixed. Will you do it or should I register bug in bug tracker? Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Copy function and dynamic array
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 RTL is used for all compiler modes. I forgot that Copy uses a compiler proc instead of being a complete intrinsic. So, yes, you're right ;) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] Copy function and dynamic array
> 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 that, In lack of a explicit "copy-to-end" RTL function I have always used Copy(S, , MaxInt) in Delphi to copy to the end of a string. I find it easier to write, more self-explanatory and perhaps faster to execute (minus a string length fetching and a subtraction) than writing Length(S) - , especially if is an expression. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Copy function and dynamic array
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 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 overflows nor make code slower, so it should be fixed. Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE : [fpc-devel] Copy function and dynamic array
> > 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 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, and made the code a bit slower. And as I > said, I don't think it's a good idea > 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. Ludo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Copy function and dynamic array
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" in FPC, Delphi returns > > empty array > > end; > > > > 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 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, and made the code a bit slower. > And as I said, I don't think it's a good idea +1 ... @lacak, better fix your code. I don't like to be delphi compatibile with such things. zeljko ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Copy function and dynamic array
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 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 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, and made the code a bit slower. And as I said, I don't think it's a good idea 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). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Copy function and dynamic array
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 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 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, and made the code a bit slower. And as I said, I don't think it's a good idea > L. > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel