[Info-vax] C limitations, was: Re: VMS process communication

[Johnny Billquist]

On 2023-03-27 14:27, Simon Clubley wrote:
> On 2023-03-25, Scott Dorsey <kludge at panix.com> wrote:
>> bill  <bill.gunshannon at gmail.com> wrote:
>>> I knew there was.  I just find it funny that everyone holds that
>>> idea up as the very worst thing in C and yet, as you said, it was
>>> the industry standard long before C came around.  Had C done it
>>> differently I am sure people would have bitched about abandoning
>>> the current standard.
>>
>> Quite possibly, but they would have had a lot fewer buffer overrun
>> vulnerabilities while doing so.
>>
>> I am a big fan of C and I definitely think null-terminated strings
>> were a mistake.  There are syntax issues in C that I don't like, but
>> there is nothing in the same order of magnitude as null terminated
>> strings.
>>
>> But, at the time C was made, the notion that people would attempt to
>> deliberately cause software to malfunction seemed alien.  It no longer
>> is, and as the world has changed the design decisions that seem appropriate
>> may have changed as well.
> 
> In this very different world, gets() was once considered to be an acceptable
> function. :-)

That one is bad in a way that is hard to defend.

> In the more recent world, strncpy() is not always guaranteed to write
> a terminating null. Absolutely no excuse for that one :-(, especially
> given that it was supposed to be a fix for strcpy() (IIRC).

Agreed that this is sortof very annoying, but the workaround is 
exceedingly simple. So I tend to just be annoyed by it, but it don't 
really cause any problems if you just are aware of it.

> Other annoyances (apart from the null-terminated strings):
> 
> = for assignment, versus == for comparison. (At least it's not PHP however,
> where you need to use === to get a sane comparison. :-))
> 
> enums are integers, not a type.

Not sure I consider the enum thing to be much of a deal. Unless we 
compare to Ada, which is the only language I've seen which really do 
enums properly as its own type.

> Functions are public unless marked as static. I would have preferred them
> to be private by default with the need for a "public" keyword to make the
> function visible to the linker.

I could agree with that. Not that I think it's a big deal, and I can see 
people becoming very annoyed had it been the other way around as well.

> signed characters are the default.

Actually, this one is worse. char is implementation defined if it is 
signed or not (really - the standard says so).
If you think/assume they are signed, you're asking for it...

   Johnny