Adriaan van Os wrote:
Frank Heckenbach wrote:
For strings, range checking is BP compatible (access up to the capacity allowed) in `--borland-pascal' and `--delphi' modes and EP compatible (access only up to the current length allowed) otherwise. So in default (EP) mode code such as
if MyString[1] = '-' ...without a check
if (MyString <> '') and ...may now fail with a range-checking error. This is useful, since the first test was always undefined if `MyString' was empty, but in my experience so far, this has been one of the most common causes of range-checking errors in my code.
Shouldn't this depend on the internal representation of the respective string rather than the dialect ? BP compatible range checking for strings makes sense for UCSD-Pascal strings when implemented in GPC. UCSD-Pascal strings are not only used by --borland-pascal but also by --ucsd-pascal and --mac-pascal. And UCSD-Pascal strings allow access to element 0.
I don't think you can make a single range checking rule for UCSD Pascal style strings. There is some variation between different vendors' implementation in the range checking criteria enforced in accessing individual string elements of UCSD Pascal style strings.
For example, the documentation for THINK Pascal (a MacPascal dialect compiler) states range checking checks that the individual character element being accessed is within the range 1..n where n is the current length of the string whose individual character element is being accessed. The documentation also specifically notes (by example) that accessing "element" 0, e.g., MyString[0], is not allowed when the range checking option is on.
As to what string range checking criteria to use for GPC's --mac-pascal dialect mode, since the documentation for Metrowerks/CodeWarrior Pascal and MPW Pascal does not explicitly state what the string range checking criteria is for the respective compilers, I need to do some test program checking with the compiler implementations to see what the implementations actually enforce with the range checking option on before stating what the criteria should be. (As Frank has indicated, what is allowed and works with range checking off is not necessarily allowed with range checking on. Since range checking is off by default, one can easily form a mistaken impression that some string constructs which work without range checking also work with range checking on when they really don't.)
Gale Paeper gpaeper@empirenet.com