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

[Johnny Billquist]

On 2023-04-13 13:48, bill wrote:
> 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.

What C says is that the characters used for coding, which means the 
basic alphabet, numbers, special characters, and so on, are required to 
be positive, no matter what kind of type a char is (signed or unsigned). 
For other characters, as well as how many bits a char actually is, is 
implementation defined in C. So if you use Latin-1, any of those (extra) 
characters might be represented as a negative number in a char, just as 
well as a positive number. And they are both correct according to the 
standard.

And then you brought up Primos, which appears to have been using mark 
parity for characters, and I pointed out that this was also rather true 
of old PDP-8 and PDP-11 systems. And then you somehow got that to be 
about memory parity, while I was talking about serial communication.

At this point, it feels like we've gotten lost in what the point was.

   Johnny