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

[Dan Cross]

In article <tvs23c$37d4e$1 at dont-email.me>,
Simon Clubley  <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>> [snip]
>
>In this very different world, gets() was once considered to be an acceptable
>function. :-)

Hey, it was finally removed from the C standard!

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

I agree with you, but this is not why strncpy() was introduced.
The name here is bad, but it was really intended for copying
string-like data into fixed-width _fields_ in data structures
(such as directory entries in the filesystem structures that are
written to secondary storage).

It has other patholical behavior, too: in particular, it touches
every byte in its output argument, regardless if the source is
shorter than that or not.

Modern replacements, like strlcpy/strlcat, are generally
preferable.

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

I mostly agree; syntax that can disambiguate between assignment
and comparison is better in a language like C that is loose in
the sense of allowing almost any expression in a boolean
context.

More modern languages "fix" this by just not punning arbitrary
arithmetic expressions to bools.

>enums are integers, not a type.

+1e6

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

Absolutely; same for data.

>signed characters are the default.

As Johnny pointed out, it's even worse!  This is implementation
defined.

	- Dan C.