On 2023-03-27 14:27, Simon Clubley wrote:
> On 2023-03-25, Scott Dorsey <kludge@panix.com> wrote:
>> bill <bill.gunshannon@gmail.com> wrote:
>>> I knew there was. I just find it funny that everyone holds that
>>> idea up as the very worst thing in C and yet, as you said, it was
>>> the industry standard long before C came around. Had C done it
>>> differently I am sure people would have bitched about abandoning
>>> the current standard.
>>
>> Quite possibly, but they would have had a lot fewer buffer overrun
>> vulnerabilities while doing so.
>>
>> I am a big fan of C and I definitely think null-terminated strings
>> were a mistake. There are syntax issues in C that I don't like, but
>> there is nothing in the same order of magnitude as null terminated
>> strings.
>>
>> But, at the time C was made, the notion that people would attempt to
>> deliberately cause software to malfunction seemed alien. It no longer
>> is, and as the world has changed the design decisions that seem appropriate
>> may have changed as well.
>
> In this very different world, gets() was once considered to be an acceptable
> function. :-)

That one is bad in a way that is hard to defend.

> In the more recent world, strncpy() is not always guaranteed to write
> a terminating null. Absolutely no excuse for that one :-(, especially
> given that it was supposed to be a fix for strcpy() (IIRC).

Agreed that this is sortof very annoying, but the workaround is
exceedingly simple. So I tend to just be annoyed by it, but it don't
really cause any problems if you just are aware of it.

> Other annoyances (apart from the null-terminated strings):
>
> = for assignment, versus == for comparison. (At least it's not PHP however,
> where you need to use === to get a sane comparison. :-))
>
> enums are integers, not a type.

Not sure I consider the enum thing to be much of a deal. Unless we
compare to Ada, which is the only language I've seen which really do
enums properly as its own type.

> Functions are public unless marked as static. I would have preferred them
> to be private by default with the need for a "public" keyword to make the
> function visible to the linker.

I could agree with that. Not that I think it's a big deal, and I can see
people becoming very annoyed had it been the other way around as well.

> signed characters are the default.

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

Johnny

On 2023-03-27 15:21, Arne Vajhøj wrote:
> On 3/27/2023 8:27 AM, Simon Clubley wrote:
>> = for assignment, versus == for comparison. (At least it's not PHP
>> however,
>> where you need to use === to get a sane comparison. :-))
>
> C == is not that great either.

[...]

Not sure I understand what your issue with C == was here.
You got a bunch of warnings for comparing mismatching types, which was
to be expected. I failed to see any problems beyond that.

This has nothing to do with == as such, but with with C type system.
This is how the type system is defined to work.

One might argue that this is bad, but in this case, I would say it's
pretty reasonable. (As opposed to the promotion of unsigned to signed
that can happen, which we had a thread about a couple of weeks ago...)

Johnny

On 3/27/2023 6:16 PM, Johnny Billquist wrote:
> On 2023-03-27 14:27, Simon Clubley wrote:
>> enums are integers, not a type.
>
> Not sure I consider the enum thing to be much of a deal. Unless we
> compare to Ada, which is the only language I've seen which really do
> enums properly as its own type.

Java enums are also very much non-int.

Arne

Johnny Billquist <bqt@softjar.se> wrote:
>On 2023-03-27 14:27, Simon Clubley wrote:
>> On 2023-03-25, Scott Dorsey <kludge@panix.com> wrote:
>>> bill <bill.gunshannon@gmail.com> wrote:
>>> I am a big fan of C and I definitely think null-terminated strings
>>> were a mistake. There are syntax issues in C that I don't like, but
>>> there is nothing in the same order of magnitude as null terminated
>>> strings.
>>>
>>> But, at the time C was made, the notion that people would attempt to
>>> deliberately cause software to malfunction seemed alien. It no longer
>>> is, and as the world has changed the design decisions that seem appropriate
>>> may have changed as well.
>>
>> In this very different world, gets() was once considered to be an acceptable
>> function. :-)
>
>That one is bad in a way that is hard to defend.

It was easy to defend in 1978. But we do not live in 1978 anymore.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 3/27/2023 6:19 PM, Johnny Billquist wrote:
> On 2023-03-27 15:21, Arne Vajhøj wrote:
>> On 3/27/2023 8:27 AM, Simon Clubley wrote:
>>> = for assignment, versus == for comparison. (At least it's not PHP
>>> however,
>>> where you need to use === to get a sane comparison. :-))
>>
>> C == is not that great either.
>
> [...]
>
> Not sure I understand what your issue with C == was here.
> You got a bunch of warnings for comparing mismatching types, which was
> to be expected. I failed to see any problems beyond that.

It gave warnings on zero int comparison with string and NULL. I
would prefer an error.

It accepted non-zero int comparison with string and NULL. I would like
an error.

It accepted int comparison with TRUE/FALSE. I would like
an error.

> This has nothing to do with == as such, but with with C type system.
> This is how the type system is defined to work.

Yes - a lot of it is due to the type system.

Arne

On 3/27/2023 6:46 PM, Arne Vajhøj wrote:
> On 3/27/2023 6:16 PM, Johnny Billquist wrote:
>> On 2023-03-27 14:27, Simon Clubley wrote:
>>> enums are integers, not a type.
>>
>> Not sure I consider the enum thing to be much of a deal. Unless we
>> compare to Ada, which is the only language I've seen which really do
>> enums properly as its own type.
>
> Java enums are also very much non-int.

And some languages require some "arm twisting"
to make enums work like integers.

VMS Pascal:

program enumchk(input,output);

type
direction = (north, south, west, east);
color = (red, green, blue, yellow);
material = (wood, iron, concrete);

var
d : direction;
c : color;
m : material;

begin
d := west;
c := green;
m := (ord(d) div ord(c))::material;
writeln(m);
end.

and C#:

using System;

namespace EnumChk
{ enum Direction { North, South, West, East }
enum Color { Red, Green, Blue, Yello }
enum Material { Wood, Iron, Concrete }
public class Program
{
public static void Main(string[] args)
{
Direction d = Direction.West;
Color c = Color.Green;
Material m = (Material)((int)d / (int)c);
Console.WriteLine(m);
Console.ReadKey();
}
}
}

both write concrete (different case), but one could
argue that the programmer asked for it.

Arne

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)

But I also happen to agree zero terminated strings are evil.
--
Tactical Nuclear Kittens

On 2023-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 3/27/2023 6:19 PM, Johnny Billquist wrote:
>> On 2023-03-27 15:21, Arne Vajhøj wrote:
>>> On 3/27/2023 8:27 AM, Simon Clubley wrote:
>>>> = for assignment, versus == for comparison. (At least it's not PHP
>>>> however,
>>>> where you need to use === to get a sane comparison. :-))
>>>
>>> C == is not that great either.
>>
>> [...]
>>
>> Not sure I understand what your issue with C == was here.
>> You got a bunch of warnings for comparing mismatching types, which was
>> to be expected. I failed to see any problems beyond that.
>
> It gave warnings on zero int comparison with string and NULL. I
> would prefer an error.
>

Agreed, but you can at least turn warnings into errors in your build
procedures to force people to fix the warnings.

In Linux land, I _always_ use -Werror and the DEC C compiler has a
comparable qualifier as well.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-03-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
> m := (ord(d) div ord(c))::material;

Anyone writing _that_ line of code deserves to have their keyboard
permanently taken away from them. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

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.

Arne

In article <tvs23c$37d4e$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> [snip]
>
>In this very different world, gets() was once considered to be an acceptable
>function. :-)

Hey, it was finally removed from the C standard!

>In the more recent world, strncpy() is not always guaranteed to write
>a terminating null. Absolutely no excuse for that one :-(, especially
>given that it was supposed to be a fix for strcpy() (IIRC).

I agree with you, but this is not why strncpy() was introduced.
The name here is bad, but it was really intended for copying
string-like data into fixed-width _fields_ in data structures
(such as directory entries in the filesystem structures that are
written to secondary storage).

It has other patholical behavior, too: in particular, it touches
every byte in its output argument, regardless if the source is
shorter than that or not.

Modern replacements, like strlcpy/strlcat, are generally
preferable.

>Other annoyances (apart from the null-terminated strings):
>
>= for assignment, versus == for comparison. (At least it's not PHP however,
>where you need to use === to get a sane comparison. :-))

I mostly agree; syntax that can disambiguate between assignment
and comparison is better in a language like C that is loose in
the sense of allowing almost any expression in a boolean
context.

More modern languages "fix" this by just not punning arbitrary
arithmetic expressions to bools.

>enums are integers, not a type.

+1e6

>Functions are public unless marked as static. I would have preferred them
>to be private by default with the need for a "public" keyword to make the
>function visible to the linker.

Absolutely; same for data.

>signed characters are the default.

As Johnny pointed out, it's even worse! This is implementation
defined.

- Dan C.

On 2023-03-28 00:59, Arne Vajhøj wrote:
> On 3/27/2023 6:19 PM, Johnny Billquist wrote:
>> On 2023-03-27 15:21, Arne Vajhøj wrote:
>>> On 3/27/2023 8:27 AM, Simon Clubley wrote:
>>>> = for assignment, versus == for comparison. (At least it's not PHP
>>>> however,
>>>> where you need to use === to get a sane comparison. :-))
>>>
>>> C == is not that great either.
>>
>> [...]
>>
>> Not sure I understand what your issue with C == was here.
>> You got a bunch of warnings for comparing mismatching types, which was
>> to be expected. I failed to see any problems beyond that.
>
> It gave warnings on zero int comparison with string and NULL. I
> would prefer an error.
>
> It accepted non-zero int comparison with string and NULL. I would like
> an error.
>
> It accepted int comparison with TRUE/FALSE. I would like
> an error.

Ah. So your complaint was about that. Well, it's not completely unheard
of to actually do such comparisons.
One need to understand that in C, "string" is just syntactic sugar.
When you have a string, in C all you have is an address. And an address
is a number.

So while it seems unlikely that you want to compare the two, it's
possibly something you'd want, hence warning. Same with NULL. It's just
an address, which is a number.

As Simon pointed out, you can request that such warnings be treated as
errors if you want to. But for some, it might actually be very intentional.

>> This has nothing to do with == as such, but with with C type system.
>> This is how the type system is defined to work.
>
> Yes - a lot of it is due to the type system.

And I think that in this case, it's not completely unreasonable how it
handles things. I consider a warning to be a good thing here. It might
be what the author intended. If so, he might want to rephrase it to not
get the warnings, or else consider the warnings as something flagging a
potential error.

It is not absolutely certain that this actually is an error. The author
needs to figure that out. The compiler can not.

Johnny

On 2023-03-28 00:46, Arne Vajhøj wrote:
> On 3/27/2023 6:16 PM, Johnny Billquist wrote:
>> On 2023-03-27 14:27, Simon Clubley wrote:
>>> enums are integers, not a type.
>>
>> Not sure I consider the enum thing to be much of a deal. Unless we
>> compare to Ada, which is the only language I've seen which really do
>> enums properly as its own type.
>
> Java enums are also very much non-int.

I can't remember Java enough to be sure, but I don't think they went as
far as Ada. What happens in Java if you print out the value of an enum
variable? Can you loop over it, and that is a loop that does not have an
integer loop counting? Can you read values into an enum, and do you then
type in the possible enums or else get an error? Can you use enums as
indexing in arrays? And nowhere does any numberness of the whole thing
shines through?

I thought Java was rather C-like...

Johnny

On 2023-03-28 00:47, Scott Dorsey wrote:
> Johnny Billquist <bqt@softjar.se> wrote:
>> On 2023-03-27 14:27, Simon Clubley wrote:
>>> On 2023-03-25, Scott Dorsey <kludge@panix.com> wrote:
>>>> bill <bill.gunshannon@gmail.com> wrote:
>>>> I am a big fan of C and I definitely think null-terminated strings
>>>> were a mistake. There are syntax issues in C that I don't like, but
>>>> there is nothing in the same order of magnitude as null terminated
>>>> strings.
>>>>
>>>> But, at the time C was made, the notion that people would attempt to
>>>> deliberately cause software to malfunction seemed alien. It no longer
>>>> is, and as the world has changed the design decisions that seem appropriate
>>>> may have changed as well.
>>>
>>> In this very different world, gets() was once considered to be an acceptable
>>> function. :-)
>>
>> That one is bad in a way that is hard to defend.
>
> It was easy to defend in 1978. But we do not live in 1978 anymore.

I don't think it was defendable in 1978 either, but it was easy to use.

Johnny

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.

Johnny

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

bill

On 3/29/2023 11:37 AM, Johnny Billquist wrote:
> On 2023-03-28 00:46, Arne Vajhøj wrote:
>> On 3/27/2023 6:16 PM, Johnny Billquist wrote:
>>> On 2023-03-27 14:27, Simon Clubley wrote:
>>>> enums are integers, not a type.
>>>
>>> Not sure I consider the enum thing to be much of a deal. Unless we
>>> compare to Ada, which is the only language I've seen which really do
>>> enums properly as its own type.
>>
>> Java enums are also very much non-int.
>
> I can't remember Java enough to be sure, but I don't think they went as
> far as Ada. What happens in Java if you print out the value of an enum
> variable? Can you loop over it, and that is a loop that does not have an
> integer loop counting? Can you read values into an enum, and do you then
> type in the possible enums or else get an error? Can you use enums as
> indexing in arrays? And nowhere does any numberness of the whole thing
> shines through?
>
> I thought Java was rather C-like...

Java use curly brackets, has the traditional if/switch/for/while/do
control structures and has char/short/int/long/float/double simple
data types.

But besides that it does not have that much in common with C.

Java enum's are not int's. But there are certain possibilities
to do stuff if one really wants to.

Let me explain.

First the very basic:

public enum Direction {
North, South, West, East;
}

This is not a type with integer values 0,1,2,3 or 1,2,3,4.

The Java compiler generate something similar to
(not quite like this - I will come back to that):

public final class Direction extends Enum {
public static final Direction North = new Direction();
public static final Direction South = new Direction();
public static final Direction West = new Direction();
public static final Direction East = new Direction();
private Direction() {
}
}

So the values of the enum are really references/pointers to
dynamically allocated objects. Either 32 or 64 bit. And may
actually have different values in different applications due to
different memory usage when initialized.

They are very type safe though. It is not possible to assign
between different unrelated classes.

But some convenience features was added:
* a toString method that convert to String representation
* a values method that return an array of ordered values
that can be iterated over
* a valueOf method that convert from String representation

$ type Nice.java
public class Nice {
public static void main(String[] args) {
Direction d0 = Direction.West;
System.out.println(d0);
for(Direction d1 : Direction.values()) {
System.out.println("-" + d1);
}
Direction d2 = Direction.valueOf("West");
System.out.println(d2);
}
} $ javac Nice.java
$ java "Nice"
West
-North
-South
-West
-East
West

That array of values can of course be abused to convert
to and from int.

$ type Hack.java
import java.util.Arrays;

public class Hack {
public static void main(String[] args) {
Direction[] alld = Direction.values();
int ix = Arrays.asList(alld).indexOf(Direction.West);
System.out.println(ix);
System.out.println(alld[ix]);
}
} $ javac Hack.java
$ java "Hack"
2 West

But I don't think that is really bad. That is all
array functionality and has nothing to do with enum.

But worse is that to support the convenience methods then
the private constructor is not:

private Direction() {
}

but instead:

private Direction(String strval, int ordval) {
super(strval, ordval);
}

which opens up for some creative abuse of the internals
of Enum.

$ type DirtyHack.java
import java.lang.reflect.Field;

public class DirtyHack {
public static void main(String[] args) throws NoSuchFieldException,
SecurityException, IllegalArgumentException, IllegalAccessEx
ception {
Direction d = Direction.West;
Field f = d.getClass().getSuperclass().getDeclaredField("ordinal");
f.setAccessible(true);
int ix = (int)(Integer)f.get(d);
System.out.println(ix);
System.out.println(Direction.values()[ix]);
}
} $ javac DirtyHack.java
$ java "DirtyHack"
2 West

Nobody use those hacks in practice, because Java's
enum has support for having extra properties
because it is a class under the hood.

$ type XDirection.java
public enum XDirection {
North(1001),
South(1002),
West(1003),
East(1004);
private int n;
private XDirection(int n) {
this.n = n;
}
public String toString() {
return String.format("%s (%d)", super.toString(), n);
}
public int getN() {
return n;
}
} $ javac "XDirection.java"
$ type Adv.java
public class Adv {
public static void main(String[] args) {
XDirection d0 = XDirection.West;
System.out.println(d0 + " : " + d0.getN());
for(XDirection d1 : XDirection.values()) {
System.out.println("-" + d1 + " : " + d1.getN());
}
XDirection d2 = XDirection.valueOf("West");
System.out.println(d2 + " : " + d2.getN());
}
} $ javac Adv.java
$ java "Adv"
West (1003) : 1003
-North (1001) : 1001
-South (1002) : 1002
-West (1003) : 1003
-East (1004) : 1004
West (1003) : 1003

I think that sort of explains Java enum.

One last thing - array indexes in Java are always int (signed
32 bit integer), so enums cannot be used as array index.

Arne

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

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.

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

bill

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

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

I believe there are basically two groups of languages:

A) those where one can write both c=='A' and c==65
B) those where one can write c=='A' but c==65 gives a compile error and
has to be written as ord(c)==65

I find it more likely that group A will use 65 than group B.

Arne

On 4/12/2023 10:41 AM, Arne Vajhøj wrote:
> 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:
>>>>> 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.
>
> I believe there are basically two groups of languages:
>
> A) those where one can write both c=='A' and c==65
> B) those where one can write c=='A' but c==65 gives a compile error and
> has to be written as ord(c)==65
>
> I find it more likely that group A will use 65 than group B.

Examples of code:

$ type isint.c
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

static int isint(const char *s)
{ int res, i;
if((s == NULL) || (strlen(s) == 0))
{
res = FALSE;
}
else
{
res = TRUE;
for(i = 0; i < strlen(s); i++)
{
if((s[i] < '0') || ('9' < s[i]))
{
if((i != 0) || (s[i] != '-'))
{
res = FALSE;
}
}
}
}
return res;
}

static int isintx(const char *s)
{ int res, i;
if((s == NULL) || (strlen(s) == 0))
{
res = FALSE;
}
else
{
res = TRUE;
for(i = 0; i < strlen(s); i++)
{
if((s[i] < 48) || (57 < s[i]))
{
if((i != 0) || (s[i] != 45))
{
res = FALSE;
}
}
}
}
return res;
}

static void test(const char *s)
{ printf("\"%s\" : %d\n", s, isint(s));
printf("\"%s\" : %d\n", s, isintx(s));
}

int main(int argc, char *argv[])
{ test("123");
test("-123");
test("ABC");
test("123X");
test("");
return 0;
} $ cc isint
$ link isint
$ run isint
"123" : 1
"123" : 1
"-123" : 1
"-123" : 1
"ABC" : 0
"ABC" : 0
"123X" : 0
"123X" : 0
"" : 0
"" : 0
$ type isint.pas
program main(input,output);

type
pstr = varying [255] of char;

function isint(s : pstr) : boolean;

var
i : integer;
res : boolean;

begin
if length(s) = 0 then begin
res := false;
end else begin
res := true;
for i:= 1 to length(s) do begin
if (s[i] < '0') or ('9' < s[i]) then begin
if (i <> 1) or (s[i] <> '-') then begin
res := false;
end;
end;
end;
end;
isint := res;
end;

function isintx(s : pstr) : boolean;

var
i : integer;
res : boolean;

begin
if length(s) = 0 then begin
res := false;
end else begin
res := true;
for i:= 1 to length(s) do begin
if (ord(s[i]) < 48) or (57 < ord(s[i])) then begin
if (i <> 1) or (ord(s[i]) <> 45) then begin
res := false;
end;
end;
end;
end;
isintx := res;
end;

procedure test(s : pstr);

begin
writeln('"', s, '" : ', isint(s):1);
writeln('"', s, '" : ', isintx(s):1);
end;

begin
test('123');
test('-123');
test('ABC');
test('123X');
test('');
end.
$ pas isint
$ link isint
$ run isint
"123" : T
"123" : T
"-123" : T
"-123" : T
"ABC" : F
"ABC" : F
"123X" : F
"123X" : F
"" : F
"" : F
$ type isint.for
program main
call test('123')
call test('-123')
call test('ABC')
call test('123X')
call test('')
end
c subroutine test(s)
character*(*) s
logical*4 isint
logical*4 isintx
write(6,'(1x,1h",a,1h",3h : ,l1)') s,isint(s)
write(6,'(1x,1h",a,1h",3h : ,l1)') s,isintx(s)
return
end
c logical*4 function isint(s)
character*(*) s
integer*4 i
logical*4 res
if(len(s).eq.0) then
res = .false.
else
res = .true.
do 100 i = 1,len(s)
if((s(i:i).lt.'0').or.('9'.lt.s(i:i))) then
if((i.ne.1).or.(s(i:i).ne.'-')) then
res = .false.
end if
end if
100 continue
end if
isint = res
return
end
c logical*4 function isintx(s)
character*(*) s
integer*4 i
logical*4 res
if(len(s).eq.0) then
res = .false.
else
res = .true.
do 100 i = 1,len(s)
if((ichar(s(i:i)).lt.48).or.(57.lt.ichar(s(i:i)))) then
if((i.ne.1).or.(ichar(s(i:i)).ne.45)) then
res = .false.
end if
end if
100 continue
end if
isintx = res
return
end
$ for isint
$ link isint
$ run isint
"123" : T
"123" : T
"-123" : T
"-123" : T
"ABC" : F
"ABC" : F
"123X" : F
"123X" : F
"" : F
"" : F
$ type isint.bas
program main

external sub test(string)

call test("123")
call test("-123")
call test("ABC")
call test("123X")
call test("")

end program
! sub test(string s)

external integer function isint(string)
external integer function isintx(string)

print using '"' + s + '"' + " : ##", isint(s)
print using '"' + s + '"' + " : ##", isintx(s)

end sub
! function integer isint(string s)

declare integer i, res

if len(s) = 0 then
res = 0
else
res = -1
for i = 1 to len(s)
if (mid$(s, i, 1) < "1") or ("9" < mid$(s, i, 1)) then
if (i <> 1) or (mid$(s, i, 1) <> "-") then
res = 0
end if
end if
next i
end if
isint = res

end function
! function integer isintx(string s)

declare integer i, res

if len(s) = 0 then
res = 0
else
res = -1
for i = 1 to len(s)
if (asc(mid$(s, i, 1)) < 48) or (57 < asc(mid$(s, i, 1))) then
if (i <> 1) or (asc(mid$(s, i, 1)) <> 45) then
res = 0
end if
end if
next i
end if
isintx = res

end function
$ bas isint
$ link isint
$ run isint
"123" : -1
"123" : -1
"-123" : -1
"-123" : -1
"ABC" : 0
"ABC" : 0
"123X" : 0
"123X" : 0
"" : 0
"" : 0
$ type IsInt.java
public class IsInt {
private static boolean isInt(String s) {
boolean res;
if((s == null) || (s.length() == 0)) {
res = false;
} else {
res = true;
for(int i = 0; i < s.length(); i++) {
if((s.charAt(i) < '0') || ('9' < s.charAt(i))) {
if((i != 0) || (s.charAt(i) != '-')) {
res = false;
}
}
}
}
return res;
}
private static boolean isIntX(String s) {
boolean res;
if((s == null) || (s.length() == 0)) {
res = false;
} else {
res = true;
for(int i = 0; i < s.length(); i++) {
if((s.charAt(i) < 48) || (57 < s.charAt(i))) {
if((i != 0) || (s.charAt(i) != 45)) {
res = false;
}
}
}
}
return res;
}
private static void test(String s) {
System.out.printf("\"%s\" : %b\n", s, isInt(s));
System.out.printf("\"%s\" : %b\n", s, isIntX(s));
}
public static void main(String[] args) throws Exception {
test("123");
test("-123");
test("ABC");
test("123X");
test("");
}
}
Click here to read the complete article

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

Why, used the 'space parity' moby, of course.

https://sysovl.info/reference_prime_drb_ecs.html

It's ISO-8859-1 turned upside down.

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

The reason is alternately given as "compatibility with the CCC/Honeywell
family", "because the teletypes typically ran that way", etc. But the
reason it never got changed has to be because the second motto of Prime:
"And COMPATIBILITY shall Rule Forever". (With apologies to Mosley
Meer.)

De

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

On 2023-04-12 16:44, Arne Vajhøj wrote:
> On 4/12/2023 10:41 AM, Arne Vajhøj wrote:
>> 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:
>>>>>> 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.
>>
>> I believe there are basically two groups of languages:
>>
>> A) those where one can write both c=='A' and c==65
>> B) those where one can write c=='A' but c==65 gives a compile error
>> and has to be written as ord(c)==65
>>
>> I find it more likely that group A will use 65 than group B.
>
> Examples of code:

[...lots of code deleted...]

The problem with this is that it is very artificial, and designed to
prove your point.

I can just as well give a counter example.

Let's say you have a character that you know is a digit, and you want to
convert it nicely to an integer.

In C, you'd do that like this:

x = c - '0';

In FORTRAN, BASIC, and god knows what else, you'd see:

x = ord(c) - 48;

Now, I'd say I've seen plenty more of that than your type of example.
And I've *never* seen:

x = ord(c) - ord('0');

And yes, of course, you can also in C do:

x = c - 48;

but I'd say that is less common, and a bad programmer will always manage
to write bad code, no matter what language. That don't mean the language
is bad. It is just more unclear, and in C there is no performance
reason, or anything else giving any reason why you would write 48, when
'0' is so much clearer what the intent is. And then it also works if you
use another character set, as long as all the digits have consecutive
code points.

Johnny