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

Bakul Shah via COFF coff at tuhs.org
Wed Jan 7 05:23:06 AEST 2026



> On Jan 6, 2026, at 10:28 AM, segaloco via COFF <coff at tuhs.org> wrote:
> 
> On Tuesday, January 6th, 2026 at 09:42, Bakul Shah via COFF <coff at tuhs.org> wrote:
> 
>> 
>> Personally I would define a "shared" attribute and allow shared globals -- the idea being any access to shared variables is protected via mutexes --
>> 
> 
> Like all things, this sounds great as long as I can turn it off when I
> know, by definition, collisions shouldn't happen.  Otherwise I'm
> potentially avoiding a race condition (good!) in code that by definition
> should not be capable of a race condition (bad!), side-stepping the root
> cause entirely.  I should fix that, not my compiler/language.

Critical sections *are* a solution to avoiding race conditions! Better that
the compiler always puts in necessary code to implement critical sections.
*You* may be smart enough to find and fix race conditions but in general
race conditions are extremely hart to catch. [A colleague and I once had to
spent 14 days of 16 hour workdays because of a race condition in V7 Unix
that somehow escaped the original unix wizards]

And when code changes, every time you have to recheck that "collisions
shouldn't happen" remains true.

> 
> Those are the kinds of things that do keep me up at night with all the
> "hand-holding" in modern programming systems.  Sure, it'll keep me from
> invalid access without having to pay it much mind, but I *want* to pay
> my invalid accesses some mind to tighten up my algorithm, not just hope
> the language fixes it in post.
> 
> - Matt G.

It depends on how you look at languages that provide more expressive power
and proper abstractions. If multiple threads are sharing a variable, I want
to express that and have the compiler relieve me of the grunge work of checking
for race conditions every time (at least for *that* variable). PLs are for
communicating algorithms not just to compilers but also humans. Ideally one
wants correct, clear, concise and efficient code but very hard to achieve all
four (at least across the broad spectrum of use cases).



More information about the COFF mailing list