[Info-vax] VAX Macro to C conversion

[Arne Vajhøj]

On 7/11/2019 9:26 PM, Bill Gunshannon wrote:
> On 7/11/19 5:26 PM, Arne Vajhøj wrote:
>> On 7/11/2019 10:21 AM, Bill Gunshannon wrote:
>>> On 7/10/19 9:00 PM, Bill Gunshannon wrote:
>>>> On 7/10/19 8:49 PM, Arne Vajhøj wrote:
>>>>> On 7/10/2019 8:42 PM, Bill Gunshannon wrote:
>>>>>> On 7/10/19 2:20 PM, Arne Vajhøj wrote:
>>>>>>> But while Fortran and Pascal fixed the problem, then C
>>>>>>> did not.
>>>>>>
>>>>>> Actually, it did.  A long time ago.
>>>>>> 1983 PDP-11 Software Source Book -- Page 1395
>>>>>> 1986 VAX Software Source Book -- Page 1155
>>>>>>
>>>>>> The Safe C Compiler.
>>>>>>  From Catalytix Corp.
>>>>>>
>>>>>> OSes supported: RSTS, RSX, RT-11, ULTRIX-11, UNIX, ULTRIX-32, VMS.
>>>>>
>>>>> Did it have a string type?
>>>>>
>>>>
>>>> I seriously doubt it as it then wouldn't have been C.  :-)
>>
>> But that was what we were discussing for Fortran and Pascal.
> 
> The 77 Fortran standard and various Pascals (I don't have a copy
> of the standard handy) added strings to the language.  C never has.
> And the C in use at the time Safe C was created was pure K&R.

As I wrote:

 >>>>>>> But while Fortran and Pascal fixed the problem, then C
 >>>>>>> did not.

>>>> "The language understood by the Safe C Compiler is identical
>>>>   to that understood by the standard C compilers."
>>>>
>>>> But, it had a lot of the checks people here keep arguing that C
>>>> needs.  Array indexing, Stray Pointers, mismatched formal and
>>>> actual parameters, Misuse of string functions, etc.
>>>>
>>>> And the industry rejected it completely.  None of its features
>>>> ever showed up in C Compilers that followed.
>>>>
>>>> So, tell me, why did none of these things find their way into
>>>> the VMS C Compilers?
>>>
>>> You know, makes one wonder.  Why did ANSI change so much trivial
>>> stuff when the modified K&R to create ANSI-C and not fix any of
>>> these supposed shortcomings?
>>
>> If they had then C would have been much better for most applications
>> but worse for operating system kernels.
> 
> In what way?  I don't need unbounded arrays to write an OS.  Or a
> device driver.

Maybe not, but you will need unbounded pointers.

And with C's mixing of pointers and arrays, then bounded arrays
would become messy to implement.

>> But it seems quite plausible that the logic was "C does what
>> it does - those that want a more safe language should pick
>> another language".
> 
> And yet the tried to add OO to COBOL.  They created a standard for
> Pascal which, for obvious reasons, couldn't please all Pascal users.
> They added strings to Fortran, a language specifically intended for
> complex mathematics.  Go figure.

But most of those changes was pure extensions of the language meaning
that existing code would run as is (there are a few exceptions,
but ...).

Some of the problems in C being discussed could be fixed in a
non-breaking way. But other like removing flexible pointer manipulation
would break a lot of existing C programs.

>>> Why did VMS versions of C not fix any of this?  There is nothing
>>> in the language that prevents range checking or array boundaries.
>>
>> They needed to be standard compliant.
> 
> Does the standard explicitly state that boundaries and ranges can
> not be validated?

No.

But it makes it difficult to implement given what has to work.

>> I don't think it is possible/practical to make all required array,
>> pointer and array-pointer mix functionality in the standard
>> work with array range check.
> 
> If it can't be fixed then why do people still complain about the fact
> that C does it?

I think most of the complaining about C is related to the usage.

Not a problem writing OS kernel in C. For that purpose you can't have
a language where a pointer can only point to something new'ed. You
need to lookup stuff all over S0 space. That comes with certain
risks, but those risks are unavoidable.

The problem is the other 99% of applications, where the ability to
shoot oneself in the foot is not needed and just an unnecessary risk.

Arne