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

[bill]

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

Yes, other languages had people doing this, too.  But, at the time of
Primos and Primix there weren't a lot of people writing code intended
to be portable in those other languages.  Most of the comp.sources.xxx
entries were C and Unix based.

> 
> 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 saw a number of programs with parsers that relied on the value of
ASCII being between 0 and 127.  That was never the case with Pr1me.
Not even under Primix.

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

> 
> Very annoying, but you just have to live with it, I guess. And most 
> PDP-8 software is older, and almost all of it assumes mark parity 
> everywhere. And I noticed when reading documentation and drawings on the 
> ASR33 that the ones DEC used unconditionally used mark parity as well. 
> So all data from the terminal have the high bit set as well. So it seems 
> to have been what DEC always used back then.
> 
> No, the hardware in the form of the serial lines themselves usually did 
> not force it, although I'm pretty sure some of them could be set to 7M1. 
> But hardware in the form of terminals certainly did.

But that is only during communications.  I am not aware of any program
that computed the value of a character in transit and cared what that
value was.  Pr1me set the values in their firmware forcing all programs
in any language to deal with an ASCII set that had values from 128 to
255.  If they  had survived , I wonder what they would have done when
8bit ASCII came about?

And the truly sad part is probably that there really was no reason for
it.  When Bill Lenhart was working on native mode Unix for the Pr1me
50-series he "fixed" it in the microcode.  Sadly, Pr1me pulled the plug
on his work just before he was going to release it.

bill