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

[Johnny Billquist]

On 2023-04-16 19:26, Arne Vajhøj wrote:
> On 4/12/2023 9:33 PM, Johnny Billquist wrote:
>> 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.
> 
> Testing if a char is in the digit range is not an artificial problem.
> 
> Yes - the example was showing my point - it would have
> been pretty weird if I had produced an example that did
> not show my point.

The problem is that it is very artificial.
First of all, I've never seen C code where people would write

if ((x < 48) || (57 < x)) { ... }

It's just plain stupid to write that if they want to check if it is a 
digit. It's close to unreadable, and just makes much more sense to say 
'0' and '9'.

But secondly, noone in C would/should ever even do such a stupid thing. 
There are isdigit() for exactly this, and basically any other 
categorization you would want to do, so even more so, the suggested bad 
way of doing it in C is not something anyone would/should do.

And using a function like isdigit() is actually way better than checking 
if the character is between '0' and '9', even in other languages. Since 
it actually also removes the possible risks that you might have a 
character set where they are not consecutive values. Your code is 
already making bad assumptions, and in most languages you are actually 
force to stick with those assumptions.

In C, you are not, and should actually not write this kind of code. It 
is potentially bad and non-portable in all kind of weird ways.

That is why you have libraries that provide the proper evaluation of 
such issues, and which makes the code safer.

So in the end, I definitely think C does this better than your other 
languages selected.

(And yes, my silly example of converting a character to a binary value 
also suffers from the potential bad non-portability which was pointed 
out. But I was just trying to find an example where expressing integer 
values as characters actually was helpful, and not bad. Probably should 
try to think of other examples, if we really want to continue this...)

   Johnny