I am using gpc 20010924 with gcc 2.95.3 on UnixWare 7.1 and the following code does not work.
Program Test(Input, Output);
Type Str10 = String(10); LetterType = (AA, BB, CC, DD); MyRec = record LetterName: Array[LetterType] of Str10; end; procedure SetIt(var aStr1: String; const aStr2: String); begin aStr1:=aStr2; end;
var ThisLetter: LetterType; ThisRec: MyRec;
begin for ThisLetter:=AA to DD do SetIt(ThisRec.LetterName[ThisLetter], Chr(Ord(ThisLetter)+Ord('A'))); for ThisLetter:=AA to DD do WriteLn(ThisRec.letterName[ThisLetter]); for ThisLetter:=AA to DD do ThisRec.LetterName[ThisLetter]:=Chr(Ord(ThisLetter)+Ord('A')); for ThisLetter:=AA to DD do WriteLn(ThisRec.LetterName[ThisLetter]); end.
The first set of WriteLn commands prints out A and B and then spaces. The second set prints out A to D as expected.
Theo Carr-Brion
Theo Carr-Brion wrote:
I am using gpc 20010924 with gcc 2.95.3 on UnixWare 7.1 and the following code does not work.
Program Test(Input, Output);
Type Str10 = String(10); LetterType = (AA, BB, CC, DD); MyRec = record LetterName: Array[LetterType] of Str10; end; procedure SetIt(var aStr1: String; const aStr2: String); begin aStr1:=aStr2; end;
var ThisLetter: LetterType; ThisRec: MyRec;
begin for ThisLetter:=AA to DD do SetIt(ThisRec.LetterName[ThisLetter], Chr(Ord(ThisLetter)+Ord('A')));
^^^ I don't know just what a str10 or a string is (apart from an extension), but this is not one, this is a character. The question is why didn't the compiler refuse this faulty procedure call?
for ThisLetter:=AA to DD do WriteLn(ThisRec.letterName[ThisLetter]); for ThisLetter:=AA to DD do ThisRec.LetterName[ThisLetter]:=Chr(Ord(ThisLetter)+Ord('A'));
^^^ Same thing here.
for ThisLetter:=AA to DD do WriteLn(ThisRec.LetterName[ThisLetter]); end.
The first set of WriteLn commands prints out A and B and then spaces. The second set prints out A to D as expected.
On 11 Oct 2001, at 12:47, CBFalconer wrote:
I don't know just what a str10 or a string is (apart from an extension), but this is not one, this is a character. The question is why didn't the compiler refuse this faulty procedure call?
I don't have the EP reference handy, but the "strings" section of the GPC manual at:
http://agnes.dida.physik.uni-essen.de/~gnu-pascal/gpc_142.html#SEC142
says that, "...'String' and 'Char' are assignment compatible." As far as I can recall, that's true in the EP standard as well, i.e., a char is treated as a string of length one for purposes of assignment to a string variable.
-- Dave
On 11 Oct 2001, at 16:40, Theo Carr-Brion wrote:
I am using gpc 20010924 with gcc 2.95.3 on UnixWare 7.1 and the following code does not work.
It fails on gpc 20010604 as well.
The following modification to your program illustrates the source of the error:
Program Test2(Output);
Type Str10 = String(10); LetterType = (AA, BB, CC, DD); MyRec = record LetterName: Array[LetterType] of Str10; end;
var ThisLetter: LetterType; ThisRec: MyRec;
begin for ThisLetter:=AA to DD do writeln (ThisRec.LetterName[ThisLetter].Capacity); end.
The problem is that "Capacity" is not being set for all four strings during program initialization (the type "String" is a schema consisting of "Capacity" -- the maximum length of the string, "Length" -- the current length of the string, and the actual characters themselves). To avoid overrunning the target string, the string assignment in the "SetIt" procedure assigns the shorter of the source string length and the target string capacity. As the target string capacity is not being set for the third and fourth strings in the array, their capacities are defaulting to zero. Therefore, the third and fourth string assignments are failing.
(For the string assignments in the body of the program, GPC does not generate a string length check, presumably because both the target string capacity and the source string length are known at compile time.)
Here is the relevant code generated by GPC (with -O2 -S):
_init_pascal_main_program:
[...]
xorl %edx,%edx movl $_Thisrec,%ecx jmp L12 .p2align 4,,7 L15: incl %edx L12: leal (%edx,%edx,4),%eax movl $10,(%ecx,%eax,4) testb %dl,%dl je L15
The "movl $10, ..." is correctly setting the string capacities to 10, but the statement is only being executed twice, rather than four times. It appears to me that the last two statements above should be:
cmpb $3,%dl jne L15
-- Dave
J. David Bryan wrote:
On 11 Oct 2001, at 16:40, Theo Carr-Brion wrote:
I am using gpc 20010924 with gcc 2.95.3 on UnixWare 7.1 and the following code does not work.
It fails on gpc 20010604 as well.
The following modification to your program illustrates the source of the error:
Program Test2(Output);
Type Str10 = String(10); LetterType = (AA, BB, CC, DD); MyRec = record LetterName: Array[LetterType] of Str10; end;
var ThisLetter: LetterType; ThisRec: MyRec;
begin for ThisLetter:=AA to DD do writeln (ThisRec.LetterName[ThisLetter].Capacity); end.
The problem is that "Capacity" is not being set for all four strings during program initialization (the type "String" is a schema consisting of "Capacity" -- the maximum length of the string, "Length" -- the current length of the string, and the actual characters themselves). To avoid overrunning the target string, the string assignment in the "SetIt" procedure assigns the shorter of the source string length and the target string capacity. As the target string capacity is not being set for the third and fourth strings in the array, their capacities are defaulting to zero. Therefore, the third and fourth string assignments are failing.
Theo Carr-Brion wrote:
The problem seems to be a general one with variables of Array[AType] of String(Capacity) which we use quite a lot. The capacity of the string if not always set. Sometimes it works and sometimes it does not and I can't find the pattern. Setting the capacity of each string in the program gets round the problem.
I think I found and fixed the problem (will be uploaded soon). It was a blatant type error inside GPC, so it's no wonder that it seemed to occur quite irregular. (theo1[ab].pas)
Frank
Theo Carr-Brion wrote:
I am using gpc 20010924 with gcc 2.95.3 on UnixWare 7.1 and the following code does not work.
... snip ...
Being annoyed with this, I also found that gpc 2.95.3 under DJGPP finds no fault with it. I then passed the source through PascalP, after making some declaration changes for str10 and string, and removing the "const" in the function parameter declaration. The resultant listing follows (and will be seriously troubled by line wrap)
2001 Oct 11 13:46 PASCAL-P Universal Compiler Ver. 3.1.9T
1000 0:d Program Test(Input, Output); 2000 0:d 3000 0:d Type 4000 0:d Str10 = ARRAY[1..10] OF char; (*String(10);*) 5000 0:d string = ARRAY[1..80] OF char; 6000 0:d 7000 0:d LetterType = (AA, BB, CC, DD); 8000 0:d MyRec = record 9000 0:d LetterName: Array[LetterType] of Str10; 10000 0:d end; 11000 0:d procedure SetIt(var aStr1: String; { const} aStr2: String); 12000 0:d begin 13000 0: 2 aStr1:=aStr2; 14000 12: 2 end; 15000 17: 2 16000 17: 2 var **** ^17 17. Error in declaration part 17000 0:d ThisLetter: LetterType; 18000 2:d ThisRec: MyRec; 19000 42:d 20000 42:d begin 21000 0: 1 for ThisLetter:=AA to DD do 22000 21: 2 SetIt(ThisRec.LetterName[ThisLetter], Chr(Ord(ThisLetter)+Ord('A'))); **** ^68 ^109,68 68. Illegal parameter substitution
109. Attempt to load the address of an expression 23000 60: 1 for ThisLetter:=AA to DD do 24000 76: 2 WriteLn(ThisRec.letterName[ThisLetter]); 25000 118: 1 for ThisLetter:=AA to DD do 26000 134: 2 ThisRec.LetterName[ThisLetter]:=Chr(Ord(ThisLetter)+Ord('A'));
**** ^55 55. Operand type conflict 27000 169: 1 for ThisLetter:=AA to DD do 28000 185: 2 WriteLn(ThisRec.LetterName[ThisLetter]); 29000 227: 1 end.
NO. ERRORS=5 WARNINGS=0 Program size(pcode bytes)=249
PascalP is fairly stringent. My question is: why does GPC fail to pick up these errors? Do I have to do some configuration to get it conformant?
On 11 Oct 2001, at 14:17, CBFalconer wrote:
PascalP is fairly stringent.
To which Pascal standard? There are several.
My question is: why does GPC fail to pick up these errors?
Because it's not an error in "GNU Pascal," which is what GPC compiles by default.
Do I have to do some configuration to get it conformant?
Try "gpc -c --standard-pascal test.pas" for conformance with ISO-7185.
See:
http://agnes.dida.physik.uni-essen.de/~gnu-pascal/gpc_101.html#SEC101
for additional "conformance" options.
-- Dave
"J. David Bryan" wrote:
On 11 Oct 2001, at 14:17, CBFalconer wrote:
PascalP is fairly stringent.
To which Pascal standard? There are several.
ISO level 0. I thrashed it with the validation suite almost 20 years ago. Now I no longer have the suite, and can't seem to get it without heavy fees. It has failings about procedures as parameters and gotos out of procedures (not implemented).
My question is: why does GPC fail to pick up these errors?
Because it's not an error in "GNU Pascal," which is what GPC compiles by default.
Do I have to do some configuration to get it conformant?
Try "gpc -c --standard-pascal test.pas" for conformance with ISO-7185.
See:
http://agnes.dida.physik.uni-essen.de/~gnu-pascal/gpc_101.html#SEC101
for additional "conformance" options.
Will do, when on line later.
Tried that command, with the following (after the string declaration changes I posted before)
[1] c:\dnld\scratch>gpc -c --standard-pascal test.p test.p: In procedure `Setit': test.p:14: warning: ISO Pascal requires `packed' for fixed strings test.p:14: warning: ISO Pascal requires `packed' for fixed strings test.p: In main program: test.p:23: type mismatch in argument 1 of `Setit' test.p:25: warning: ISO Pascal requires `packed' for fixed strings test.p:29: warning: ISO Pascal requires `packed' for fixed strings
while the equivalent PascalP (lines edited for email wrap)
[1] c:\dnld\scratch>pascalp test.p PASCALP (pasctext, pasclist, prr, ef, output) [parm] V 3.1.9T 17000 0:d var **** ^17 17. Error in declaration part 23000 60: 1 SetIt(ThisRec.LetterName[ThisLetter], **** ^68 ^109,68 68. Illegal parameter substitution 109. Attempt to load the address of an expression 27000 169: 1 ThisRec.LetterName[ThisLetter]:=Chr(Ord(... **** ^55 55. Operand type conflict
NO. ERRORS=5 WARNINGS=0 Program size(pcode bytes)=249
I want to configure it (new at this package) so it picks up all non-standard stuff by default. I don't want Extended Pascal nor Object Pascal compliance, and certainly not Borland (unless I tell it so explicitly). I did something in rhide, but it doesn't seem to stick, nor does it carry over to command line use. Level 1 compliance is fine.
Does it read an environment variable for defaults, perchance?
Just the fact that this thread ever started is worrysome. I could see it in C, but Pascal is supposed to prevent such things.
On 11 Oct 2001, at 18:59, CBFalconer wrote:
ISO level 0.
You may wish to use "--standard-pascal-level-0" in preference to "--standard-pascal" (the latter is level 1, i.e., with conformant arrays).
Will do, when on line later.
Note that the manual should have been built (or included) locally in some form or another as part of your GPC installation.
Tried that command, with the following (after the string declaration changes I posted before)
I believe that generally it would be most helpful to the GPC maintainers if you could separate into the smallest complete programs each of the missed syntax errors you noted (i.e., create the smallest possible test case for each reported problem). For example, the first error appears to be caused by an out-of-order declaration, so:
program t1;
procedure p; begin end;
var x: integer;
begin end.
...should do it. Your help in improving the quality of GPC will be appreciated.
I want to configure it (new at this package) so it picks up all non-standard stuff by default.
I am unfamiliar with RHIDE, so I cannot comment on that part.
The cleanest way to default GPC to one particular standard would have been to modify the "specs" file, specifically, the "*gpc1" entry. I say "would have been" because although GPC correctly reads the specs file and processes most of the entries found therein, no substitution is performed for the "*gpc1" spec, even though a substitution parameter is defined for this purpose.
I have a patch for "lang-specs.h" at home, which I've been using for this purpose. I'll send it to the list this weekend.
In the absence of proper specs processing, creating a command file that runs GPC with the desired language specification switch is a reasonable workaround.
Just the fact that this thread ever started is worrysome. I could see it in C, but Pascal is supposed to prevent such things.
I'm not certain that I understand your point here. The original poster correctly identified a bug in the compiler, and the test case provided was legal "GNU Pascal" (and legal Extended Pascal too). What specifically is worrisome about this bug report?
-- Dave
"J. David Bryan" wrote:
On 11 Oct 2001, at 18:59, CBFalconer wrote:
... snip ...
I believe that generally it would be most helpful to the GPC maintainers if you could separate into the smallest complete programs each of the missed syntax errors you noted (i.e., create the smallest possible test case for each reported problem). For example, the first error appears to be caused by an out-of-order declaration, so:
program t1;
procedure p; begin end; var x: integer;begin end.
...should do it. Your help in improving the quality of GPC will be appreciated.
Your sample above has two faults. It should specify at least (output) in the command line, and it has the illegal declaration portion. Both of which are minor, but contrary to strict standards. PascalP has a flag to allow some of the out-of-order declarations. So:
PROGRAM testnn1;
BEGIN writeln('Testnn fails to detect lack of output file parameter'); (* here is needed a way to return a status *) (* which is missing from ISO Pascal *) (* PascalP uses "terminate(integer)" extension *) END.
PROGRAM testnn2(output);
CONST a = 1;
TYPE b = integer;
CONST c = 2;
BEGIN writeln('Failure to detect misordered declarations'); END.
and variations on the above. There should be a numbering scheme tying the tests to sections in the standard (which I don't have anymore) and to identify the standard involved. You seem to have multiple levels, 0, 1, extended, and others which have no published standard.
One that I put up on pascal.misc a while ago:
PROGRAM testnn3(output);
CONST mini = 32765; maxi = 32767;
TYPE ix = mini..maxi;
VAR i : ix;
BEGIN FOR i := mini TO 32770 DO write(i : 8); writeln; writeln('Failed to detect out of range index'); writeln('Should probably fail at compile time'); END.
and another oldie is a for loop up to maxint
FOR i :- maxint-5 TO maxint DO write(i : 10);
which becomes an infinite loop on some systems.
I can prepare a few sample tests after I get more familiar with the package.
How do I turn on range-checking? It appears to be missing by default, and a search of the manual via 'info' turns up nothing.
I got the command line version to default by running it through an alias. rhide doesn't seem to call it through the command processor, so this doesn't affect it, and so far I have found no way to set that default.
I get the impression that GPC encompasses the full GCC functionality. Is this correct? Is the idea to eventually include it in GCC rather than as a separate package.
The cleanest way to default GPC to one particular standard would have been to modify the "specs" file, specifically, the "*gpc1" entry. I say "would have been" because although GPC correctly reads the specs file and processes most of the entries found therein, no substitution is performed for the "*gpc1" spec, even though a substitution parameter is defined for this purpose.
I have a patch for "lang-specs.h" at home, which I've been using for this purpose. I'll send it to the list this weekend.
Does that involve recompiling GPC - it sounds it and I am not really prepared to do that under DJGPP. I am operating on 7 year old hardware, and the CDROM is flakey, so I have not found a way to mount Linux yet.
Just the fact that this thread ever started is worrysome. I could see it in C, but Pascal is supposed to prevent such things.
I'm not certain that I understand your point here. The original poster correctly identified a bug in the compiler, and the test case provided was legal "GNU Pascal" (and legal Extended Pascal too). What specifically is worrisome about this bug report?
I really meant this sub-thread. Bug is one thing, but the fact that, even with the standard flag, it fails to flag various errors is my concern. Where is your test suite available?
I have persuaded Netscape to isolate the gpc list traffic, however replies do not default to the list, but to the originator. I assume traffic such as this should go through the list.
On 12 Oct 2001, at 14:38, CBFalconer wrote:
Your sample above has two faults. It should specify at least (output) in the command line....
I beg to differ. The ISO 7185 Pascal Standard, section 6.10, "Programs," lists the following syntax for the program heading:
program-heading = 'program' identifer [ '(' program-parameter-list ')' ] .
Note that the parenthesized program-parameter-list (e.g., "(output)") is syntactically optional. It is semantically required if the program contains implicit references to "output" (e.g., a "writeln" statement that does not explicitly specify a file variable), but my example did not.
Both of which are minor, but contrary to strict standards.
Minor or not, errors should be flagged in compliance with the standard selected during compilation.
You seem to have multiple levels, 0, 1, extended, and others which have no published standard.
First, a clarification. It is not "my" compiler. I'm just a casual user with an interest in standards-compliant Pascal (specifically, Extended Pascal, ISO 10206) who offers an occasional suggestion to the group.
Otherwise, your statement is correct.
How do I turn on range-checking?
To my knowledge, that is still on the "To Do" list. See the section entitled "Planned features: Misc.", sixth bulleted item.
I get the impression that GPC encompasses the full GCC functionality. Is this correct?
I am not sure what is meant by "the full GCC functionality." GPC does use the GCC back end and therefore may take advantage of the optimizer, output formats, etc. provided therein.
Is the idea to eventually include it in GCC rather than as a separate package.
I will defer that question to one of the primary maintainers, as I am not qualified to answer it.
Does that involve recompiling GPC - it sounds it and I am not really prepared to do that under DJGPP.
It does, but my intent was to make it available for inclusion in GPC, so that a future pre-built binary would include that capability.
Bug is one thing, but the fact that, even with the standard flag, it fails to flag various errors is my concern.
Well, that's a bug too. I'm sure the intent is to reject everything that does not strictly comply with the selected standard. If GPC doesn't, then it's a bug.
Where is your test suite available?
Again, I must defer to the primary maintainers for an authoritative answer, but I believe that the 2200-plus files that appear in the "test" directory of the source distribution constitute the test suite.
...replies do not default to the list, but to the originator. I assume traffic such as this should go through the list.
The list owner has rather strong views regarding whether the reply address should default to the originator or to the list. I happen to disagree with him on this matter :-), but, in any case, replies should indeed go to the list. (No need to copy me separately, as I read the list. :-)
-- Dave
"J. David Bryan" wrote:
On 12 Oct 2001, at 14:38, CBFalconer wrote:
Your sample above has two faults. It should specify at least (output) in the command line....
I beg to differ. The ISO 7185 Pascal Standard, section 6.10, "Programs," lists the following syntax for the program heading:
program-heading = 'program' identifer [ '(' program-parameter-list ')' ] .
Note that the parenthesized program-parameter-list (e.g., "(output)") is syntactically optional. It is semantically required if the program contains implicit references to "output" (e.g., a "writeln" statement that does not explicitly specify a file variable), but my example did not.
My contention is that output is *ALWAYS* implicitly used, in order to report range errors, etc. I definitely remember that this was included in the original test suite.
... snip ...
How do I turn on range-checking?
To my knowledge, that is still on the "To Do" list. See the section entitled "Planned features: Misc.", sixth bulleted item.
Horrors. I consider that fundamental. Grafting it in after the fact will be a virtually impossible job, IMO. Depends on how the system is built. I believe it was Urs Amman who wrote an important paper on checking, showing how taking advantage of known ranges etc. can reduce the overhead drastically.
I get the impression that GPC encompasses the full GCC functionality. Is this correct?
I am not sure what is meant by "the full GCC functionality." GPC does use the GCC back end and therefore may take advantage of the optimizer, output formats, etc. provided therein.
I thought I read that it would compile c, cpp, etc source if the source files carried those extensions. That seems to be taken over from GCC, so I assumed that the system was built on top of the existing GCC, including its front end.
... snip ...
Bug is one thing, but the fact that, even with the standard flag, it fails to flag various errors is my concern.
Well, that's a bug too. I'm sure the intent is to reject everything that does not strictly comply with the selected standard. If GPC doesn't, then it's a bug.
Where is your test suite available?
Again, I must defer to the primary maintainers for an authoritative answer, but I believe that the 2200-plus files that appear in the "test" directory of the source distribution constitute the test suite.
Sorry, I had the impression that you were one of those. Is development moribund? I seem to see no sign of developers other than Frank Hackenbach here.
On 13 Oct 2001, at 6:45, CBFalconer wrote:
My contention is that output is *ALWAYS* implicitly used, in order to report range errors, etc.
I don't see where that contention is supported by the ISO 7185 standard. Clearly, if the program-parameter-list is optional, it cannot be always required, else it would not be optional. Can you cite a statement from the standard to support your conclusion? The ISO standard is available from:
http://www.pascal-central.com/standards.html
...if you don't have a copy handy.
Moreover, one of the examples that accompanies section 6.10 of the ISO standard is:
program copy (f, g); var f, g : file of real; begin reset(f); rewrite(g); while not eof(f) do begin g^ := f^; get(f); put(g) end end.
Nary an "output" in sight (although examples are not normative).
I definitely remember that this was included in the original test suite.
"The original test suite" of what?
Horrors. I consider that fundamental.
Be welcome to contribute a fix. ;-) Seriously, that is the one certain way of ensuring that GPC has the feature support that you want. (As an aside, I happen to agree that range checking is important, though not as fundamental as ensuring that syntactic requirements are enforced strictly in standards-compliant modes.)
I thought I read that it would compile c, cpp, etc source if the source files carried those extensions.
A GPC build from source does create a C compiler as a side-effect of the process. However, C libraries and headers are not included in the GPC source distribution, so its utility is limited. C++ is not included.
Sorry, I had the impression that you were one of those.
I appreciate the compliment, but I'm just one of the 200 or so names listed as the "other contributors" on the "Contributors to GPC" page of the manual.
Is development moribund?
I wouldn't say so. If you look at the "ChangeLog" for the source code, you will find multiple changes made in for each of the past months of this year. A peek at the CVS snapshots directory:
ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/
...also shows quite a number of releases in 2001.
-- Dave
On 13 Oct 2001, at 6:45, CBFalconer wrote:
My contention is that output is *ALWAYS* implicitly used, in order to report range errors, etc.
I don't see where that contention is supported by the ISO 7185 standard. Clearly, if the program-parameter-list is optional, it cannot be always required, else it would not be optional. Can you cite a statement from the standard to support your conclusion? The ISO standard is available from:
I think that CB's statement is only true for commandline systems. It could be different on some OSes where rangecheck errors are passed to the critical errorhandler of the os. The output then goes via the OSes output system.
I'm replying to several mails at once ...
Marco van de Voort wrote:
On 13 Oct 2001, at 6:45, CBFalconer wrote:
My contention is that output is *ALWAYS* implicitly used, in order to report range errors, etc.
I don't see where that contention is supported by the ISO 7185 standard. Clearly, if the program-parameter-list is optional, it cannot be always required, else it would not be optional. Can you cite a statement from the standard to support your conclusion? The ISO standard is available from:
I think that CB's statement is only true for commandline systems. It could be different on some OSes where rangecheck errors are passed to the critical errorhandler of the os. The output then goes via the OSes output system.
Though we could argue about whether an error handler should be provided by the OS (I don't think so), that's quite OT here. In any case, AFAIK, it's up to the compiler implementation how to report runtime errors, therefore requiring Output to be mentioned for those implementations that write errors to Output would make programs dependent on the compiler implementation, and I don't think this should be so.
BTW, GPC does not write error messages to standard output (Output), but to standard error (StdErr in Pascal), for obvious reasons.
J. David Bryan wrote:
In the absence of proper specs processing, creating a command file that runs GPC with the desired language specification switch is a reasonable workaround.
I wouldn't call it a work-around, but the best solution (besdies setting options in, say RHIDE -- though I'm also not very familiar with how to do this in RHIDE).
The specs file is system-wide and therefore should not change the default behaviour of the compiler. A private (per-user) script/alias that sets the options is the better way to go. (If RHIDE prevents aliases from working, and you don't figure out how to set the options in RHIDE itself, a script should work in any case if it's called gpc and found before the real gpc in the PATH since I suppose RHIDE searches the PATH.)
CBFalconer wrote:
I get the impression that GPC encompasses the full GCC functionality. Is this correct?
I am not sure what is meant by "the full GCC functionality." GPC does use the GCC back end and therefore may take advantage of the optimizer, output formats, etc. provided therein.
I thought I read that it would compile c, cpp, etc source if the source files carried those extensions. That seems to be taken over from GCC, so I assumed that the system was built on top of the existing GCC, including its front end.
No, these are different front-ends. The compiler driver (gpc) will just pick the appropriate front-end (gpc1, cc1, ...) depending on the file name extension and options.
PROGRAM testnn1;
BEGIN writeln('Testnn fails to detect lack of output file parameter'); (* here is needed a way to return a status *) (* which is missing from ISO Pascal *) (* PascalP uses "terminate(integer)" extension *) END.
This produces a warning with `gpc --standard-pascal'. If you want it to be an error, add `-Werror'.
PROGRAM testnn2(output);
CONST a = 1;
TYPE b = integer;
CONST c = 2;
BEGIN writeln('Failure to detect misordered declarations'); END.
I'm putting it in the test suite (chuck1.pas), so we can fix it sometime. (Though I must admit that the priority isn't very high, at least for me, since I don't program in plain SP myself, and see such restrictions as rather limiting -- mixing declaration blocks allows for more "topic oriented" structuring. But, of course, to be really conformant, GPC must detect this in the future.)
and variations on the above. There should be a numbering scheme tying the tests to sections in the standard (which I don't have anymore)
Given the number of existing tests, this would be *quite* a bit of work to do (though in theory a good thing).
and to identify the standard involved.
If a particular standard is asummed, this is noted by something like (* FLAG --standard-pascal *) in the test sources. Otherwise, the whole "GNU Pascal dialect" (i.e., the union of all supported standards, dialects and extensions) is assumed.
You seem to have multiple levels, 0, 1, extended, and others which have no published standard.
Yes, there's the object-oriented extensions draft standard, the PXSC extensions (both published) and the Borland Pascal and Delphi dialects (the latter only supported to a small degree in GPC) which are published only in the form of compiler manuals by Borland, not as abstract standards.
One that I put up on pascal.misc a while ago:
PROGRAM testnn3(output);
CONST mini = 32765; maxi = 32767;
TYPE ix = mini..maxi;
VAR i : ix;
BEGIN FOR i := mini TO 32770 DO write(i : 8); writeln; writeln('Failed to detect out of range index'); writeln('Should probably fail at compile time'); END.
GPC fails on that. -- I've just fixed it (will be in the next upload). Thanks for the report (chuck2.pas).
and another oldie is a for loop up to maxint
FOR i :- maxint-5 TO maxint DO write(i : 10);
which becomes an infinite loop on some systems.
Also with GPC? This would surprise me since GPC contains explicit code to prevent this, and at least on IA32 where I'm on right now, it works correctly.
I can prepare a few sample tests after I get more familiar with the package.
This would be very welcome. The chapter `Support', section `Reporting Bugs' in the GPC manual, as well as the file BUGS in <prefix>/doc/gpc (or similar) in GPC installations and test/README in GPC sources describes how to set up tests for our test suite.
Frank
Frank Heckenbach wrote:
... snip ...
and another oldie is a for loop up to maxint
FOR i :- maxint-5 TO maxint DO write(i : 10);
which becomes an infinite loop on some systems.
Also with GPC? This would surprise me since GPC contains explicit code to prevent this, and at least on IA32 where I'm on right now, it works correctly.
Hadn't tried it. Now I won't bother. I went through some gyrations to stamp it out on PascalP, so it sticks in memory.
I can prepare a few sample tests after I get more familiar with the package.
This would be very welcome. The chapter `Support', section `Reporting Bugs' in the GPC manual, as well as the file BUGS in <prefix>/doc/gpc (or similar) in GPC installations and test/README in GPC sources describes how to set up tests for our test suite.
A couple of things.
1. Would it be possible to have the mailing list insert a "Reply-to:" header, so that replies are auto routed to the list, rather than to the originator. I still don't know who wants what, but that seems to me to be the better destination, and editing the To: field is a pain.
2. The test suite could well be separated into a separate tarball, and made available separately. This would not preclude including that tarball in the source distribution. I gather that the full source is totally unnecessary for test execution.
3. The tests might well be grouped by area, eg. ISO, Extended, Object, Delphi, GNU. To a large extent each section includes the preceding one, and tests could be flagged if they will fail on a 'higher' group. For example, anything that includes 'const' for parameters will fail on ISO or Extended (I believe). Strict declaration section order is probably a failed test for some variants, so the headers should include a: basic area b: not for area list. Separate directories for each such group would be handy. I see no great purpose in segregating ISO-0 and ISO-1, although there is an argument for it. Once setup existing tests could be gradually migrated.
4. The tests are obviously setup for Unixy/GNUized system control, although I detect a lot of effort at segregating that. I think they are a product in their own right, and should have a separate life, and be useful for other systems than GPC. It is too bad they couldn't be built on the basis of the original test suite, now held by Prospero.
CBFalconer wrote:
Frank Heckenbach wrote:
... snip ...
and another oldie is a for loop up to maxint
FOR i :- maxint-5 TO maxint DO write(i : 10);
which becomes an infinite loop on some systems.
Also with GPC? This would surprise me since GPC contains explicit code to prevent this, and at least on IA32 where I'm on right now, it works correctly.
Hadn't tried it. Now I won't bother. I went through some gyrations to stamp it out on PascalP, so it sticks in memory.
Same for me. Though I didn't write that code (according to the change log it's actually quite old, from 1989), but I recently read the code because of another issue with `for' loops, and the extra effort done is clearly visible ...
- The test suite could well be separated into a separate
tarball, and made available separately. This would not preclude including that tarball in the source distribution. I gather that the full source is totally unnecessary for test execution.
No problem. We're going to migrate the whole GPC stuff to a new server soon, setting up some automated package building etc., and we can probably do this in one go. If you'd like to have such a tarball now, just let me know.
- The tests might well be grouped by area, eg. ISO, Extended,
Object, Delphi, GNU. To a large extent each section includes the preceding one, and tests could be flagged if they will fail on a 'higher' group. For example, anything that includes 'const' for parameters will fail on ISO or Extended (I believe). Strict declaration section order is probably a failed test for some variants, so the headers should include a: basic area b: not for area list. Separate directories for each such group would be handy. I see no great purpose in segregating ISO-0 and ISO-1, although there is an argument for it. Once setup existing tests could be gradually migrated.
- The tests are obviously setup for Unixy/GNUized system
control, although I detect a lot of effort at segregating that. I think they are a product in their own right, and should have a separate life, and be useful for other systems than GPC. It is too bad they couldn't be built on the basis of the original test suite, now held by Prospero.
Both are in principle good ideas, IMHO, but as I said in my last mail, someone would have to do the work ...
I for one, as the author of most of the tests in the current test sutie, use it mostly for regression testing of GPC (if someone changes something in GPC, I can check if it breaks something else, which doesn't happen to rarely ...). I write new tests whenever I discover problems, or things that work but "should be checked, anyway" (IMHO), and for msot new features implemented. I don't really have the time to put any more effort into the test suite, and I'm quite content with what it does for me currently.
Any volunteers?
Frank
Frank Heckenbach wrote:
CBFalconer wrote:
... snip ...
- The test suite could well be separated into a separate
tarball, and made available separately. This would not preclude including that tarball in the source distribution. I gather that the full source is totally unnecessary for test execution.
No problem. We're going to migrate the whole GPC stuff to a new server soon, setting up some automated package building etc., and we can probably do this in one go. If you'd like to have such a tarball now, just let me know.
I would. The djgpp source zip includes a large tarball for the GPC sources, and the test suite is contained therein. If you separate it please describe clearly what directory it is to be untarred in.
- The tests might well be grouped by area, eg. ISO, Extended,
Object, Delphi, GNU. To a large extent each section includes the preceding one, and tests could be flagged if they will fail on a 'higher' group. For example, anything that includes 'const' for parameters will fail on ISO or Extended (I believe). Strict declaration section order is probably a failed test for some variants, so the headers should include a: basic area b: not for area list. Separate directories for each such group would be handy. I see no great purpose in segregating ISO-0 and ISO-1, although there is an argument for it. Once setup existing tests could be gradually migrated.
- The tests are obviously setup for Unixy/GNUized system
control, although I detect a lot of effort at segregating that. I think they are a product in their own right, and should have a separate life, and be useful for other systems than GPC. It is too bad they couldn't be built on the basis of the original test suite, now held by Prospero.
Both are in principle good ideas, IMHO, but as I said in my last mail, someone would have to do the work ...
I for one, as the author of most of the tests in the current test sutie, use it mostly for regression testing of GPC (if someone changes something in GPC, I can check if it breaks something else, which doesn't happen to rarely ...). I write new tests whenever I discover problems, or things that work but "should be checked, anyway" (IMHO), and for msot new features implemented. I don't really have the time to put any more effort into the test suite, and I'm quite content with what it does for me currently.
Let me get the existing stuff working and I will see if I can find time and energy to re-organize it. Have you run it all under DJGPP? It would be nice if the ready to roll tarball was packed up under the DJGPP system, so the first step is to unzip in the DJGPP home directory, and then untar the test stuff from whereever it appears. Less opportunity for silly errors that way.
Is there any documentation about what the tests are supposed to be testing - I looked at one or two, and it was far from clear.
This info system is driving me nuts. I can't get from it to the printer or (preferably) to a text file. man files I at least know how to massage into acceptable printable text files with a few filters.
On 16 Oct 2001, at 14:47, CBFalconer wrote:
This info system is driving me nuts. I can't get from it to the printer or (preferably) to a text file.
GNU Texinfo can process the Texinfo files present in the source distribution into an HTML version of the manual, if that would help. If you have a Postscript printer, a PS version of the manual is available on the GPC Web site. There's also a version of Aladdin Ghostscript for DOS that would enable you to print the PS manual on any type of supported non- PS printer. See:
http://www.cs.wisc.edu/~ghost/
I don't use DJGPP myself, so I don't know what other option might be available to you.
-- Dave
On Tue, 16 Oct 2001, J. David Bryan wrote:
On 16 Oct 2001, at 14:47, CBFalconer wrote:
This info system is driving me nuts. I can't get from it to the printer or (preferably) to a text file.
GNU Texinfo can process the Texinfo files present in the source distribution into an HTML version of the manual, if that would help. If you have a Postscript printer, a PS version of the manual is available on the GPC Web site. There's also a version of Aladdin Ghostscript for DOS that would enable you to print the PS manual on any type of supported non- PS printer. See:
http://www.cs.wisc.edu/~ghost/
I don't use DJGPP myself, so I don't know what other option might be available to you.
If your printer is setup to print plain ascii files, then try:
makeinfo --fill-column=78 --no-headers --force -o <file>.txt <file>.texi
You will get an error message at the end which you can ignore.
Russ
On 16 Oct 2001, at 15:55, Russell Whitaker wrote:
If your printer is setup to print plain ascii files, then try:
makeinfo --fill-column=78 --no-headers --force -o <file>.txt <file>.texi
That's a great suggestion! I just tried that with the GPC manual, and it works very well.
For GPC specifically, and for anyone interested in the "cookbook" instructions, first obtain the GPC source (e.g., gpc-20010924.tar.gz) from:
ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/
Unpack all of the files that are present in the archive in the "/gpc- 20010924/p/doc" directory and subdirectories under that one (be sure to preserve the directory structure when unpacking). Then change to the "doc" directory and run makeinfo with this command line:
makeinfo --fill-column=78 --no-headers --force -o gpc.txt -I generated -I en en\gpc.texi
(that command should be all on one line). The resulting "gpc.txt" version of the GPC manual is about 1 MB.
-- Dave
J. David Bryan wrote:
Unpack all of the files that are present in the archive in the "/gpc- 20010924/p/doc" directory and subdirectories under that one (be sure to preserve the directory structure when unpacking). Then change to the "doc" directory and run makeinfo with this command line:
makeinfo --fill-column=78 --no-headers --force -o gpc.txt -I generated -I en en\gpc.texi
(that command should be all on one line). The resulting "gpc.txt" version of the GPC manual is about 1 MB.
Thanks for the info. FWIW, I'm adding a `gpc.txt' rule to the makefile that will do just that. Of course, everyone will be free to use that or the manual command line.
Frank
"J. David Bryan" wrote:
On 16 Oct 2001, at 14:47, CBFalconer wrote:
This info system is driving me nuts. I can't get from it to the printer or (preferably) to a text file.
GNU Texinfo can process the Texinfo files present in the source distribution into an HTML version of the manual, if that would help. If you have a Postscript printer, a PS version of the manual is available on the GPC Web site. There's also a version of Aladdin Ghostscript for DOS that would enable you to print the PS manual on any type of supported non- PS printer. See:
I have Ghostscript/ghostview mounted. They take forever to convert everything into bitmaps, and I don't know if I can use anything else. I also use fineprint to pack printer output into booklets. The problem with the textinfo stuff etc. is that I have to go get all the sources. I would be happy with a concatenated text version of the info screen output, but info won't dump to a file (or I don't know how). The problem with any printing from DOS is that the fineprint utility will only function in Windoze, it just can't be accessed from DOS at all, even a DOSbox.
I haven't even the vaguest idea of how to talk to the printer. It is a Samsung Laser, which comes with drivers, but not a word about the interface at the plug. Can it accept postscript (which is really text)? I don't know, but I doubt it. Can it accept text with terminal cr/lf, I don't know. Are there ESC sequences to do whatever? I still don't know. I can't even find anything from their website - it rejected any attempts to download anything midway for unknown reasons. Multiple times. Bah humbug.
Compilers are nice and simple. They have a gozinta and a comesouta.
CBFalconer wrote:
I vote against any such sweeping change. It is enough to say the --standard-pascal refers to ISO-1.
Opinions seem to be divided on what to do. Until and unless there's an agreement, I'll do nothing about it. ;-)
What is the status of the Extended Pascal (10206) standard? Is it an official standard, or in the proposed state. I just downloaded the postscript version, and that is a monster to handle on this machine. Ghostview takes forever, can't backup, etc.
Yep, they removed the PostScript DSC comments, apparently for no good reason. I'm probably not allow to distribute a version with them added again, but the attached script (requires bash and GNU awk) will do it on your local copy). This will allow gs to backup and to jump to arbitrary pages.
I haven't even the vaguest idea of how to talk to the printer. It is a Samsung Laser, which comes with drivers, but not a word about the interface at the plug. Can it accept postscript (which is really text)? I don't know, but I doubt it. Can it accept text with terminal cr/lf, I don't know. Are there ESC sequences to do whatever? I still don't know. I can't even find anything from their website - it rejected any attempts to download anything midway for unknown reasons. Multiple times. Bah humbug.
Compilers are nice and simple. They have a gozinta and a comesouta.
Yeah, I know this problem. Most modern printers (except PostScript printers which are quite a bit more expensive) have a proprietary interface and only come with a Windoze driver (and if you're lucky, a Linux driver), but no documentation of the interface ...
Frank
J. David Bryan wrote:
On 16 Oct 2001, at 14:47, CBFalconer wrote:
This info system is driving me nuts. I can't get from it to the printer or (preferably) to a text file.
GNU Texinfo can process the Texinfo files present in the source distribution into an HTML version of the manual, if that would help. If you have a Postscript printer, a PS version of the manual is available on the GPC Web site.
It's also possible to create a PDF version. We haven't done this so far on the web site, but will probably do after the migration to the new server. If someone wants it in can't build it themselves (make gpc.pdf if you have the GPC sources and a rather current version of pdftex), let me know ...
Frank
CBFalconer wrote:
Frank Heckenbach wrote:
CBFalconer wrote:
... snip ...
- The test suite could well be separated into a separate
tarball, and made available separately. This would not preclude including that tarball in the source distribution. I gather that the full source is totally unnecessary for test execution.
No problem. We're going to migrate the whole GPC stuff to a new server soon, setting up some automated package building etc., and we can probably do this in one go. If you'd like to have such a tarball now, just let me know.
I would. The djgpp source zip includes a large tarball for the GPC sources, and the test suite is contained therein.
I hope you can handle tar.gz files. In this case, they're quite a bit smaller (230 KB vs. 650 KB) since zip compresses on a file level which is quite ineffecient for large numbers of small files (like here). If not, let me know ...
ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/gpc-test-20011015.tar.gz
Please note that it already contains some tests for the latest GPC changes which haven't been uploaded yet, so these tests will fail on your version. (I'll be making some more changes before uploading them as a whole.)
If you separate it please describe clearly what directory it is to be untarred in.
Doesn't matter. Just put it in any directory and run make (or, under DJGPP under Windoze, dostest.bat, to avoid some system limit). `make clean' afterwards should remove all files generated during the test run and leave only the original files.
You can also run the tests in another directory by doing make -sf </path/to/testsuite/>Makefile srcdir=/path/to/testsuite
Let me get the existing stuff working and I will see if I can find time and energy to re-organize it. Have you run it all under DJGPP?
Yes. I routinely let it run under DJGPP (within Linux Dosemu, though this shouldn't make a big difference).
It would be nice if the ready to roll tarball was packed up under the DJGPP system, so the first step is to unzip in the DJGPP home directory, and then untar the test stuff from whereever it appears. Less opportunity for silly errors that way.
I'm not too familiar with the DJGPP file system hierarchy, so perhaps someone can tell me how to do it (which directory etc.). I should then probably also create a manifest file (which I haven't done yet). For now, just put it in any directory and remove the whole directory when you want to get rid of it. I'm leaving the `p/test' prefix in the archive, so it won't clobber the directory in which you extract it.
Is there any documentation about what the tests are supposed to be testing - I looked at one or two, and it was far from clear.
Sorry, there isn't (except in a few cases where noted in program comments or obvious from the file name or something).
Frank
Frank Heckenbach wrote:
CBFalconer wrote: I'm not too familiar with the DJGPP file system hierarchy, so perhaps someone can tell me how to do it (which directory etc.).
Test suites are usually not installed and remain within the sources. Probably the most natural would be to install them in a doc/gpc/test directory (below the djgpp root directory, which is always implied), i.e. at the same level than the demos and docdemos directories.
I should then probably also create a manifest file (which I haven't done yet).
I use the small attached gpc program which also produces the zip: (notice that manifest files contain forward slashes, even for DOS). You put everything with the intended directory structure (but omitting the djgpp root and also the manifest directory which will be created) below some temp directory and issue makedist from there.
Others use shell scripts I suppose.
Maurice
Maurice Lombardi wrote:
Frank Heckenbach wrote:
CBFalconer wrote: I'm not too familiar with the DJGPP file system hierarchy, so perhaps someone can tell me how to do it (which directory etc.).
Test suites are usually not installed and remain within the sources.
Sure, but I see Chuck's (and perhaps some others') desire to get the test suite without the (quite a bit bigger) source archive.
For mere regression testing it would be sufficient if everyone who builds GPC, and therefore has the sources, runs the test suite, but since we also wish to encourage everyone to report their bugs in a test-suite conformant way, and possibly write additional tests, I like the idea of a separate test-suite (in addition).
Probably the most natural would be to install them in a doc/gpc/test directory (below the djgpp root directory, which is always implied), i.e. at the same level than the demos and docdemos directories.
Does everyone agree on that for DJGPP?
For Unix, should we also do it in <prefix>/doc/gpc/test/, or rather in a relative directory? I'm not sure (and I don't care very much since I'll always use the full sources, anyway).
I'm just thinking ... should we install the test suite "core" (i.e., just the Makefile and scripts, not the many, many test files) with every GPC installation so that every GPC user has an easy access to the test-suite when it comes to writing new tests (not for complete regression testing, of course)? That would be just a few files which shouldn't hurt anyone.
I should then probably also create a manifest file (which I haven't done yet).
I use the small attached gpc program which also produces the zip: (notice that manifest files contain forward slashes, even for DOS). You put everything with the intended directory structure (but omitting the djgpp root and also the manifest directory which will be created) below some temp directory and issue makedist from there.
Others use shell scripts I suppose.
Yes, me. :-) I think something like the following (untested) should work:
mkdir manifest echo "$2" > "manifest/$1.ver" find -type f | sed 's,^./,,' > "manifest/$1.mft" zip -9r "$1.zip" .
Frank
On 15 Oct 2001, at 1:50, Frank Heckenbach wrote:
The specs file is system-wide and therefore should not change the default behaviour of the compiler. A private (per-user) script/alias that sets the options is the better way to go.
I would argue that the "better way to go" depends on the situation.
If I want to deploy GPC as an EP compiler only for a team, then setting up multiple per-user script files, and ensuring that each person actually uses their script file every time, would seem to be awkward and error-prone. The same argument would apply to any other team-wide settings (e.g., -fno- macros, or -funit-path).
Changing the default behavior of the compiler in these cases would be far safer and make far more sense than would attempting to force every user to invoke the compiler only by using the proper script.
Of course, per-user scripts make sense for individuals to set personal preferences.
-- Dave
On 14 Oct 2001, at 13:10, Marco van de Voort wrote:
I think that CB's statement is only true for commandline systems.
ISO 7185, section 1.1 ("Scope") says:
This International Standard specifies the semantics and syntax of the computer programming language Pascal by specifying requirements for a processor and for a conforming program.
...and section 5.1 ("Compliance, Processors") says:
A processor complying with the requirements of this International Standard shall:
[...]
c) not require the inclusion of substitute or additional language elements in a program in order to accomplish a feature of the language that is specified in clause 6;
If I understand those sections correctly (argument welcomed :-), standards- compliant implementations are not permitted to impose additional syntactic or semantic requirements beyond those explicitly stated in the standard (except where such requirements are explicitly allowed as "implementation defined").
The syntax indicates that program-parameters (such as "output") are optional. The semantics in the standard say that "output" is required as a program-parameter only if the file-variable is omitted for the predefined procedures "write", "writeln", and "page". Therefore, a complying system cannot require the specification of "output" in every program header (although a non-complying system certainly can).
I admit that I find reading the standard(s) to be quite difficult, so arguments against my interpretation are welcomed!
To bring this back home, when given a legal program with no program parameters, "gpc --standard-pascal" and "gpc --extended-pascal" report:
warning: no program parameters specified
I shall have to research the standards more before determining whether this is a bug or a feature. ;-)
-- Dave
J. David Bryan wrote:
To bring this back home, when given a legal program with no program parameters, "gpc --standard-pascal" and "gpc --extended-pascal" report:
warning: no program parameters specified
I shall have to research the standards more before determining whether this is a bug or a feature. ;-)
Please do. It would be easy, of course, to remove the warning, but before I do, I'd like to be sure whether that's the right thing to do.
Frank
On 16 Oct 2001, at 14:54, Frank Heckenbach wrote:
Please do. It would be easy, of course, to remove the warning, but before I do, I'd like to be sure whether that's the right thing to do.
I will read further and report back, but as far as I can tell, it's legal to omit the program-parameter-list if "input" and "output" are not used implicitly (a citation from the standard that contradicts this would be welcomed). It is certainly syntactically legal, as the syntax specifies that the list is optional. My only uncertainty is whether it is semantically legal.
It appears from a cursory reading that the standard enumerates the cases where "input" and "output" are implied and therefore required to be present in the program-parameter-list. GPC would need to detect those cases and output an error message only if they occur.
I shall read the standards in-depth, once I put the clamps on my head to keep it from exploding. ;-)
Also, you wrote:
However, I don't think the standards define warnings at all....
That was actually what I intended with my "bug or feature" comment. If the standard doesn't define warnings, then should warnings about things that are true (i.e., there are no program parameters), but that are not violations of the standard, be considered bugs?
-- Dave
J. David Bryan wrote:
On 16 Oct 2001, at 14:54, Frank Heckenbach wrote:
Please do. It would be easy, of course, to remove the warning, but before I do, I'd like to be sure whether that's the right thing to do.
I will read further and report back, but as far as I can tell, it's legal to omit the program-parameter-list if "input" and "output" are not used implicitly (a citation from the standard that contradicts this would be welcomed). It is certainly syntactically legal, as the syntax specifies that the list is optional. My only uncertainty is whether it is semantically legal.
Actually, I doubt whether the standard would explicitly(!) allow something syntactically if it's invalid semantically in any case.
It appears from a cursory reading that the standard enumerates the cases where "input" and "output" are implied and therefore required to be present in the program-parameter-list. GPC would need to detect those cases and output an error message only if they occur.
It does already. This warning (in the future: error) is already there in addition to the (questionable) warning about `no program parameters specified'.
Also, you wrote:
However, I don't think the standards define warnings at all....
That was actually what I intended with my "bug or feature" comment. If the standard doesn't define warnings, then should warnings about things that are true (i.e., there are no program parameters), but that are not violations of the standard, be considered bugs?
I don't think so. It's certainly useful to have a compiler warn about, say unused variables (though these are valid according to the standard AFAIK). It must not be an error, of course.
Frank
On 16 Oct 2001, at 20:39, Frank Heckenbach wrote:
Actually, I doubt whether the standard would explicitly(!) allow something syntactically if it's invalid semantically in any case.
That's my guess as well, but I suppose that guesses don't count here....
It's certainly useful to have a compiler warn about, say unused variables (though these are valid according to the standard AFAIK). It must not be an error, of course.
Precisely.
-- Dave
J. David Bryan wrote:
...replies do not default to the list, but to the originator. I assume traffic such as this should go through the list.
The list owner has rather strong views regarding whether the reply address should default to the originator or to the list. I happen to disagree with him on this matter :-), but, in any case, replies should indeed go to the list. (No need to copy me separately, as I read the list. :-)
His arguments are the same as found on http://www.unicom.com/pw/reply-to-harmful.html (which does not necessarily reflect my own opinion).
Frank
Frank Heckenbach wrote:
J. David Bryan wrote:
...replies do not default to the list, but to the originator. I assume traffic such as this should go through the list.
The list owner has rather strong views regarding whether the reply address should default to the originator or to the list. I happen to disagree with him on this matter :-), but, in any case, replies should indeed go to the list. (No need to copy me separately, as I read the list. :-)
His arguments are the same as found on http://www.unicom.com/pw/reply-to-harmful.html (which does not necessarily reflect my own opinion).
Since I read offline, it is not convenient to visit that URL just now. I still have no idea who wants what.
On 14 Oct 2001, at 18:37, CBFalconer wrote:
I still have no idea who wants what.
Regarding replies? Post replies to the list, not to the originating individual. (The usual exceptions for personal comments and off-topic discussions apply.)
-- Dave
-
CBFalconer -
Frank Heckenbach -
J. David Bryan -
marcov＠stack.nl -
Maurice Lombardi -
Russell Whitaker -
Theo Carr-Brion