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

[Simon Clubley]

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. :-)

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).

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.

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.

signed characters are the default.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.