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

[Johnny Billquist]

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.

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.

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

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.

   Johnny