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

[Johnny Billquist]

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

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.

   Johnny