CBFalconer wrote:
I ran the following little tests. There are some comments in the source. In particular I am worrying about the use of field width specifications. 0 is illegal in ISO7185, legal in 10206. -ve are illegal in both, and not detected. I really have no great objections to this, but if it is not detected lets at least put it to good use. I recommend using -ve values to cause left justification in the field.
This has been discussed long time ago, and an implementation was started, but never finished.
If I'll finish it now, I'd prefer to do it standard-compliant, i.e. reject it in the standard modes, and use it for left justification in the GPC mode (and do whatever BP does in BP mode, I'd have to check this).
I wasn't aware that 0 is invalid in 7185, but if so, we should do this as well then ...
BTW what is the effect, if any, of the -pedantic,
Complain about just about everything (i.e., anything that is invalid or problematic in any known dialect). Quite as the name says. :-)
-W, -Wall gcc options?
See the GCC manual (Invoking GCC/Warning Options).
Should we be using -gstabs+ (my practice) or just -g. Under DJGPP in particular.
Whichever works currently. ;-) As was said before, debug info (especially with gcc-3) is still fragile. Stabs seems to work now under Linux in my tests, and so it will under DJGPP hopefully. COFF (which is the default with just `-g', AFAIK) might also work, but I haven't tested this myself ...
Emil Jerabek wrote:
As usual: negative field width is an "error", which means:
3.2 Error
A violation by a program of the requirements of this International Standard that a processor is permitted to leave undetected.
There are dozens of other errors like this which gpc doesn't detect.
BTW, if you'd like to make a list (or have one already) of those that GPC doesn't detect and that are not on the to-do list already, please let me know. (Though I don't promise that I'll fix them immediately, but it's good to know what should be improved in the future.)
I also consider the failure to stop compilation on the final '.' a serious fault. This feature makes the sources immune to the lack of line termination at the end of the source file, and allows appending useful commentary there. Some of my files end with ^Z (for EOF on CP/M or MsDos) and a two byte CCIT CRC checksum. This makes it extremely easy to detect corruption. Heeding the final '.' makes the system immune to the OS handling of EOF markers.
The standard doesn't permit garbage anywhere, be it at the end of the file or at other place.
Actually, I don't think the standard speaks of source files at all (so it should also be valid to extract the files from an archive, or get them from a web site during compilation ... ;-).
Therefore this behaviour may be unspecified by the standard. AFAIK, the reason for allowing multiple parts in a file in GPC was that that's often desirable for a module interface and its implementation.
However, there doesn't seem to be a compelling reason for any more than this. So, if there's consensus, I might make GPC allow only one program, one unit, one module interface or implementation, or one module interface plus its implementation.
But even then I'd still prefer to issue at least a warning if "garbage" is found after the final `.'.
IIRIC gpc _does_ ignore stuff after the first final "." in --borland-pascal mode, but I don't remember if there a separate switch for this feature.
Currently there's no separate switch, but I can easily make one. (Perhaps `-Wno-garbage-after-dot' -- if we make it a warning as described above.)
CBFalconer wrote:
I am arguing that I see no point to the practice, and that stopping all consideration of the source file after the final '.' is desirable. I may well have missed some reason for allowing such practices. Maybe Borland did allow such; if so I never used it and never missed it.
Quite the contrary, actually, i.e. in this case you're on the same side as Borland (and I disagree with you and them ;-).
Frank