Re: VMS Pascal article

On 1/3/2025 10:11 AM, Dan Cross wrote:

In article <vl3pi8$2r2sr$1@dont-email.me>,
Arne Vajhøj  <arne@vajhoej.dk> wrote:

VMS Pascal for C/Java/C# programmers:
      https://www.vajhoej.dk/arne/articles/vmspascal.html
>
It is a "pre-release" - I am not sure I got it right.
>
So I would love some feedback.

C supports 'long double' which _may_ be the same as
`quadruple`, depending on the implementation, though
that's usually 80-bit floats.

Very good point. It is 128 bit on VMS unless using /L_DOUBLE=64.
Added.

I would not say that 'chr' and 'ord' are like casts in C.
Pascal is strongly, statically typed; C is weakly typed with
implicit conversions.  Conversion between characters and integer
types in Pascal is an explicit operation, but `int c = 'a' + 1;`
is perfectly legal in C.

It was the best explanation I could come up with.

You give two C equivalents of, `round`: `lround` and
`ceil(v + 0.5)`.  Surely the latter should be `trunc(v + 0.5)`:

Ooops. All ceil should be floor.
Fixed.

But, consider negative numbers,

Very good point.
I have added notes.

                                  and note that one would still
have to do a conversion to an integer type.

Yes.
Fixed.

Your C equivalent of `substr` is not correct; exercise left to
the reader (consider what happens when `ix` is beyond the end of
the string).  For that matter, this is true of the VSI Pascal
example as well: you should specify the preconditions that must
be true.

Invalid index or length causes an exception in VMS Pascal.
But I don't want to get into that level of detail.

`readln` and `fgets` are not similar in that `readln` strips the
line ending sequence, and `fgets` does not.

Close enough for the purpose of this article.

`f = fopen,fnm "r");` is an obvious typo.
`while not eof(f)) do` is an obvious typo.

Fixed.

You may want to mention that Pascal, the semicolon is a
statement separator, not a terminator, and hence why the last
"END" in the protocol is followed by "." and not ";".

The article is more what to do than why to do that.

The structure you present at the end as "equivalent" of a
varying character array is not correct.  `integer16` is a signed
type, with a maximum value of 32,767.  The length field for a
`varying [n] of char` is an integer subrange type with word
representation.  That is, `length` is unsigned 0..max, where max
is <= 65,535.

Ooops.
You are right.
I was sure that the limit was 32K but it is 64K.
Fixed.
And also fixed in the description of VARYING further up.
Arne