One of the listed bugs of GPC was "modules without implementation". However, if I understand EP correctly, this actually doesn't concern `interface' modules (as in pmodtest.pas without the `implementation' part):
: Each identifier having a definingÂpoint as a moduleÂidentifier in a : moduleÂheading of a module declaration containing the interfaceÂdirective : interface shall have exactly one of its applied occurrences in a : moduleÂidentification of a moduleÂdeclaration containing the : implementationÂdirective implementation.
In contrast, the following works in GPC (with an almost empty module-block):
module fjf843m;
export fjf843m = all;
const OK = 'OK';
end;
end.
What seems to be missing is this variant (no module-block at all), and I'll add it in the next release (that's easy to do):
module fjf843m;
export fjf843m = all;
const OK = 'OK';
end.
However, AFAICS, EP doesn't require to support `interface' modules without implementation. That's good because GPC has to know when compiling a module whether there will be an implementation part (because it has to create the initializer if (and only if) not).
It also seems reasonable to me from the programmer's point of view. When you write a module interface, you know whether there has to be an implementation (namely, if there are any routines in the interface or an initializer or finalizer will be needed) or not (only constants, types and variables without need for initialization/finalization). So it makes sense to specify this explicitly (by writing `interface' or not).
Can anyone confirm my interpretation?
Frank
Frank Heckenbach wrote:
One of the listed bugs of GPC was "modules without implementation".
Where is the bug listed? It isn't listed under "Known bugs in GPC" at < http://www.gnu-pascal.de/gpc/Known-Bugs.html%3E.
However, if I understand EP correctly, this actually doesn't concern `interface' modules (as in pmodtest.pas without the `implementation' part):
If I understand the comment in pmodtest.pas correctly, EP always requires one and exactly one implementation module to be associated with an interface module. Even if the module-block is empty (except for the required 'end'), there still must exist an implementation module to associate with an interface module. This is what the "shall have exactly one" language in ISO 10206 requires.
: Each identifier having a definingpoint as a moduleidentifier in a : moduleheading of a module declaration containing the interfacedirective : interface shall have exactly one of its applied occurrences in a : moduleidentification of a moduledeclaration containing the : implementationdirective implementation.
In contrast, the following works in GPC (with an almost empty module-block):
module fjf843m;
export fjf843m = all;
const OK = 'OK';
end;
end.
This is conformant to ISO 10206 requirements for modules (except for the export all extension). It is the module-heading [without the interface-directive] ';' module-block alternative for a module-declaration.
What seems to be missing is this variant (no module-block at all), and I'll add it in the next release (that's easy to do):
module fjf843m;
export fjf843m = all;
const OK = 'OK';
end.
I really don't see any need for this variant. It isn't in any way conformant to ISO 10206 requirements and the only "value" of it is to save typing an 'end;'. There are already enough problems with the gaggle of non-compatible, non-standard ISO 7185 based dialect variants so there is no need to create additional problems with non-standard ISO 10206 variants which serves no purpose other than to save typing *four* characters.
However, AFAICS, EP doesn't require to support `interface' modules without implementation. That's good because GPC has to know when compiling a module whether there will be an implementation part (because it has to create the initializer if (and only if) not).
Actually without extensions, EP strictly disallows 'interface' modules without implementation modules. However, as mentioned a while ago in the "Combining .o files?" thread, ISO 10206 suggests in the note to paragraph 6.1.5 that if one wants to implement an extension which allows for a module-interface without a module body the way to do so is with an 'external' interface-directive.
It also seems reasonable to me from the programmer's point of view. When you write a module interface, you know whether there has to be an implementation (namely, if there are any routines in the interface or an initializer or finalizer will be needed) or not (only constants, types and variables without need for initialization/finalization). So it makes sense to specify this explicitly (by writing `interface' or not).
This is pretty much what I called a "pure" interface in the "Combining .o files?" thread. At the time, you didn't see much need for it (or at least not from a unit perspective) or that it had sufficient priority to devote any time on it. However, if your thoughts on it have changed, I think the ISO 10206 suggestion on using an "external" interface-directive is the implementation method to use. For one reason, the syntax location is sufficiently early enough in the parse that you can easily direct the parse to code constructs which don't require any initialization or finalization actions (or at least flag the useage of such constructs as errors). For a second reason, it clearly indicates a programmer's intent that it is strictly an interface-only module without having to deal with the uncertainty of whether the missing 'end' was an inadvertant programmer error or an intentional omission in the deliberate construct of an interface-only module. For another reason, using the ISO 10206 suggested method will hopefully put GPC on the same extensions page as the rare few other ISO 10206 implementors.
Can anyone confirm my interpretation?
For strict ISO 10206 compliance, there is no way to avoid requiring a module-block for a module-heading. ISO 10206 requires the complete specification of a module consisting of a module-heading and a module-block and provides for two alternative forms for the specification.
Gale Paeper gpaeper@empireet.com
Gale Paeper wrote:
Frank Heckenbach wrote:
One of the listed bugs of GPC was "modules without implementation".
Where is the bug listed? It isn't listed under "Known bugs in GPC" at < http://www.gnu-pascal.de/gpc/Known-Bugs.html%3E.
However, if I understand EP correctly, this actually doesn't concern `interface' modules (as in pmodtest.pas without the `implementation' part):
If I understand the comment in pmodtest.pas correctly, EP always requires one and exactly one implementation module to be associated with an interface module. Even if the module-block is empty (except for the required 'end'), there still must exist an implementation module to associate with an interface module. This is what the "shall have exactly one" language in ISO 10206 requires.
What seems to be missing is this variant (no module-block at all), and I'll add it in the next release (that's easy to do):
module fjf843m;
export fjf843m = all;
const OK = 'OK';
end.
I really don't see any need for this variant. It isn't in any way conformant to ISO 10206 requirements and the only "value" of it is to save typing an 'end;'. There are already enough problems with the gaggle of non-compatible, non-standard ISO 7185 based dialect variants so there is no need to create additional problems with non-standard ISO 10206 variants which serves no purpose other than to save typing *four* characters.
I meant that this form *is* according to EP:
: programÂcomponent = mainÂprogramÂdeclaration `.' : | moduleÂdeclaration `.' . : moduleÂdeclaration = moduleÂheading [ `;' moduleÂblock ] : | moduleÂidentification `;' moduleÂblock . : moduleÂheading = `module' identifier [ interfaceÂdirective ] : [ `(' moduleÂparameterÂlist `)' ] `;' : interfaceÂspecificationÂpart : importÂpart : { constantÂdefinitionÂpart : | typeÂdefinitionÂpart : | variableÂdeclarationÂpart : | procedureÂandÂfunctionÂheadingÂpart } : `end' .
Note the optional module-block in the first form of module-declaration. So IIUIC, there are 3 kinds of "module components": module headings with `interface' (aka interface modules), module headings without `interface' and module identifications (aka implementation modules).
However, AFAICS, EP doesn't require to support `interface' modules without implementation. That's good because GPC has to know when compiling a module whether there will be an implementation part (because it has to create the initializer if (and only if) not).
Actually without extensions, EP strictly disallows 'interface' modules without implementation modules. However, as mentioned a while ago in the "Combining .o files?" thread, ISO 10206 suggests in the note to paragraph 6.1.5 that if one wants to implement an extension which allows for a module-interface without a module body the way to do so is with an 'external' interface-directive.
That's something different (I don't want to go into this again, but as I said, I prefer to specify this on a per routine basis, because it's not generally optimal to have everything or nothing external). Here I'm talking about the cases of interfaces without any routines at all (where there's nothing to be external).
It also seems reasonable to me from the programmer's point of view. When you write a module interface, you know whether there has to be an implementation (namely, if there are any routines in the interface or an initializer or finalizer will be needed) or not (only constants, types and variables without need for initialization/finalization). So it makes sense to specify this explicitly (by writing `interface' or not).
This is pretty much what I called a "pure" interface in the "Combining .o files?" thread.
Not quite the same -- (a) see above, (b) that was about initialization; even pure interface modules may need an initialization in GPC (e.g., if they declare file variables which must be initialized internally). The latter would even apply to external modules (if we ever implement them) because it wouldn't be reasonable to expect the external implementation to call the internal GPC initialization routines.
Frank
On Sun, Apr 20, 2003 at 01:11:37PM +0200, Frank Heckenbach wrote:
Gale Paeper wrote:
Frank Heckenbach wrote:
One of the listed bugs of GPC was "modules without implementation".
Where is the bug listed? It isn't listed under "Known bugs in GPC" at < http://www.gnu-pascal.de/gpc/Known-Bugs.html%3E.
However, if I understand EP correctly, this actually doesn't concern `interface' modules (as in pmodtest.pas without the `implementation' part):
If I understand the comment in pmodtest.pas correctly, EP always requires one and exactly one implementation module to be associated with an interface module. Even if the module-block is empty (except for the required 'end'), there still must exist an implementation module to associate with an interface module. This is what the "shall have exactly one" language in ISO 10206 requires.
What seems to be missing is this variant (no module-block at all), and I'll add it in the next release (that's easy to do):
module fjf843m;
export fjf843m = all;
const OK = 'OK';
end.
I really don't see any need for this variant. It isn't in any way conformant to ISO 10206 requirements and the only "value" of it is to save typing an 'end;'. There are already enough problems with the gaggle of non-compatible, non-standard ISO 7185 based dialect variants so there is no need to create additional problems with non-standard ISO 10206 variants which serves no purpose other than to save typing *four* characters.
I meant that this form *is* according to EP:
: programÂcomponent = mainÂprogramÂdeclaration `.' : | moduleÂdeclaration `.' . : moduleÂdeclaration = moduleÂheading [ `;' moduleÂblock ] : | moduleÂidentification `;' moduleÂblock . : moduleÂheading = `module' identifier [ interfaceÂdirective ] : [ `(' moduleÂparameterÂlist `)' ] `;' : interfaceÂspecificationÂpart : importÂpart : { constantÂdefinitionÂpart : | typeÂdefinitionÂpart : | variableÂdeclarationÂpart : | procedureÂandÂfunctionÂheadingÂpart } : `end' .
Note the optional module-block in the first form of module-declaration. So IIUIC, there are 3 kinds of "module components": module headings with `interface' (aka interface modules), module headings without `interface' and module identifications (aka implementation modules).
Maybe I'm missing the point here, but: the second kind of module "components" _must_ include a module block (this doesn't follow from the BNF rules, but from the text of 6.11.1). Hence this is not valid (in EP):
module fjf843m;
export fjf843m = all;
const OK = 'OK';
end.
Emil
Emil Jerabek wrote:
On Sun, Apr 20, 2003 at 01:11:37PM +0200, Frank Heckenbach wrote:
Gale Paeper wrote:
Frank Heckenbach wrote:
One of the listed bugs of GPC was "modules without implementation".
Where is the bug listed? It isn't listed under "Known bugs in GPC" at < http://www.gnu-pascal.de/gpc/Known-Bugs.html%3E.
However, if I understand EP correctly, this actually doesn't concern `interface' modules (as in pmodtest.pas without the `implementation' part):
If I understand the comment in pmodtest.pas correctly, EP always requires one and exactly one implementation module to be associated with an interface module. Even if the module-block is empty (except for the required 'end'), there still must exist an implementation module to associate with an interface module. This is what the "shall have exactly one" language in ISO 10206 requires.
What seems to be missing is this variant (no module-block at all), and I'll add it in the next release (that's easy to do):
module fjf843m;
export fjf843m = all;
const OK = 'OK';
end.
I really don't see any need for this variant. It isn't in any way conformant to ISO 10206 requirements and the only "value" of it is to save typing an 'end;'. There are already enough problems with the gaggle of non-compatible, non-standard ISO 7185 based dialect variants so there is no need to create additional problems with non-standard ISO 10206 variants which serves no purpose other than to save typing *four* characters.
I meant that this form *is* according to EP:
: programÂcomponent = mainÂprogramÂdeclaration `.' : | moduleÂdeclaration `.' . : moduleÂdeclaration = moduleÂheading [ `;' moduleÂblock ] : | moduleÂidentification `;' moduleÂblock . : moduleÂheading = `module' identifier [ interfaceÂdirective ] : [ `(' moduleÂparameterÂlist `)' ] `;' : interfaceÂspecificationÂpart : importÂpart : { constantÂdefinitionÂpart : | typeÂdefinitionÂpart : | variableÂdeclarationÂpart : | procedureÂandÂfunctionÂheadingÂpart } : `end' .
Note the optional module-block in the first form of module-declaration. So IIUIC, there are 3 kinds of "module components": module headings with `interface' (aka interface modules), module headings without `interface' and module identifications (aka implementation modules).
Maybe I'm missing the point here, but: the second kind of module "components" _must_ include a module block (this doesn't follow from the BNF rules, but from the text of 6.11.1).
You mean they write misleading BNF rules, only to clarify them in they unusually clear and understandable "English" description? Great! :-(
No wonder modules never got very popular if even the definition what is a module is so incomprehensible ...
Frank
Frank Heckenbach wrote:
Gale Paeper wrote:
Frank Heckenbach wrote:
What seems to be missing is this variant (no module-block at all), and I'll add it in the next release (that's easy to do):
module fjf843m;
export fjf843m = all;
const OK = 'OK';
end.
I really don't see any need for this variant. It isn't in any way conformant to ISO 10206 requirements and the only "value" of it is to save typing an 'end;'. There are already enough problems with the gaggle of non-compatible, non-standard ISO 7185 based dialect variants so there is no need to create additional problems with non-standard ISO 10206 variants which serves no purpose other than to save typing *four* characters.
I meant that this form *is* according to EP:
Okay, that clarifies that your focus is on ISO 10206 compliance and not on an extension to cover something that is missing from ISO 10206.
If I'm reading ISO 10206 correctly, it isn't a legal code construct.
: programcomponent = mainprogramdeclaration `.' : | moduledeclaration `.' . : moduledeclaration = moduleheading [ `;' moduleblock ] : | moduleidentification `;' moduleblock . : moduleheading = `module' identifier [ interfacedirective ] : [ `(' moduleparameterlist `)' ] `;' : interfacespecificationpart : importpart : { constantdefinitionpart : | typedefinitionpart : | variabledeclarationpart : | procedureandfunctionheadingpart } : `end' .
Note the optional module-block in the first form of module-declaration. So IIUIC, there are 3 kinds of "module components": module headings with `interface' (aka interface modules), module headings without `interface' and module identifications (aka implementation modules).
I think the point of misunderstanding is with "module headings without `interface'". For this case, EP requires a requires a module-block to follow the module-heading.
I think the relevant text from paragraph 6.11.1 is:
"An interface-directive shall occur in a module-heading of a module-declaration if and only if a module-block does not occur in the module-declaration."
From this, it seems pretty clear that if you don't have a module-block in the module-declaration form/pattern you must have an interface-directive. Conversely, if you do have a module-block in the form/pattern you cannot have an interface-directive. Therefore, the missing "(no module-block at all)" variant under discussion cannot be a ISO 10206 legal variant since no module-block dictates the useage of an interface directive in the module-heading.
So, as you allude to, there are three kinds of module-declaration forms/patterns. They are:
1. module-headings with an interface-directive and no module-block (aka interface modules).
2. module-blocks with a module-identification with implementation-directive and no module-heading (aka implementation modules).
3. module-heading without an interface-directive and a module-block (aka fully specified ?? modules).
Paragraph 6.11.1 also states:
"There shall be exactly one module-block associated with a module-heading."
From this, it also seem pretty clear that if you have a module-heading you must have a module-block declared by one of the legal forms to be in compliance with ISO 10206. From the three kinds of module-declaration forms/patterns, there are only two kind combinations which constructs a legal ISO 10206 program-component. One combination is a kind 1 and kind 2 pair. The other combination is a kind 3 by itself.
However, AFAICS, EP doesn't require to support `interface' modules without implementation. That's good because GPC has to know when compiling a module whether there will be an implementation part (because it has to create the initializer if (and only if) not).
Actually without extensions, EP strictly disallows 'interface' modules without implementation modules. However, as mentioned a while ago in the "Combining .o files?" thread, ISO 10206 suggests in the note to paragraph 6.1.5 that if one wants to implement an extension which allows for a module-interface without a module body the way to do so is with an 'external' interface-directive.
That's something different (I don't want to go into this again, but as I said, I prefer to specify this on a per routine basis, because it's not generally optimal to have everything or nothing external). Here I'm talking about the cases of interfaces without any routines at all (where there's nothing to be external).
With the follow-up clarification that it is an ISO compliance issue, I agree it is something different.
Not quite the same -- (a) see above, (b) that was about initialization; even pure interface modules may need an initialization in GPC (e.g., if they declare file variables which must be initialized internally). The latter would even apply to external modules (if we ever implement them) because it wouldn't be reasonable to expect the external implementation to call the internal GPC initialization routines.
As already noted, I agree it isn't the same. Although I do have some comments in regards to (b), I think it would probably be best for both our time useages to defer the discussion until such time a pure interface external module extension ever becomes a GPC implementation priority.
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
Frank Heckenbach wrote:
... snip ...
Okay, that clarifies that your focus is on ISO 10206 compliance and not on an extension to cover something that is missing from ISO 10206.
If I'm reading ISO 10206 correctly, it isn't a legal code construct.
: programÂcomponent = mainÂprogramÂdeclaration `.' : | moduleÂdeclaration `.' . : moduleÂdeclaration = moduleÂheading [ `;' moduleÂblock ] : | moduleÂidentification `;' moduleÂblock . : moduleÂheading = `module' identifier [ interfaceÂdirective ] : [ `(' moduleÂparameterÂlist `)' ] `;' : interfaceÂspecificationÂpart : importÂpart : { constantÂdefinitionÂpart : | typeÂdefinitionÂpart : | variableÂdeclarationÂpart : | procedureÂandÂfunctionÂheadingÂpart } : `end' .
Note the optional module-block in the first form of module-declaration. So IIUIC, there are 3 kinds of "module components": module headings with `interface' (aka interface modules), module headings without `interface' and module identifications (aka implementation modules).
I think the point of misunderstanding is with "module headings without `interface'". For this case, EP requires a requires a module-block to follow the module-heading.
I think the relevant text from paragraph 6.11.1 is:
"An interface-directive shall occur in a module-heading of a module-declaration if and only if a module-block does not occur in the module-declaration."
I should think this sort of discussion would be better suited to comp.lang.pascal.ansi-iso, where some of the originators of the standard might well chime in. It is not peculiar to GPC AFAICT.
Gale Paeper wrote:
If I'm reading ISO 10206 correctly, it isn't a legal code construct.
: programÂcomponent = mainÂprogramÂdeclaration `.' : | moduleÂdeclaration `.' . : moduleÂdeclaration = moduleÂheading [ `;' moduleÂblock ] : | moduleÂidentification `;' moduleÂblock . : moduleÂheading = `module' identifier [ interfaceÂdirective ] : [ `(' moduleÂparameterÂlist `)' ] `;' : interfaceÂspecificationÂpart : importÂpart : { constantÂdefinitionÂpart : | typeÂdefinitionÂpart : | variableÂdeclarationÂpart : | procedureÂandÂfunctionÂheadingÂpart } : `end' .
Note the optional module-block in the first form of module-declaration. So IIUIC, there are 3 kinds of "module components": module headings with `interface' (aka interface modules), module headings without `interface' and module identifications (aka implementation modules).
I think the point of misunderstanding is with "module headings without `interface'". For this case, EP requires a requires a module-block to follow the module-heading.
I think the relevant text from paragraph 6.11.1 is:
"An interface-directive shall occur in a module-heading of a module-declaration if and only if a module-block does not occur in the module-declaration."
From this, it seems pretty clear that if you don't have a module-block
in the module-declaration form/pattern you must have an interface-directive. Conversely, if you do have a module-block in the form/pattern you cannot have an interface-directive. Therefore, the missing "(no module-block at all)" variant under discussion cannot be a ISO 10206 legal variant since no module-block dictates the useage of an interface directive in the module-heading.
So, as you allude to, there are three kinds of module-declaration forms/patterns. They are:
- module-headings with an interface-directive and no module-block (aka
interface modules).
- module-blocks with a module-identification with
implementation-directive and no module-heading (aka implementation modules).
- module-heading without an interface-directive and a module-block
(aka fully specified ?? modules).
Paragraph 6.11.1 also states:
"There shall be exactly one module-block associated with a module-heading."
From this, it also seem pretty clear that if you have a module-heading
you must have a module-block declared by one of the legal forms to be in compliance with ISO 10206. From the three kinds of module-declaration forms/patterns, there are only two kind combinations which constructs a legal ISO 10206 program-component. One combination is a kind 1 and kind 2 pair. The other combination is a kind 3 by itself.
OK, so can we say what they actually mean to say is something like this -- but they chose not to write it clearly in the BNF, but let the BNF accept more and restrict it again in the text(*)?
module-declaration = `module' identifier interface-directive module-interface | `module' identifier module-interface `;' module-block | module-identification `;' module-block .
module-interface = [ `(' module-parameter-list `)' ] `;' interface-specification-part import-part { constant-definition-part | type-definition-part | variable-declaration-part | procedure-and-function-heading-part } `end' .
(*) Bad style IMHO. Of course, a BNF will (almost) always accept more than valid programs (undeclared identifiers etc.), but if it's so easy to rewrite it in a stricter way, this should be done. (Otherwise, why not define a BNF that accepts anything? ;-)
So, I'll forbid this wrong form again. Now GPC will allow 1., 2., 1. and 2. in one source file, 3. and a "GPC specific form" (which may also be PXSC compatible) without any explicit export part.
Frank
Frank Heckenbach wrote:
Gale Paeper wrote:
So, as you allude to, there are three kinds of module-declaration forms/patterns. They are:
- module-headings with an interface-directive and no module-block (aka
interface modules).
- module-blocks with a module-identification with
implementation-directive and no module-heading (aka implementation modules).
- module-heading without an interface-directive and a module-block
(aka fully specified ?? modules).
Paragraph 6.11.1 also states:
"There shall be exactly one module-block associated with a module-heading."
From this, it also seem pretty clear that if you have a module-heading
you must have a module-block declared by one of the legal forms to be in compliance with ISO 10206. From the three kinds of module-declaration forms/patterns, there are only two kind combinations which constructs a legal ISO 10206 program-component. One combination is a kind 1 and kind 2 pair. The other combination is a kind 3 by itself.
OK, so can we say what they actually mean to say is something like this -- but they chose not to write it clearly in the BNF, but let the BNF accept more and restrict it again in the text(*)?
module-declaration = `module' identifier interface-directive module-interface | `module' identifier module-interface `;' module-block | module-identification `;' module-block .
Although it doesn't have any syntactic difference, you could expand the third alternative's module-identification into it's component parts for style consistancy, i.e.,:
'module' identifier implementation-directive ';' module-block .
module-interface = [ `(' module-parameter-list `)' ] `;' interface-specification-part import-part { constant-definition-part | type-definition-part | variable-declaration-part | procedure-and-function-heading-part } `end' .
(*) Bad style IMHO. Of course, a BNF will (almost) always accept more than valid programs (undeclared identifiers etc.), but if it's so easy to rewrite it in a stricter way, this should be done. (Otherwise, why not define a BNF that accepts anything? ;-)
I would speculate that perhaps there were more factors involved than just clarity of syntactic contructs. Some of the syntactic forms are arranged to provide nonterminal names for a semantic entities. Perhaps a need to have a tie to the syntax for the semantic entity module-heading was a factor in reducing the clarity of the modified BNF for module-declaration. The prose describing the semantics is pretty dense already; just imagine what it would be like if there wasn't any convenient handles to associate the semantic prose to the syntax.
So, I'll forbid this wrong form again. Now GPC will allow 1., 2., 1. and 2. in one source file, 3. and a "GPC specific form" (which may also be PXSC compatible) without any explicit export part.
Although I think it would be a major headache to implement, I'll note that for full compliance you can't restrict the number of program-components in a source file nor require any ordering other than the parial ordering of the define-before-use 6.2.2.9 requirement. (I'm just noting the requirement and not suggesting that GPC must fully implement the requirement.)
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
The prose describing the semantics is pretty dense already; just imagine what it would be like if there wasn't any convenient handles to associate the semantic prose to the syntax.
I don't want to go into this too deeply, because it might get rather ugly. If they really cared about a readable language, there are dozens of ways to do so, without affecting the BNF syntax.
So, I'll forbid this wrong form again. Now GPC will allow 1., 2., 1. and 2. in one source file, 3. and a "GPC specific form" (which may also be PXSC compatible) without any explicit export part.
Although I think it would be a major headache to implement, I'll note that for full compliance you can't restrict the number of program-components in a source file nor require any ordering other than the parial ordering of the define-before-use 6.2.2.9 requirement. (I'm just noting the requirement and not suggesting that GPC must fully implement the requirement.)
Where does the standard say anything about source files?
Frank
Is a zero length slice a legitimate structure?
Ie
var s, t: String(10); begin if EQ( s[1..0], t[1..0] ) then begin WriteLn( 'TRUE' ); end; end.
Should that work?
Currently it gives
testpas.pas:6: size of array is too large
however, if the 0 is changed to a runtime variable:
var s, t: String(10); n: Integer; begin n := 0; if EQ( s[1..n], t[1..n] ) then begin WriteLn( 'TRUE' ); end; end.
Then it returns TRUE (as expected, sort of).
Similarly for s := t[1..0]; etc.
So, is it legitimate or not? If it is, the compile error is a bug. If not, then there seems to be a missing runtime range check error (or do I have to enable that)?
Thanks, Peter.
Peter N Lewis wrote:
Is a zero length slice a legitimate structure?
Ie
var s, t: String(10); begin if EQ( s[1..0], t[1..0] ) then begin WriteLn( 'TRUE' ); end; end.
Should that work?
No:
: substringÂvariable = stringÂvariable : `[' indexÂexpression `..' indexÂexpression `]' . : : The indexÂexpressions in a substringÂvariable shall possess the : integerÂtype. It shall be an error if the stringÂvariable of the : substringÂvariable is undefined, or if the value of an indexÂexpression in a : substringÂvariable is less than 1 or greater than the length of the value of : the stringÂvariable of the substringÂvariable, or if the value of the first : indexÂexpression is greater than the value of the second indexÂexpression.
Currently it gives
testpas.pas:6: size of array is too large
Fixed in the next release. (peter2*.pas)
however, if the 0 is changed to a runtime variable:
var s, t: String(10); n: Integer; begin n := 0; if EQ( s[1..n], t[1..n] ) then begin WriteLn( 'TRUE' ); end; end.
Then it returns TRUE (as expected, sort of).
Similarly for s := t[1..0]; etc.
So, is it legitimate or not? If it is, the compile error is a bug. If not, then there seems to be a missing runtime range check error (or do I have to enable that)?
Missing runtime range checks are one of the most well-known issues of GPC (even if not strictly a bug, as long as it's documented).
Frank
-
CBFalconer -
Emil Jerabek -
Frank Heckenbach -
Gale Paeper -
Peter N Lewis