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

[Arne Vajhøj]

On 4/7/2023 4:58 PM, Johnny Billquist wrote:
> On 2023-04-03 14:31, bill wrote:
>> On 4/2/2023 8:50 PM, Johnny Billquist wrote:
>>> On 2023-03-29 19:51, bill wrote:
>>>> Weird?  What about under Primos where chars always have the high order
>>>> bit turned on?  It was called "mark memory parity" but it never made 
>>>> any
>>>> sense to me when I had to work with it.  :-)
>>>
>>> I think/suspect that this goes outside the scope of C...
>>
>> Of course it does.  But it affects C a lot more than other languages
>> if for no other reason than programming style.  How many Unix C programs
>> have you seen where parsing is done by looking at the value of a letter
>> as opposed to just comparing chars?  Even with Primix porting a Unix
>> program to a Pr1me was a serious task and often not even possible.
> 
> I don't understand what you mean. Are you just talking about some people 
> assuming you have ASCII, and looking at the decimal values, instead of 
> the character representation. Basically writing 65 instead of 'A'?
> If so, that is certainly something I've seen in lots of languages, and 
> are in fact much more an issue in most other languages that I've used, 
> since they do not consider a thing like 'A' to be a numeric value. C 
> doing that really helps in this context.
> 
> I'd say it's more common to see C code using the characters instead of 
> their numeric representation just because it is so easy to do in C.

I believe there are basically two groups of languages:

A) those where one can write both c=='A' and c==65
B) those where one can write c=='A' but c==65 gives a compile error and 
has to be written as ord(c)==65

I find it more likely that group A will use 65 than group B.

Arne