[COFF] [TUHS] C vs Pascal thoughts - was Buffer overflow found/fixed in v4 tape ; )

[Bakul Shah via COFF]

> On Jan 5, 2026, at 10:16 AM, Clem Cole via TUHS <tuhs at tuhs.org> wrote:
> 
> Moving to COFF, bcc  TUHS
> 
> On Mon, Jan 5, 2026 at 12:47 PM Bakul Shah <bakul at iitbombay.org> wrote:
> 
>> Actually Pascal got a lot of things right. Coming from being intimately
>> familiar with Pascal and its orig. compiler, I disliked these things in C:
>> 1. poor array support, no multi-dim arrays
>> 2. C's union type vs Pascal's variant records
>> 3. no subrange type
>> 4. C's poor type system
>> 5. C's enum type which are essentiall integers vs Pascal's strict
>> enumeration type
>> 6. No nested functions.
>> 
>> [Of course, there were many things to like in C as well.]
>> 
>> Granted, it was not as clean and orthogonal as Algol68 (whose popularity
>> suffered from surface issues such as use of vW grammar od choice of
>> keywords
>> etc.).
>> 
>> Also note that pretty much all non-C compilers pre-1988 generate code to
>> do bounds check -- at least as an option but more often the option was to
>> turn *off* bounds check!
>> 
>> Now that we are aware of the danger of no bounds check, we seem to have
>> gone
>> to other extreme of using complicated languages like Rust....
> 
> 
> I, too,  don't "hate" Pascal and don't argue with the strengths it
> demonstrated.  But I have one primary issue: *"Which Pascal do you
> mean?"  *When
> I worked at Tektronix, Ward Cunningham and I counted 14 different "Tek
> Pascals" in use at the time.  The paper "*Why Pascal is not my Favorite

I used The "Pascal User Manual and Report" as *the* Pascal, though granted
it didn't pin down nitty gritty details. May be why there were so many
variants (also due to small memory sizes of microcomputers of the era).

> Programming Language*" [
> https://web.archive.org/web/20060821183401/http://cm.bell-labs.com/cm/cs/cstr/100.ps.gz
> ] offers up the fundamental issues.  I suggest looking at Ward's Wiki [
> https://wiki.c2.com/?WhyPascalIsNotMyFavoriteProgrammingLanguage ] as there
> are some interesting comments.

I reread bwk's paper after a long time (thanks Arnold for the link to
troffable paper). Just a quick impression:

He says (talking about range types) "although of course run-time checking
does exact a penalty." Of course it does in the general case, but this
criticism seems funny now in light of buffer overflow issues!

2.1 (array size part of its type) is a definite issue. This was more or
less fixed in the 1985 Pascal std with "conformant arrays" (but not well
enough IMHO). bwk also talks about strings. Perhaps a "string" type would
have been better. 

2.2 static variables --  I tend to believe using static vars is usually
a mistake. Initialization -- saves some typing but that is about it.

2.3 related components have to be kept separate.

2.4 separate compilation -- yes, this was a problem. Ironically C had
separate compilation but its weak type system made it error prone (and not
fixed for years).

2.5 misc. I saw these more as a lack of convenience than intrinsic to Pascal.
These were probably added by some variants later.

bwk says "But the calling program has no way to declare that a variable is to
be modified". Perhaps he means "no way to *note* that a variable is to be
modified". C indicates this by &var syntax but this adds to inconvenience in
the called function (have to explicitly deref it or use -> for struct fields).

2.6 no cast. I think casts are actually a misfeature of C. I once had to fix
a program that was "lint free" (back in 1980s) but kept crashing. Turned out
the client's programmers used casts liberally to shut up the linter! 

3 control flow - these seem nitpicky.

4 environment & io. IO was certainly a weak point of Pascal.

Both language designs were the result/victims of their intended audience.
Perhaps Pascal as a teaching language didn't have enough real life use
(early its life) to debug IO design, add convenience features etc.
The way C grew, working code to solve real problems was more important
than any theoretical soundness.

> 
> I think this observation is also important:
> 
>> "Interestingly, many of Kernighan's objections to Pascal are things that
>> Knuth also found it necessary to address in his LiterateProgramming
>> <https://wiki.c2.com/?LiterateProgramming> tool "Web", which he used in
>> the development of TexTheProgram <https://wiki.c2.com/?TexTheProgram> and
>> Metafont. It is fair to say that the Web system is only half about
>> LiterateProgramming <https://wiki.c2.com/?LiterateProgramming>; the other
>> half is just workarounds for the shortcomings of the Pascal dialects of its
>> day. Most notably, Web provides a mechanism to allow the use of
>> variable-length strings in things like error messages."

Pascal's shortcomings were solvable (but weren't) while we are still paying
for C's shortcomings.