program file attached is a program missing a "}" which should get compilation error, but which compiles without errors and when run, gets a "Segmentation fault" and quits.
tested on GNU Pascal version 20030830, based on gcc-3.3.2
Willett Kempton
On Mon, 20 Dec 2004, willett wrote:
program file attached is a program missing a "}" which should get compilation error, but which compiles without errors and when run, gets a "Segmentation fault" and quits.
compiler saw { { }, he wanted { } { }
found that problem the other day, but since it is not a bug, sat down and wrote a non-distructive tool that might be useful: it checks for matching (* *), { }, [ ], ( ), " ", and ' '
program attached. let me know what you think of it.
Russ
Russell Whitaker wrote:
On Mon, 20 Dec 2004, willett wrote:
program file attached is a program missing a "}" which should get compilation error, but which compiles without errors and when run, gets a "Segmentation fault" and quits.
compiler saw { { }, he wanted { } { }
found that problem the other day, but since it is not a bug, sat down and wrote a non-distructive tool that might be useful: it checks for matching (* *), { }, [ ], ( ), " ", and ' '
All that is required is that the lexical front end detect '{' while absorbing a comment (and possibly '(*' also, depending on whether or not you are allowing mixed comments). I thought that was already in there, in fact. If found, it should emit a warning about possible earlier comment unclosed.
Russ, Frank, Adrian, Waldek, Chuck F.,
Thanks for the info. I should have seen this. My main problem was the "segmentation fault" which I now see was due to using an uninitialized array index. I misread the source error completely. Sorry for the distraction. (But perhaps it led to some useful discussion...)
Willett Kempton
On 21 Dec 2004, at 02:32, Russell Whitaker wrote:
On Mon, 20 Dec 2004, willett wrote:
program file attached is a program missing a "}" which should get compilation error, but which compiles without errors and when run, gets a "Segmentation fault" and quits.
compiler saw { { }, he wanted { } { }
found that problem the other day, but since it is not a bug, sat down and wrote a non-distructive tool that might be useful: it checks for matching (* *), { }, [ ], ( ), " ", and ' '
program attached. let me know what you think of it.
Russ<match.pas>
willett wrote:
program file attached is a program missing a "}" which should get compilation error, but which compiles without errors and when run, gets a "Segmentation fault" and quits.
It compiles fine on my system using 20041218.
As Russ wrote, the program should compile, since in Pascal comments cannot be nested, i.e. the one `}' terminates the comment, even if it contains additional `{'s.
GPC has a non-standard option `--nested-comments', and with this option on, 20041218 reports an "unterminated comment", as it should.
Frank
Frank Heckenbach wrote:
willett wrote:
program file attached is a program missing a "}" which should get compilation error, but which compiles without errors and when run, gets a "Segmentation fault" and quits.
It compiles fine on my system using 20041218.
As Russ wrote, the program should compile, since in Pascal comments cannot be nested, i.e. the one `}' terminates the comment, even if it contains additional `{'s.
In the ISO Pascal Standard Report (Jensen, Wirth, third edition) I read at the end of Section 5:
Comment = { "{" | "(*" ) { CommentElement } ( "}" | "*)" ) .
A CommentElement is either an end of line or any sequence of characters not containing "}" or "*)". Notes: { ...*) and (* ...} are valid comments. The comment {(*) is equivalent to the comment {(}.
This means that {{} is a valid comment, but {}} isn't, according to the standard. Several other Pascal compilers, however, only allow (*.. { .. } .. *) or { .. (* .. *) .. }. But, as Frank noted, you can use the --nested-comments option in GPC to get similar behaviour.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
willett wrote:
program file attached is a program missing a "}" which should get compilation error, but which compiles without errors and when run, gets a "Segmentation fault" and quits.
It compiles fine on my system using 20041218.
As Russ wrote, the program should compile, since in Pascal comments cannot be nested, i.e. the one `}' terminates the comment, even if it contains additional `{'s.
In the ISO Pascal Standard Report (Jensen, Wirth, third edition) I read at the end of Section 5:
Comment = { "{" | "(*" ) { CommentElement } ( "}" | "*)" ) .
A CommentElement is either an end of line or any sequence of characters not containing "}" or "*)".
Notes: { ...*) and (* ...} are valid comments. The comment {(*) is equivalent to the comment {(}.
This means that {{} is a valid comment, but {}} isn't, according to the standard. Several other Pascal compilers, however, only allow (*.. { .. } .. *) or { .. (* .. *) .. }. But, as Frank noted, you can use the --nested-comments option in GPC to get similar behaviour.
This would be `--no-mixed-comments' which is set (i.e. "no") by default, except in standard Pascal modes.
Frank
Frank Heckenbach wrote:
In the ISO Pascal Standard Report (Jensen, Wirth, third edition) I read at the end of Section 5:
Comment = { "{" | "(*" ) { CommentElement } ( "}" | "*)" ) .
A CommentElement is either an end of line or any sequence of characters not containing "}" or "*)".
Notes: { ...*) and (* ...} are valid comments. The comment {(*) is equivalent to the comment {(}.
This means that {{} is a valid comment, but {}} isn't, according to the standard. Several other Pascal compilers, however, only allow (*.. { .. } .. *) or { .. (* .. *) .. }. But, as Frank noted, you can use the --nested-comments option in GPC to get similar behaviour.
This would be `--no-mixed-comments' which is set (i.e. "no") by default, except in standard Pascal modes.
I see. Then --nested-comments --no-mixed-comments would be the ideal default for --mac-pascal.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
In the ISO Pascal Standard Report (Jensen, Wirth, third edition) I read at the end of Section 5:
Comment = { "{" | "(*" ) { CommentElement } ( "}" | "*)" ) .
A CommentElement is either an end of line or any sequence of characters not containing "}" or "*)".
Notes: { ...*) and (* ...} are valid comments. The comment {(*) is equivalent to the comment {(}.
This means that {{} is a valid comment, but {}} isn't, according to the standard. Several other Pascal compilers, however, only allow (*.. { .. } .. *) or { .. (* .. *) .. }. But, as Frank noted, you can use the --nested-comments option in GPC to get similar behaviour.
This would be `--no-mixed-comments' which is set (i.e. "no") by default, except in standard Pascal modes.
I see. Then --nested-comments --no-mixed-comments would be the ideal default for --mac-pascal.
Does Mac Pascal allow real nested comments, i.e. `{ ... { ... } ... }'? (Then it might be the first compiler I hear of that does so, apart from GPC. I had even considered dropping that option, OTOH, it's quite useful for embedding TeX etc. in comments.)
And `--nested-comments --no-mixed-comments' would also mean comments such as `{ ... { ... (* ... } ... }'. Is it so?
Frank
Frank Heckenbach wrote:
... snip ...
Does Mac Pascal allow real nested comments, i.e. `{ ... { ... } ... }'? (Then it might be the first compiler I hear of that does so, apart from GPC. I had even considered dropping that option, OTOH, it's quite useful for embedding TeX etc. in comments.)
And `--nested-comments --no-mixed-comments' would also mean comments such as `{ ... { ... (* ... } ... }'. Is it so?
I am confused as to what you actually have. I consider that there are two forms of comment delimiters, (* comment *) and { comment }. Let's refer to them as star and brace comments. The standard mandated thing is that a star delimiter and a brace delimiter are always interchangeable individually. The other attitude is that the comments are separate beasts, so that (* commment { junk } more *) is a single star comment which happens to include brace characters (and the inverse). Call this nested comments. I don't believe that any system that counts comment opening symbols so as to allow full comment nesting is useful or desireable.
If we are agreed on that then the only thing to discuss is whether, having selected the nested/non-nested formats, the appearance of an open-comment marker in a comment should trigger a warning. It is certainly not an error. I consider the warning should always appear, but others may differ. I would call this warn on possible unclosed comments.
Frank Heckenbach wrote:
Adriaan van Os wrote:
Frank Heckenbach wrote:
In the ISO Pascal Standard Report (Jensen, Wirth, third edition) I read at the end of Section 5:
Comment = { "{" | "(*" ) { CommentElement } ( "}" | "*)" ) .
A CommentElement is either an end of line or any sequence of characters not containing "}" or "*)".
Notes: { ...*) and (* ...} are valid comments. The comment {(*) is equivalent to the comment {(}.
This means that {{} is a valid comment, but {}} isn't, according to the standard. Several other Pascal compilers, however, only allow (*.. { .. } .. *) or { .. (* .. *) .. }. But, as Frank noted, you can use the --nested-comments option in GPC to get similar behaviour.
This would be `--no-mixed-comments' which is set (i.e. "no") by default, except in standard Pascal modes.
I see. Then --nested-comments --no-mixed-comments would be the ideal default for --mac-pascal.
Does Mac Pascal allow real nested comments, i.e. `{ ... { ... } ... }'? (Then it might be the first compiler I hear of that does so, apart from GPC. I had even considered dropping that option, OTOH, it's quite useful for embedding TeX etc. in comments.)
At least according to the documentation, none of the MacPascal dialect compilers allow nested comments in the `{ ... { ... } ... }' form. CodeWarrior Pascal and MPW Pascal compilers support a nest comments Pascal non-standard extension but you must use different comment delimiters for nesting; e.g. '{ ... (* ... *) ... }'. THINK Pascal doesn't support nested comments and it isn't completely ISO compliant in allowing different syntax forms for beginning and ending comment delimiters - only '{ ... }' and '(* ... *)' are doucmented to be accepted comments. (As an aside, there is a THINK Pascal add-on tool which provides the sort of capability nested comments are intended to provide. Basicly, it is just a bulk text editor which modifies blocks of program text with specific character formatting markups to indicate the level of commenting out - no non-standard extensions required since it is just a markup convention employed inside "regular" comment delimiters which the add-on tool assists with using the convention.)
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
At least according to the documentation, none of the MacPascal dialect compilers allow nested comments in the `{ ... { ... } ... }' form. CodeWarrior Pascal and MPW Pascal compilers support a nest comments Pascal non-standard extension but you must use different comment delimiters for nesting; e.g. '{ ... (* ... *) ... }'.
Are these really nested comments, or are `(*' and `*)' just ignored within a `{ ... }' comment? In the latter case, also `{ (* }' and `{ *) }' would be comments. This (requiring matching delimiters) would be the behaviour of most compilers I've seen (including GPC in non-standard modes).
(As an aside, there is a THINK Pascal add-on tool which provides the sort of capability nested comments are intended to provide. Basicly, it is just a bulk text editor which modifies blocks of program text with specific character formatting markups to indicate the level of commenting out - no non-standard extensions required since it is just a markup convention employed inside "regular" comment delimiters which the add-on tool assists with using the convention.)
That's really something different. As I wrote, the main usefulness of real nested comments to me is to be able to embed formatted text that uses those characters itself, e.g. TeX code (to describe mathematical routines), or the description of regular expressions in the RegEx unit.
CBFalconer wrote:
The other attitude is that the comments are separate beasts, so that (* commment { junk } more *) is a single star comment which happens to include brace characters (and the inverse). Call this nested comments.
I call these non-mixed comments (or more precisely, comments without mixed forms of delimiters). As you wrote, the `{' and `}' in your example are considered ordinary comment characters, not comment delimiters, so it isn't suitable to speak of `{ junk }' as a nested comment; it's just a sequence of ordinary comment characters. (The practical difference is, as above, that non-matching `{'/`}'s are accepted here, unlike with real nested comments.
I don't believe that any system that counts comment opening symbols so as to allow full comment nesting is useful or desireable.
Feel free not to use it. (`--nested-comments' is not the default is GPC, of course.)
If we are agreed on that then the only thing to discuss is whether, having selected the nested/non-nested formats, the appearance of an open-comment marker in a comment should trigger a warning. It is certainly not an error. I consider the warning should always appear, but others may differ. I would call this warn on possible unclosed comments.
I think a warning could be useful, but not always on, i.e. another option. I wouldn't mind if it's on by default. Maybe even in standard modes (though this construct is standard-compliant, we do warn about other standard-compliant constructs, such as unused variables.)
Frank
Frank Heckenbach wrote:
If we are agreed on that then the only thing to discuss is whether, having selected the nested/non-nested formats, the appearance of an open-comment marker in a comment should trigger a warning. It is certainly not an error. I consider the warning should always appear, but others may differ. I would call this warn on possible unclosed comments.
I think a warning could be useful, but not always on, i.e. another option. I wouldn't mind if it's on by default. Maybe even in standard modes (though this construct is standard-compliant, we do warn about other standard-compliant constructs, such as unused variables.)
There is one tricky point, though. Consider:
(* (*)
This is a valid comment, contaning ` ('. However `(*' *looks* like a nested comment-opener. Generally this should be warned for, but not here, because the `*' is (must be!) actually part of the `*)'.
I hope I'll manage to explain this to our lexer ... (-; but I think so -- in the end it's all regex, just a little more complex).
Frank
Frank Heckenbach wrote:
... snip ...
There is one tricky point, though. Consider:
(* (*)
This is a valid comment, contaning ` ('. However `(*' *looks* like a nested comment-opener. Generally this should be warned for, but not here, because the `*' is (must be!) actually part of the `*)'.
I hope I'll manage to explain this to our lexer ... (-; but I think so -- in the end it's all regex, just a little more complex).
I don't think there is any need to explain it. These are not errors, simply warnings. By definition, it is impossible to make an error within a comment. In this case the verbiage might be: "Possible unclosed earlier comment". If it offends someone you have provided an input parameter to suppress it.
On Wed, 5 Jan 2005, CBFalconer wrote:
Frank Heckenbach wrote:
.. snip ...
There is one tricky point, though. Consider:
(* (*)
If you were reading a long program and that first (* was quite a number of lines back and you read: foo (*) Is it: foo (* ) foo( *) or foo(*)
I think a little whitespace would be a reasonable requiremnet. my .02
Russ
Russell Whitaker wrote:
On Wed, 5 Jan 2005, CBFalconer wrote:
Frank Heckenbach wrote:
.. snip ...
There is one tricky point, though. Consider:
(* (*)
If you were reading a long program and that first (* was quite a number of lines back and you read: foo (*) Is it: foo (* ) foo( *) or foo(*)
I think a little whitespace would be a reasonable requiremnet. my .02
It would be perhaps, but according to the standards, there is no such requirement.
When writing code, I'd surely recommend to put in the whitespace, but the compiler has to cope with anything ...
Frank
I wrote:
CBFalconer wrote:
If we are agreed on that then the only thing to discuss is whether, having selected the nested/non-nested formats, the appearance of an open-comment marker in a comment should trigger a warning. It is certainly not an error. I consider the warning should always appear, but others may differ. I would call this warn on possible unclosed comments.
I think a warning could be useful, but not always on, i.e. another option. I wouldn't mind if it's on by default. Maybe even in standard modes (though this construct is standard-compliant, we do warn about other standard-compliant constructs, such as unused variables.)
I think we can neatly reuse existing options. `-Wnested-comments' and `--nested-comments' give us 4 combinations which cover just the cases anyone might prefer.
Consider the input `{ { }'.
-Wno-nested-comments --no-nested-comments
nothing, regular comment
(This is the default and standard-conformant.)
-Wnested-comments --no-nested-comments
warning: comment opener found within comment
(This is what Chuck suggests. I'm implementing this in the next release.)
-Wno-nested-comments --nested-comments
unterminated comment
(GPC extension)
-Wnested-comments --nested-comments
warning: nested comments are a GPC extension
unterminated comment
(GPC extension plus warning when it's used)
Note that `-Wnested-comments' has a slightly different meaning with and without `--nested-comments', but actually not too different since the situations where the warning appears are exactly the same in both cases, so I think it's better this way than adding another option.
Frank
Frank Heckenbach wrote:
Gale Paeper wrote:
At least according to the documentation, none of the MacPascal dialect compilers allow nested comments in the `{ ... { ... } ... }' form. CodeWarrior Pascal and MPW Pascal compilers support a nest comments Pascal non-standard extension but you must use different comment delimiters for nesting; e.g. '{ ... (* ... *) ... }'.
Are these really nested comments, or are `(*' and `*)' just ignored within a `{ ... }' comment? In the latter case, also `{ (* }' and `{ *) }' would be comments. This (requiring matching delimiters) would be the behaviour of most compilers I've seen (including GPC in non-standard modes).
After some quickie blackbox compiler behavior checking, it doesn't appear that any of the MacPascal dialect compilers support what would be true nested comments although the documentation uses the term "nested" to describe the supported comment forms. What testing indicates is implemented in CodeWarrior Pascal, MPW Pascal, and THINK Pascal compilers is (to use THINK Pascal's documentation description):
{ Any text not containing right-brace } (* Any text not containing star-right-paren *)
which, if I've understood your comment correctly, is another way of describing your "latter case". The begin-comment and end-comment delimiters must use the same comment style form to form a legal closed comment.
In case it helps in understanding, some of the constructs tested which formed accepted/legal comments:
{ (* } { *) }
and unaccepted/illegal constructs with problem notations:
{ ... (* ... { ... } ... *) ... } illegal - error after first '}' { ... (* ... } ... *) illegal - error after '}' { ... *) Non-matching begin-comment and end-comment delimiters don't form a closed comment { ... (* ... *) ... *) Non-matching begin-comment and end-comment delimiters don't form a closed comment
Note: For the unaccepted/illegal constructs, errors were reported. However, the reported errors weren't indicative of a malformed comment - just some sort of non-comment related illegal program construct. For example, the last two unclosed comment test cases resulted in illegal statement errors at the end of the file for the simple test program I was using.
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
Frank Heckenbach wrote:
Gale Paeper wrote:
At least according to the documentation, none of the MacPascal dialect compilers allow nested comments in the `{ ... { ... } ... }' form. CodeWarrior Pascal and MPW Pascal compilers support a nest comments Pascal non-standard extension but you must use different comment delimiters for nesting; e.g. '{ ... (* ... *) ... }'.
Are these really nested comments, or are `(*' and `*)' just ignored within a `{ ... }' comment? In the latter case, also `{ (* }' and `{ *) }' would be comments. This (requiring matching delimiters) would be the behaviour of most compilers I've seen (including GPC in non-standard modes).
After some quickie blackbox compiler behavior checking, it doesn't appear that any of the MacPascal dialect compilers support what would be true nested comments although the documentation uses the term "nested" to describe the supported comment forms.
So did GPC some years ago for "non-mixed comments", but for the reasons I gave, I think speaking of nested comments here is really misleading.
What testing indicates is implemented in CodeWarrior Pascal, MPW Pascal, and THINK Pascal compilers is (to use THINK Pascal's documentation description):
{ Any text not containing right-brace } (* Any text not containing star-right-paren *)
which, if I've understood your comment correctly, is another way of describing your "latter case".
Yes, i.e. non-mixed, non-nested comments, in GPC's option naming.
{ ... (* ... { ... } ... *) ... } illegal - error after first '}' { ... (* ... } ... *) illegal - error after '}' { ... *) Non-matching begin-comment and end-comment delimiters don't form a closed comment { ... (* ... *) ... *) Non-matching begin-comment and end-comment delimiters don't form a closed comment
Note: For the unaccepted/illegal constructs, errors were reported. However, the reported errors weren't indicative of a malformed comment - just some sort of non-comment related illegal program construct. For example, the last two unclosed comment test cases resulted in illegal statement errors at the end of the file for the simple test program I was using.
GPC says "unterminated comment" here. Otherwise, its behaviour in default as well as `--mac-pascal' modes is just as you describe, AFAICS.
Frank
Willett Kempton wrote:
program file attached is a program missing a "}" which should get compilation error, but which compiles without errors and when run, gets a "Segmentation fault" and quits.
tested on GNU Pascal version 20030830, based on gcc-3.3.2
Form your program:
begin { LoadTranFunctions NextT := -MaxInputFields; LoadOne(1,TFCopy,PropSentinel); { put first names into workspace (PropSentinal=workspace } ^^^^ comment ends here.
Gpc treats anything from opening brace to closed brace as a comment (it _may_ contain another opening brace). That behaviour is mandated by the Pascal standard.
Use `--nested-comments' option to require balanced braces in the comment.
-
Adriaan van Os -
CBFalconer -
Frank Heckenbach -
Gale Paeper -
Russell Whitaker -
Waldek Hebisch -
willett