The following program will rise an error:
Adress: $00401493
Procedure: fpc_pchar_length
program project1;
{$mode objfpc}{$H+}
uses
Classes;
var Buffer: PChar;
begin
Buffer := Nil;
WriteLn(Length( Buffer ));
end.is this a bug?
Alex
Mailing lists / fpc-devel / 2005-12
fpc_pchar_length error
9 messages · 4 people · –
- Alexandrov Alexandru 4
- Jonas Maebe 2
- Michael Van Canneyt 2
- dannym 1
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Alexandrov Alexandru wrote 19 lines
The following program will rise an error:
Adress: $00401493
Procedure: fpc_pchar_length
program project1;
{$mode objfpc}{$H+}
uses
Classes;
var Buffer: PChar;
begin
Buffer := Nil;
WriteLn(Length( Buffer ));
end.
is this a bug?
It depends on the specs of "length" :-)
Michael.
Michael Van Canneyt wrote 31 lines
On Sat, 10 Dec 2005, Alexandrov Alexandru wrote:
> The following program will rise an error:
> Adress: $00401493
> Procedure: fpc_pchar_length
>
>
> program project1;
>
> {$mode objfpc}{$H+}
>
> uses
> Classes;
>
> var Buffer: PChar;
> begin
> Buffer := Nil;
> WriteLn(Length( Buffer ));
> end.
>
> is this a bug?
It depends on the specs of "length" :-)
Michael.
_______________________________________________
fpc-devel maillist -
http://lists.freepascal.org/mailman/listinfo/fpc-devel
What do you mean with specs?
btw i forgot to mention, i tested on winxp.
In Delphi the result is 0, and no error.
Alex
Alexandrov Alexandru wrote> It depends on the specs of "length" :-) What do you mean with specs?
How it is defined to behave in the documentation (i.e., whether the documentation says "if you call length with as argument a nil pointer, the result is defined to be 0", or "the behaviour of length with as argument a nil pointer is undefined", or simply doesn't mention it at all).
btw i forgot to mention, i tested on winxp. In Delphi the result is 0, and no error.
Delphi obviously is a lot more tolerant to bad programming than we are... A pchar which is nil is not an empty string, but an invalid pointer. It's like assuming that a nil pointer to a longint is the same as a pointer to the value 0 or so.
Jonas
Jonas Maebe wrote 11 lines
On 11 dec 2005, at 22:22, Alexandrov Alexandru wrote:
>> It depends on the specs of "length" :-)
>
> What do you mean with specs?
How it is defined to behave in the documentation (i.e., whether the
documentation says "if you call length with as argument a nil pointer, the
result is defined to be 0", or "the behaviour of length with as argument a
nil pointer is undefined", or simply doesn't mention it at all).
Exactly.
Show quoted text 7 lines
> btw i forgot to mention, i tested on winxp.
> In Delphi the result is 0, and no error.
Delphi obviously is a lot more tolerant to bad programming than we are... A
pchar which is nil is not an empty string, but an invalid pointer. It's like
assuming that a nil pointer to a longint is the same as a pointer to the
value 0 or so.
I agree with this position.
A Nil pointer is usually a sign of a bad or uninitialized value.
I will try to update the docs with this.
Michael.
Michael Van Canneyt wrote 28 lines
On Mon, 12 Dec 2005, Jonas Maebe wrote:
>
> On 11 dec 2005, at 22:22, Alexandrov Alexandru wrote:
>
>>> It depends on the specs of "length" :-)
>>
>> What do you mean with specs?
>
> How it is defined to behave in the documentation (i.e., whether the
> documentation says "if you call length with as argument a nil pointer, the
> result is defined to be 0", or "the behaviour of length with as argument a
> nil pointer is undefined", or simply doesn't mention it at all).
Exactly.
>> btw i forgot to mention, i tested on winxp.
>> In Delphi the result is 0, and no error.
>
> Delphi obviously is a lot more tolerant to bad programming than we are... A
> pchar which is nil is not an empty string, but an invalid pointer. It's like
> assuming that a nil pointer to a longint is the same as a pointer to the
> value 0 or so.
I agree with this position.
A Nil pointer is usually a sign of a bad or uninitialized value.
..but we speak here about the length of the string. IMO the length of null string is the same as the length of an unitialised string.
Alex
Exactly. I agree with this position. A Nil pointer is usually a sign of a bad or…
Michael Van Canneyt wrote 28 lines
On Mon, 12 Dec 2005, Jonas Maebe wrote:
>
> On 11 dec 2005, at 22:22, Alexandrov Alexandru wrote:
>
>>> It depends on the specs of "length" :-)
>>
>> What do you mean with specs?
>
> How it is defined to behave in the documentation (i.e., whether the
> documentation says "if you call length with as argument a nil pointer, the
> result is defined to be 0", or "the behaviour of length with as argument a
> nil pointer is undefined", or simply doesn't mention it at all).
Exactly.
>> btw i forgot to mention, i tested on winxp.
>> In Delphi the result is 0, and no error.
>
> Delphi obviously is a lot more tolerant to bad programming than we are... A
> pchar which is nil is not an empty string, but an invalid pointer. It's like
> assuming that a nil pointer to a longint is the same as a pointer to the
> value 0 or so.
I agree with this position.
A Nil pointer is usually a sign of a bad or uninitialized value.
..but we speak here about the length of the string. IMO length of null string = length of unitialised string.
Alex
..but we speak here about the length of the string. IMO the length of null string is the…
Alexandrov Alexandru wrote> I agree with this position. > A Nil pointer is usually a sign of a bad or uninitialized value. ..but we speak here about the length of the string.
No, the length of pchar's. A string and a pchar are two different things in Pascal (although you can convert them into each other). A pchar is simply a pointer to an array of characters, by convention terminated by chr(0).
IMO the length of null string is the same as the length of an unitialised string.
An uninitialised ansistring's length is defined to be zero by the documentation. The length of an uninitialised pchar is nowhere defined, nor is the length of an invalid pchar pointer. pchar(null) does not have a defined length, just like pchar(1) and pchar(2) don't have a defined length.
Jonas
..but we speak here about the length of the string. IMO the length of null string is the…
Hi,
Alexandrov Alexandru wrote 32 lines
On 12/12/05, Michael Van Canneyt wrote:
>
>
> On Mon, 12 Dec 2005, Jonas Maebe wrote:
>
> >
> > On 11 dec 2005, at 22:22, Alexandrov Alexandru wrote:
> >
> >>> It depends on the specs of "length" :-)
> >>
> >> What do you mean with specs?
> >
> > How it is defined to behave in the documentation (i.e., whether the
> > documentation says "if you call length with as argument a nil pointer, the
> > result is defined to be 0", or "the behaviour of length with as argument a
> > nil pointer is undefined", or simply doesn't mention it at all).
>
> Exactly.
>
> >> btw i forgot to mention, i tested on winxp.
> >> In Delphi the result is 0, and no error.
> >
> > Delphi obviously is a lot more tolerant to bad programming than we are... A
> > pchar which is nil is not an empty string, but an invalid pointer. It's like
> > assuming that a nil pointer to a longint is the same as a pointer to the
> > value 0 or so.
>
> I agree with this position.
> A Nil pointer is usually a sign of a bad or uninitialized value.
..but we speak here about the length of the string. IMO the length of
null string is the same as the length of an unitialised string.
It isn't technically a string, it's a PChar. Some horrible hack pointer to a char that happens to be able to be interpreted as a string by the programmer (C) or compiler (Pascal).
If something is "nil", the value isn't "there" to begin with. So the length of "value not there" would be either
1) "value not there"
2) *bam*
3) exception, "eeek! it's not there"
but certainly not "0" :)
If you don't have a specific need for a PChar (as in "interfacing to C code"), don't use it. Use a pascal string :)
(Note that all "newer" stuff - read: ms excel etcetc - uses pascal-like strings because using char pointers for string is just ... weird - not to mention *slow* - especially determining the length!)
Alex
cheers,
Danny