Just to add confirmation to what Frank and Gale have said. In the following "foo" example, yes, the string length is undefined. Yes it is supposed to be an error, and is defined as an error in ISO and Extended Pascal standards. No, it's probably not desirable to start automatically initializing everything; it would be costly in time and space and generally an error-free program will do it's own initialization when needed. And sure, GPC does not detect undefined values, in fact, very very few "compilers" (actually runtimes) do detect undefined values. (Our "Dr. Pascal" interpreter is one of the few systems that does, and it costs a lot of runtime overhead and complexity.) It's very reasonable for GPC to not try to do this.
Willett Kempton Visible Software
On 7 Aug 2005, at 21:21, Frank Heckenbach wrote:
Russell Whitaker wrote:
The capacity, OTOH, is initialized, and must be in order for the string to work at all.
Would it be reasonable to define the length to be 0 as the default initialization?
It would be nonstandard. Basically the same question as defining default values for other types. The programmer can do this explicitly (String (n) value '') if wanted.
Otherwise the following should produce an error but dosen't:
program foo; var s : string( 500 ); begin writeln( length(s) ); end.
As I said, GPC doesn't check for using undefined values at all. (Currently, and this isn't going to change soon, as this is not exactly trivial to implement in general ...)
Frank
willett wrote:
Just to add confirmation to what Frank and Gale have said. In the following "foo" example, yes, the string length is undefined. Yes it is supposed to be an error, and is defined as an error in ISO and Extended Pascal standards. No, it's probably not desirable to start automatically initializing everything; it would be costly in time and space and generally an error-free program will do it's own initialization when needed. And sure, GPC does not detect undefined values, in fact, very very few "compilers" (actually runtimes) do detect undefined values. (Our "Dr. Pascal" interpreter is one of the few systems that does, and it costs a lot of runtime overhead and complexity.) It's very reasonable for GPC to not try to do this.
Please don't toppost.
I look on the string facility as similar to the file facility in some respects. For files, some sort of automatic initialization is needed so that reset/rewrite can function, and so that the error of reading/writing to unopened files can be detected. For strings the 'capacity' has to be initialized, and I doubt it would be much trouble to zero the length field at the same time. Note that this is much different from initializing the entire string storage.
CBFalconer wrote:
I look on the string facility as similar to the file facility in some respects. For files, some sort of automatic initialization is needed so that reset/rewrite can function, and so that the error of reading/writing to unopened files can be detected. For strings the 'capacity' has to be initialized, and I doubt it would be much trouble to zero the length field at the same time. Note that this is much different from initializing the entire string storage.
To drag the analogy, initializing the length of a string would be comparable to resetting a file variable to an empty (internal) file, which is not done.
But perhaps more important, initializing strings (which are not declared with an explicit initial value) would be non-standard, and encouraging programmers to rely on this leads no more non-portable code. I don't think you'd like this. ;-)
Frank
Frank Heckenbach wrote:
CBFalconer wrote:
I look on the string facility as similar to the file facility in some respects. For files, some sort of automatic initialization is needed so that reset/rewrite can function, and so that the error of reading/writing to unopened files can be detected. For strings the 'capacity' has to be initialized, and I doubt it would be much trouble to zero the length field at the same time. Note that this is much different from initializing the entire string storage.
To drag the analogy, initializing the length of a string would be comparable to resetting a file variable to an empty (internal) file, which is not done.
But perhaps more important, initializing strings (which are not declared with an explicit initial value) would be non-standard, and encouraging programmers to rely on this leads no more non-portable code. I don't think you'd like this. ;-)
Well, I always felt apologetic that, in PascalP, files as components of other things, such as arrays of files, or a file component of a record, required the non-standard use of "fileinit(record.filecomponent)" before it would function normally.
I destroyed the article where Gale (I believe) explained the ISO10206 specification. That was a mistake, I should have kept it here. As I see it the problem is that an uninitialized length field will mean unpredictable action, that may or may not involve an error message.
CBFalconer wrote:
Well, I always felt apologetic that, in PascalP, files as components of other things, such as arrays of files, or a file component of a record, required the non-standard use of "fileinit(record.filecomponent)" before it would function normally.
Yes, that's a tricky bit that we also had to spend some effort to get working automatically ...
I destroyed the article where Gale (I believe) explained the ISO10206 specification. That was a mistake, I should have kept it here.
BTW, the archives are back online, and they have a search function. Do you mean this one?
http://www.gnu-pascal.de/crystal/gpc/en/mail12577.html
As I see it the problem is that an uninitialized length field will mean unpredictable action, that may or may not involve an error message.
Yes -- just like many other cases of using uninitialized variables/components ...
Frank
-
CBFalconer -
Frank Heckenbach -
willett