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

[Johnny Billquist]

On 2023-04-12 16:44, Arne Vajhøj wrote:
> On 4/12/2023 10:41 AM, Arne Vajhøj wrote:
>> 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.
> 
> Examples of code:

[...lots of code deleted...]

The problem with this is that it is very artificial, and designed to 
prove your point.

I can just as well give a counter example.

Let's say you have a character that you know is a digit, and you want to 
convert it nicely to an integer.

In C, you'd do that like this:

    x = c - '0';

In FORTRAN, BASIC, and god knows what else, you'd see:

   x = ord(c) - 48;

Now, I'd say I've seen plenty more of that than your type of example.
And I've *never* seen:

   x = ord(c) - ord('0');


And yes, of course, you can also in C do:

   x = c - 48;

but I'd say that is less common, and a bad programmer will always manage 
to write bad code, no matter what language. That don't mean the language 
is bad. It is just more unclear, and in C there is no performance 
reason, or anything else giving any reason why you would write 48, when 
'0' is so much clearer what the intent is. And then it also works if you 
use another character set, as long as all the digits have consecutive 
code points.

   Johnny