According to Frank Heckenbach answering to a mail by Phil Nelson:

Ok, then, if I got this right, you have to do write(num_var:1) and write(string_var) for output without spaces, whereas write(num_var) and write(string_var:1) both don't work this way.

This seems a bit inconsistent and confusing to me.

To me, too. That's why I prefer Borland's way to default to a width of 0 (or 1 in the above example) if nothing was specified (which does not contradict the standard, BTW), and to treat string values just like all the other ones, i.e. without clipping.

I see that your programs rely on this way, but my programs rely on BP's way, and I don't think there's anything worse with BP's way than the standard's way. So, obviously, gpc needs to support both ways.

So it's okay that "gpc --borland-pascal" does switch off string clipping, while "gpc --standard-pascal" or "gpc --extended-pascal" turns it on. There must also be a pair of separate switches, e.g. "--clip-strings" and "--no-clip-strings", to make this decision independent of the selected Pascal dialect.

(*** Does anybody know how UCSD behaves here? I don't want to dig out my old Apple //e in order to check this. ***)

Now what about default field widths? The ISO Standard allows this to be implementation-dependent. If we just take Borland's method it still complies to the standard, so there is no a-priori reason to make this change at all. However it seems to be a de-facto-standard that ISO Pascal compilers have default field widths that are wide enough to ensure that numeric values are always output with leading spaces. Thus `--standard-pascal' and `--extended-pascal' should imply such wide field widths. Of course there must be a separate switch for them, for example "gpc --field-widths=12,24,6" (for Integer, Real, Boolean values).

The above does not clarify how GPC's default behaviour should be. IMHO Borland's method is more logical than what most Standard Pascal compilers do. However the only true contradiction between Borland and ISO in this context is string clipping which only occurs in very rare cases (at least in my programs). Thus I could live with string clipping being "on" by default. Concerning field widths, it does not contradict ISO Standard to follow Borland, so we should do that. (Remember that `--borland-pascal' turns string clipping off and that `--standard-pascal' makes GPC behave like other Standard Pascal compilers.)

BTW, there are some other strange things in GPC's interpretation of field widths:

* When an Integer value is being output with a field width of zero, output is suppressed. Is this ISO Standard (doesn't seem so), or a bug?

* When a Real value is being output with a too narrow field width, other compilers bother to make the output as short as possible. Should GPC do the same?

* All Pascal compilers I have access to have the "feature" that it is impossible to output a positive Real value without at least one leading blank. This is annoying in some situations, so what about an additional switch, e.g. `--no-real-blank', to disable it optionally? (Better suggestions for the names of all compiler switches are welcome!)

That's it for the moment.

Sqr ( BTW ), this switcherism makes it more and more necessary to let GPC read in a configuration file, or to use `make' to keep all these switches in a Makefile, or to use RHIDE which provides a menu for them.

Greetings,

Peter

Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125]