Hi,

1. does the world need a "new" C ?
-> http://thedev.nhi1.de/theKernel/main/managed-object.htm

2. is one compiler enough ?
-> http://thedev.nhi1.de/theCompiler/main/alc-compiler.htm

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

It’s called “Rust”.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 5 Jul 2024 02:30:34 -0500, BGB wrote:

On 7/4/2024 8:05 PM, Lawrence D'Oliveiro wrote:

It’s called “Rust”.

If anything, I suspect may make sense to go a different direction:
Not to a bigger language, but to a more narrowly defined language.

I think we already have enough of C. The only way forward is outward--
rethink the whole problem from a different angle.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 05 Jul 2024 01:09:37 -0700, Keith Thompson wrote:

(Ada, for example, has both arrays of arrays and multidimensional arrays
as distinct language features, using a(i)(j) to index the former and
a(i,j) to index the latter.)

Algol 68 had it before that. It also had a “rowing” coercion, to convert a value of type T to type “row of T” (as a single-element array, of course).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 5 Jul 2024 02:30:34 -0500
BGB <[email protected]> wrote:

On 7/4/2024 8:05 PM, Lawrence D'Oliveiro wrote:

It’s called “Rust”.

If anything, I suspect may make sense to go a different direction:
Not to a bigger language, but to a more narrowly defined language.

i am cautiously hopeful for Odin (odin-lang.org) which is taking that exact approach

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 5 Jul 2024 14:31:44 +0100, bart wrote:

C also is the only language that is supposed to work on any kind of
processor ...

I don’t think there is anything innate in the design of C to ensure that.
It was simply its popularity that meant it was usually the first language implemented on a new processor.

For example, C assumes byte addressability. So that causes awkwardness on architectures like the PDP-10, for example. It just so happened such architectures became extinct at about the time the rise of 8-bit microprocessors (and their more advanced successors) made byte-
addressability essentially universal.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 05 Jul 2024 01:09:37 -0700, Keith Thompson wrote:

(Ada, for example, has both arrays of arrays and multidimensional arrays
as distinct language features, using a(i)(j) to index the former and
a(i,j) to index the latter.)

And also the option for a lower bound other than zero.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 05 Jul 2024 19:00:58 -0700, Keith Thompson wrote:

C assumes byte addressibility, but it doesn't assume that bytes are 8
bits.

The PDP-10 had 36-bit words and could operate on bit fields of any size
from 1 to 36 bits.

But it couldn’t address them.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 05 Jul 2024 11:46:38 -0700, Keith Thompson wrote:

No, arrays are not pointers.

Except array indexing is designed to be indistinguishable from pointer arithmetic.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 6 Jul 2024 21:34:29 -0400, James Kuyper wrote:

On many platforms, if _Alignof(type) is less than the word size, then a
C pointer to that type is implemented as the combination of the machine address of the correct word, combined with an offset within that word of
the first byte of that object.

Which is a terrific idea, except it cannot be carried to its logical
conclusion (addressing of arbitrarily-aligned dynamically-defined
bitfields) because of the requirement in the C spec that the size of a “byte” be at least 8 bits.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 06 Jul 2024 15:38:14 -0700, Keith Thompson wrote:

BGB <[email protected]> writes:

... in the 1D case, an array can be seen as functionally an
implicitly defined pointer ...

No, there is no implicitly defined pointer.

...

If you evaluate the expression `array_object` in most contexts, it's implicitly converted to a pointer *value*, pointing to the 0th element
of the array object. There is still no implicit pointer object.

The OP said “pointer”, not “pointer object” or “pointer value”. Not sure
what hair you are trying to split here.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 6 Jul 2024 19:53:56 +0100, bart wrote:

On 06/07/2024 19:28, James Kuyper wrote:

... an expression that has type "array of type" is
converted to an expression with type "pointer to type" that points to
the initial element of the array object ..." (6.3.2.1p3).

This is really, really pedantic. Even gcc doesn't get it right in that
case, because if I try and compile this:

int a, b

Missing a semicolon?

a[b];

it says:

error: subscripted value is neither array nor pointer nor vector

Which is correct, since “a” is not an array of anything.

'Subscripting' I think we can agree is the same thing as 'indexing':
what those funny square brackets do.

It’s from mathematical usage, where selection of one from a sequence of values is done with an actual subscript.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 06 Jul 2024 15:23:47 -0700, Keith Thompson wrote:

Lawrence D'Oliveiro <[email protected]d> writes:

On Fri, 05 Jul 2024 11:46:38 -0700, Keith Thompson wrote:

No, arrays are not pointers.

Except array indexing is designed to be indistinguishable from pointer
arithmetic.

No, arrays are not pointers.

Can you point out any situation where this construct

&a[b]

might be valid, but this

(a + b)

(with the same declarations of “a” and “b”) might not?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 10 Jul 2024 03:16:18 -0400, James Kuyper wrote:

On 7/9/24 20:57, Lawrence D'Oliveiro wrote:

On Sat, 6 Jul 2024 21:34:29 -0400, James Kuyper wrote:

On many platforms, if _Alignof(type) is less than the word size, then
a C pointer to that type is implemented as the combination of the
machine address of the correct word, combined with an offset within
that word of the first byte of that object.

Which is a terrific idea, except it cannot be carried to its logical
conclusion (addressing of arbitrarily-aligned dynamically-defined
bitfields) because of the requirement in the C spec that the size of a
“byte” be at least 8 bits.

I will grant you that I failed to mention the fact that this is a
feasible way of implementing C only on platforms with a word size of 16
bits or longer.

Don’t you think C needs a better way of handling bitfields than shift-and- mask? Many architectures have bitfield instructions, but C cannot easily
make use of them without the ability to have arbitrarily-bit-aligned
pointers.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 18 Jul 2024 18:01:21 +0200, David Brown <[email protected]> wrote in <v7be8i$2g3q4$[email protected]>:

On 18/07/2024 15:00, Bart wrote:

On 18/07/2024 13:41, David Brown wrote:

[snip]

You are trying to be too smart here, IMHO - the compiler's job is to
let the programmer be smart.  It's always nice to have optimisations,
but not at the expense of correctness.

That's an odd remark from a devotee of gcc. Your usual attitude is to
let the programmer write code in the most natural manner, and let a
smart optimising compiler sort it out.

Touché :-)

Compilers can get smarter once you have them simple and correct. /Too/
smart - generating efficient but sometimes incorrect code - is not helpful.

I was a radioman in the USCG in the days of yore, where we would strive
for "secure, reliable, rapid" communications...in that order.

The same epithets could be applied to software.

--
-v

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)