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

[bill]

On 4/12/2023 9:37 PM, Johnny Billquist wrote:
> On 2023-04-12 18:26, bill wrote:
>> On 4/7/2023 4:58 PM, Johnny Billquist wrote:
>>> On 2023-04-03 14:31, bill wrote:
>>>>> 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.
>>>
>>> XXDP (the PDP-11 diagnostics) are the oldest PDP-11 software I have 
>>> been dealing with. A lot of code in there assumes you are running 
>>> with mark parity, which basically means all output characters will 
>>> always have the high bit set.
>>
>> Yes, but there is a big difference between communications parity and
>> memory parity.
> 
> Uh? Who mentioned memory parity? Not me.

I did.

> This has all been communication, as such. But the data as such are 
> generated already with mark parity by compilers. It's not something 
> added by any hardware. And the parsing of received data is also done 
> with the assumption that it was received with mark parity, and that is 
> never stripped away.

I thought we were talking about C and it's limitations and the concept
of data types.  And then there was the thing about signed and unsigned
chars.  And that led to my mentioning a case where not only are chars
(kinda) signed but they always have the high order bit on. And how that
posed a problem porting software because so much of the C software being
moved around (in places like comp.sources.xxx) were written with the
assumption that chars fell in the 0-127 value range.

bill