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

[bill]

On 4/2/2023 8:50 PM, Johnny Billquist wrote:
> On 2023-03-29 19:51, bill wrote:
>> On 3/29/2023 11:42 AM, Johnny Billquist wrote:
>>> On 2023-03-28 14:16, Arne Vajhøj wrote:
>>>> On 3/28/2023 4:06 AM, Single Stage to Orbit wrote:
>>>>> On Tue, 2023-03-28 at 00:16 +0200, Johnny Billquist wrote:
>>>>>> Actually, this one is worse. char is implementation defined if it is
>>>>>> signed or not (really - the standard says so).
>>>>>> If you think/assume they are signed, you're asking for it...
>>>>>
>>>>> Which is why stdint.h (or cstdint) was invented with explicit types
>>>>> (uint8_t, uint64_t etc)
>>>>
>>>> They should be used.
>>>>
>>>> Just note that the spec says "These types are optional.", but
>>>> I suspect that all the common platforms has them.
>>>
>>> The thing is, char is very special. It is the only one that is 
>>> implementation defined if it is signed or unsigned. All the others 
>>> (short, int, long, long long) are by definition signed.
>>>
>>> So this goes a little outside of stdint.h as well. It's just that 
>>> char, for whatever reason, is more weird/implementation specific than 
>>> anything else in C.
>>
>> 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.

> 
> PDP-8, as well as very old PDP-11 software usually also used mark parity 
> on all characters. And as far as I know, the ASR-33 variant that DEC 
> used did this, which might be the reason for all software doing it.

I am not aware of any PDP-11 operating system where the charsets ASCII
values were 128 to 255 as opposed to 0 to 127.  Certainly none where it
was the hardware forcing it.

bill