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

[Arne Vajhøj]

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.

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

I suspect that you are correct that x = c - '0' is more common
than x = c - 48 in C and x = ord(c) - ord('0') is less common
than x = ord(c) - 48 in more type safe languages.

But the construct should be very rare overall as most languages
has easy to use and efficient builtin methods for that.

(and no it is not quite the same for checking if in digit range
as doing conversion and check for error and regex are a bit
heavy tools for the task).

Arne