Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #383809 > unrolled thread

Re: A Famous Security Bug

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-20 18:54 +0000
    Re: A Famous Security Bug scott@slp53.sl.home (Scott Lurndal) - 2024-03-20 19:38 +0000
      Re: A Famous Security Bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-20 14:20 -0700
        Re: A Famous Security Bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-20 14:23 -0700
    Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-21 16:13 +0100
      Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-21 17:41 +0000
        Re: A Famous Security Bug "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-21 12:37 -0700
          Re: A Famous Security Bug scott@slp53.sl.home (Scott Lurndal) - 2024-03-21 20:21 +0000
            Re: A Famous Security Bug "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-21 14:31 -0700
              Re: A Famous Security Bug scott@slp53.sl.home (Scott Lurndal) - 2024-03-21 23:19 +0000
                Re: A Famous Security Bug "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-21 17:38 -0700
                  Re: A Famous Security Bug "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-22 12:39 -0700
        Re: A Famous Security Bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-21 13:46 -0700
          Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-22 15:50 +0000
            Re: A Famous Security Bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-22 09:31 -0700
              Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-22 17:20 +0000
                Re: A Famous Security Bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-22 13:38 -0400
                  Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-22 19:27 +0000
                Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-22 19:13 +0100
                Re: A Famous Security Bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-22 11:21 -0700
                  Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-22 19:43 +0000
                    Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-23 16:36 +0100
                      Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-23 16:07 +0000
                        Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-23 18:58 +0100
                          Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-24 01:23 +0000
                        Re: A Famous Security Bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-23 12:51 -0400
                          Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-24 05:50 +0000
                            Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-24 14:21 +0100
                              Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-24 16:02 +0000
                                Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-24 17:27 +0100
                                  Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-27 21:06 +0000
                                    Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-28 19:07 +0100
                                Re: A Famous Security Bug "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-24 12:45 -0700
            Re: A Famous Security Bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-22 13:05 -0400
            Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-22 18:42 +0100
              Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-22 18:55 +0000
                Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-22 21:26 +0100
          Re: A Famous Security Bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-22 12:35 -0400
            Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-22 17:28 +0000
              Re: A Famous Security Bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-22 13:38 -0400
        Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-22 13:51 +0100
    Re: A Famous Security Bug Anton Shepelev <anton.txt@gmail.moc> - 2024-03-21 21:13 +0300
      Re: A Famous Security Bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-21 12:42 -0700
      Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-21 20:21 +0000
        Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-22 14:38 +0100
          Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-22 15:33 +0000
            Re: A Famous Security Bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-22 13:15 -0400
            Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-22 18:50 +0100
              Re: A Famous Security Bug Richard Kettlewell <invalid@invalid.invalid> - 2024-03-23 09:20 +0000
                Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-23 16:06 +0000
                Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-23 17:08 +0100
                  Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-23 16:56 +0000
                Re: A Famous Security Bug Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-24 09:45 -0700
                  Re: A Famous Security Bug Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-24 17:53 +0000
                    Re: A Famous Security Bug Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-17 12:10 -0700
                      Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-04-18 10:20 +0200
                      Re: A Famous Security Bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-04-18 14:26 -0700
        Re: A Famous Security Bug Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-03-28 12:23 +0300
          Re: A Famous Security Bug scott@slp53.sl.home (Scott Lurndal) - 2024-03-28 14:12 +0000
      Re: A Famous Security Bug Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-22 07:50 -0700
      Re: A Famous Security Bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-22 13:14 -0400
        Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-22 21:41 +0000
          Re: A Famous Security Bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-22 16:30 -0700
            Re: A Famous Security Bug Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-23 00:09 +0000
              Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-23 17:25 +0100
                Re: A Famous Security Bug scott@slp53.sl.home (Scott Lurndal) - 2024-03-23 16:51 +0000
                Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-23 19:58 +0000
                  Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-24 14:42 +0100
          Re: A Famous Security Bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-23 03:26 -0400
            Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-23 11:26 +0000
              Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-23 17:51 +0100
                Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-23 21:21 +0000
                  Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-24 15:52 +0100
                    Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-24 19:56 +0000
                      Re: A Famous Security Bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-24 13:49 -0700
                        Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-24 23:38 +0100
                        Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-25 01:42 +0300
                          Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-25 09:37 +0100
                          Re: A Famous Security Bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-25 08:54 -0700
                        Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-24 23:07 +0000
                          Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-25 01:39 +0200
                            Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-25 02:12 +0000
                              Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-25 09:58 +0100
                                Re: A Famous Security Bug Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-25 13:26 +0000
                                  Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-25 15:43 +0200
                              Re: A Famous Security Bug scott@slp53.sl.home (Scott Lurndal) - 2024-03-25 17:21 +0000
                            Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-25 09:53 +0100
                              Re: A Famous Security Bug scott@slp53.sl.home (Scott Lurndal) - 2024-03-25 17:24 +0000
                      Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-24 23:43 +0100
                        Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-25 13:16 +0200
                          Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-25 13:26 +0100
                            Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-25 15:11 +0200
                              Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-25 16:30 +0100
                              Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-25 16:39 +0000
                            Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-25 16:06 +0000
                              Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-25 18:51 +0200
                                Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-25 18:10 +0000
                                  Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-25 21:01 +0100
                                    Re: A Famous Security Bug scott@slp53.sl.home (Scott Lurndal) - 2024-03-25 20:28 +0000
                                  Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-25 23:05 +0200
                                    Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-25 21:25 +0000
                                      Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-26 01:31 +0200
                                        Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-26 00:34 +0000
                              Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-25 19:07 +0100
                  Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-24 18:53 +0300
                    Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-24 18:58 +0000
                      Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-25 13:04 +0200
                        Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-25 13:24 +0200
                      Re: A Famous Security Bug David Brown <david.brown@hesbynett.no> - 2024-03-25 16:17 +0100
                      Re: A Famous Security Bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-28 06:14 -0400
              Re: A Famous Security Bug Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-23 11:44 -0700
              Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-24 17:22 +0300
              Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-24 17:26 +0300
                Re: A Famous Security Bug bart <bc@freeuk.com> - 2024-03-24 19:12 +0000
                  Re: A Famous Security Bug Michael S <already5chosen@yahoo.com> - 2024-03-24 22:33 +0300
              Re: A Famous Security Bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-03-28 05:52 -0400

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#383884

On 3/21/24 14:13, Anton Shepelev wrote:
...
> I think this behavior (of a C compiler) rather stupid.  In a
> low-level imperative language, the compiled program shall
> do whatever the programmer commands it to do.

C is NOT that low a level of language. The standard explicitly allows
implementations to use any method they find convenient to produce
observable behavior which is consistent with the requirements of the
standard. Despite describing how that behavior might be produced by the
abstract machine, it explicitly allows an implementation to achieve that
behavior by other means.

If you want to tell a system not only what a program must do, but also
how it must do it, you need to use a lower-level language than C. That's
not what C is for.

[toc] | [prev] | [next] | [standalone]

#383899

On 22/03/2024 17:14, James Kuyper wrote:
> On 3/21/24 14:13, Anton Shepelev wrote:
> ...
>> I think this behavior (of a C compiler) rather stupid.  In a
>> low-level imperative language, the compiled program shall
>> do whatever the programmer commands it to do.
> 
> C is NOT that low a level of language. The standard explicitly allows
> implementations to use any method they find convenient to produce
> observable behavior which is consistent with the requirements of the
> standard. Despite describing how that behavior might be produced by the
> abstract machine, it explicitly allows an implementation to achieve that
> behavior by other means.
> 
> If you want to tell a system not only what a program must do, but also
> how it must do it, you need to use a lower-level language than C.

Which one?

I don't think anyone seriously wants to switch to assembly for the sort 
of tasks they want to use C for.

I agree with AS that a program should do what it's told by the 
programmer and the compiler should not get too smart.

When /I/ implement such a language, then that's pretty much what happens.

However, people also expect a reasonable amount of optimisation, which 
can involve take some short-cuts or not doing precisely what the 
programmer wrote, in the detail.

So the line isn't clearly defined as to what is or isn't acceptable.

But in this example where somebody has clearly requested an object to be 
zeroed, ignoring that instruction has crossed the line to unacceptable IMO.

[toc] | [prev] | [next] | [standalone]

#383902

bart <bc@freeuk.com> writes:
> On 22/03/2024 17:14, James Kuyper wrote:
[...]
>> If you want to tell a system not only what a program must do, but
>> also how it must do it, you need to use a lower-level language than
>> C.
>
> Which one?

Good question.

> I don't think anyone seriously wants to switch to assembly for the
> sort of tasks they want to use C for.

Agreed.  What some people seem to be looking for is a language that's
about as portable as C, but where every language construct is required
to result in generated code that performs the specified operation.
There's a lot of handwaving in that description.  "C without
optimization", maybe?

I'm not aware that any such language exists, at least in the mainstream
(and I've looked at a *lot* of programming languages).  I conclude that
there just isn't enough demand for that kind of thing.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#383904

On 2024-03-22, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> bart <bc@freeuk.com> writes:
>> On 22/03/2024 17:14, James Kuyper wrote:
> [...]
>>> If you want to tell a system not only what a program must do, but
>>> also how it must do it, you need to use a lower-level language than
>>> C.
>>
>> Which one?
>
> Good question.
>
>> I don't think anyone seriously wants to switch to assembly for the
>> sort of tasks they want to use C for.
>
> Agreed.  What some people seem to be looking for is a language that's
> about as portable as C, but where every language construct is required
> to result in generated code that performs the specified operation.
> There's a lot of handwaving in that description.  "C without
> optimization", maybe?
>
> I'm not aware that any such language exists, at least in the mainstream
> (and I've looked at a *lot* of programming languages).  I conclude that
> there just isn't enough demand for that kind of thing.

I think you can more or less get something like that with the following
strategy:

- all memory accesses through pointers are performed as written.
- local variables are aggressively optimized into registers.
- basic optimizations:
  - constant folding, dead code elimination.
  - basic control flow ones: jump threading and the like.
  - basic data flow optimizations.
  - peephole, good instruction selection.

In that environment, the way the programmer writes the code is the rest
of the optimization. Want loop unrolling? Write it yourself.


-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#383927

On 23/03/2024 01:09, Kaz Kylheku wrote:
> On 2024-03-22, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> bart <bc@freeuk.com> writes:
>>> On 22/03/2024 17:14, James Kuyper wrote:
>> [...]
>>>> If you want to tell a system not only what a program must do, but
>>>> also how it must do it, you need to use a lower-level language than
>>>> C.
>>>
>>> Which one?
>>
>> Good question.

I have no answer here either.

>>
>>> I don't think anyone seriously wants to switch to assembly for the
>>> sort of tasks they want to use C for.

One of the stated motivations for creating C was to save people from 
writing code in assembly!

>>
>> Agreed.  What some people seem to be looking for is a language that's
>> about as portable as C, but where every language construct is required
>> to result in generated code that performs the specified operation.
>> There's a lot of handwaving in that description.  "C without
>> optimization", maybe?
>>
>> I'm not aware that any such language exists, at least in the mainstream
>> (and I've looked at a *lot* of programming languages).  I conclude that
>> there just isn't enough demand for that kind of thing.

I think lack of demand combines with it actually being an extremely 
difficult task.

Consider something as simple as "x++;" in C.  How could that be 
implemented?  Perhaps the cpu has an "increment" instruction.  Perhaps 
it has an "add immediate" instruction.  Perhaps it needs to load 1 into 
a register, then use an "add" instruction.  Perhaps "x" is in memory. 
Some cpus can execute an increment directly on the memory address as an 
atomic instruction.  Some can do so, but only using specific (and more 
expensive) instructions.  Some can't do it at all without locking 
mechanisms and synchronisation loops.

So what does this user of this mythical LLL expect when he/she writes 
"x++;" ?  If the language had been created in the days of 8086 on DOS, 
perhaps it would have been defined as an atomic operation - and now 
doing this atomically on an AArch64 device would be extremely inefficient.

The big trouble with saying that the compiler should "do what I say" is 
that people have very different ideas about what they mean when they 
write things.  You either have to have quite high-level and abstract 
definitions about meanings and give compilers a fair amount of freedom 
when implementing them (thus you get high-level languages defined by 
behaviours on abstract machines - like C and just about every other 
programming language), or you have to tie it tightly to the target 
processor (and you get assembly), or the language designer, the compiler 
implementers and the programmers all have to think exactly the same way 
(which really means one-person languages, like Bart's).

> 
> I think you can more or less get something like that with the following
> strategy:
> 
> - all memory accesses through pointers are performed as written.
> - local variables are aggressively optimized into registers.
> - basic optimizations:
>    - constant folding, dead code elimination.
>    - basic control flow ones: jump threading and the like.
>    - basic data flow optimizations.
>    - peephole, good instruction selection.
> 
> In that environment, the way the programmer writes the code is the rest
> of the optimization. Want loop unrolling? Write it yourself.
> 

You might like to try to formalise this.  You won't be the first to 
attempt it.  But you might be the first to succeed, because no one 
(AFAIK) has managed it so far.

[toc] | [prev] | [next] | [standalone]

#383929

David Brown <david.brown@hesbynett.no> writes:
>On 23/03/2024 01:09, Kaz Kylheku wrote:
>> On 2024-03-22, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 22/03/2024 17:14, James Kuyper wrote:

>Consider something as simple as "x++;" in C.  How could that be 
>implemented?  Perhaps the cpu has an "increment" instruction.  Perhaps 
>it has an "add immediate" instruction.  Perhaps it needs to load 1 into 
>a register, then use an "add" instruction.  Perhaps "x" is in memory. 
>Some cpus can execute an increment directly on the memory address as an 
>atomic instruction.  Some can do so, but only using specific (and more 
>expensive) instructions.  Some can't do it at all without locking 
>mechanisms and synchronisation loops.

And some can do it as a side effect of an indirect load, for
example autoindexing on the PDP-8.

[toc] | [prev] | [next] | [standalone]

#383937

On 23/03/2024 16:25, David Brown wrote:
> On 23/03/2024 01:09, Kaz Kylheku wrote:
>> On 2024-03-22, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

>>> I'm not aware that any such language exists, at least in the mainstream
>>> (and I've looked at a *lot* of programming languages).  I conclude that
>>> there just isn't enough demand for that kind of thing.
> 
> I think lack of demand combines with it actually being an extremely 
> difficult task.
> 
> Consider something as simple as "x++;" in C.  How could that be 
> implemented?  Perhaps the cpu has an "increment" instruction.  Perhaps 
> it has an "add immediate" instruction.  Perhaps it needs to load 1 into 
> a register, then use an "add" instruction.  Perhaps "x" is in memory. 
> Some cpus can execute an increment directly on the memory address as an 
> atomic instruction.  Some can do so, but only using specific (and more 
> expensive) instructions.  Some can't do it at all without locking 
> mechanisms and synchronisation loops.
> 
> So what does this user of this mythical LLL expect when he/she writes 
> "x++;" ?

This is not the issue the comes up in the OP (or the issue that was 
assumed as I don't think the OP has clarified).

There it is not about micro-managing the implementation of x++, but the 
compiler deciding it isn't needed at all.

[toc] | [prev] | [next] | [standalone]

#383952

On 23/03/2024 20:58, bart wrote:
> On 23/03/2024 16:25, David Brown wrote:
>> On 23/03/2024 01:09, Kaz Kylheku wrote:
>>> On 2024-03-22, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> 
>>>> I'm not aware that any such language exists, at least in the mainstream
>>>> (and I've looked at a *lot* of programming languages).  I conclude that
>>>> there just isn't enough demand for that kind of thing.
>>
>> I think lack of demand combines with it actually being an extremely 
>> difficult task.
>>
>> Consider something as simple as "x++;" in C.  How could that be 
>> implemented?  Perhaps the cpu has an "increment" instruction.  Perhaps 
>> it has an "add immediate" instruction.  Perhaps it needs to load 1 
>> into a register, then use an "add" instruction.  Perhaps "x" is in 
>> memory. Some cpus can execute an increment directly on the memory 
>> address as an atomic instruction.  Some can do so, but only using 
>> specific (and more expensive) instructions.  Some can't do it at all 
>> without locking mechanisms and synchronisation loops.
>>
>> So what does this user of this mythical LLL expect when he/she writes 
>> "x++;" ?
> 
> This is not the issue the comes up in the OP (or the issue that was 
> assumed as I don't think the OP has clarified).
> 

That is trivially true.  I was picking a simple example and showing how 
difficult it is to try to define a language where "the compiler does 
exactly what I tell it to do".  If it is that difficult to define the 
programmer's precise expectation of the behaviour of "x++;" at the 
lowest level, how could we hope to do it with anything like the OP's case?

It sounds easy to make lists of expected behaviour, like Kaz did and 
like you no doubt have (at least in your head, if not written down) for 
your own low-level language.  Such lists are totally subjective, and 
thus inappropriate for general languages usable by a range of people for 
a range of tasks.

> There it is not about micro-managing the implementation of x++, but the 
> compiler deciding it isn't needed at all.
> 

First you have to decide /exactly/ what you mean by "x++;", before you 
can decide if it is valid to remove it or not.

[toc] | [prev] | [next] | [standalone]

#383913

bart <bc@freeuk.com> writes:
> On 22/03/2024 17:14, James Kuyper wrote:
[...]
>> If you want to tell a system not only what a program must do, but
>> also how it must do it, you need to use a lower-level language than
>> C.
>
> Which one?

That's up to you. The point is, C is NOT that language.

> I don't think anyone seriously wants to switch to assembly for the
> sort of tasks they want to use C for.

Why not? Assembly provides the kind of control you're looking for; C
does not. If that kind of control is important to you, you have to find
a language which provides it. If not assembler or C, what would you use?

[toc] | [prev] | [next] | [standalone]

#383919

On 23/03/2024 07:26, James Kuyper wrote:
> bart <bc@freeuk.com> writes:
>> On 22/03/2024 17:14, James Kuyper wrote:
> [...]
>>> If you want to tell a system not only what a program must do, but
>>> also how it must do it, you need to use a lower-level language than
>>> C.
>>
>> Which one?
> 
> That's up to you. The point is, C is NOT that language.

I'm asking which /mainstream/ HLL is lower level than C. So specifically 
ruling out assembly.

If there is no such choice, then this is the problem: it has to be C or 
nothing.

>> I don't think anyone seriously wants to switch to assembly for the
>> sort of tasks they want to use C for.
> 
> Why not? Assembly provides the kind of control you're looking for; C
> does not. If that kind of control is important to you, you have to find
> a language which provides it. If not assembler or C, what would you use?

Among non-mainstream ones, my own would fit the bill. Since I write the 
implementations, I can ensure the compiler doesn't have a mind of its own.

However if somebody else tried to implement it, then I can't guarantee 
the same behaviour. This would need to somehow be enforced with a 
precise language spec, or mine would need to be a reference 
implementation with a lot of test cases.


-----------------

Take this program:

   #include <stdio.h>
   int main(void) {
       goto L;
       0x12345678;
   L:
       printf("Hello, World!\n");
   }

If I use my compiler, then that 12345678 pattern gets compiled into the 
binary (because it is loaded into a register then discarded). That means 
I can use that value as a marker or sentinel which can be searched for.

However no other compiler I tried will do that. If I instead change that 
line to:

     int a = 0x12345678;

then a tcc-compiled binary will contain that value. So will 
lccwin32-compiled (with a warning). But not DMC or gcc.

If I get rid of the 'goto' , then gcc-O0 will work, but still not DMC or 
gcc-O3.

Here I can use `volatile` to ensure that value stays in, but not if I 
put the 'goto' back in!

It's all too unpredictable.

[toc] | [prev] | [next] | [standalone]

#383928

On 23/03/2024 12:26, bart wrote:
> On 23/03/2024 07:26, James Kuyper wrote:
>> bart <bc@freeuk.com> writes:
>>> On 22/03/2024 17:14, James Kuyper wrote:
>> [...]
>>>> If you want to tell a system not only what a program must do, but
>>>> also how it must do it, you need to use a lower-level language than
>>>> C.
>>>
>>> Which one?
>>
>> That's up to you. The point is, C is NOT that language.
> 
> I'm asking which /mainstream/ HLL is lower level than C. So specifically 
> ruling out assembly.
> 
> If there is no such choice, then this is the problem: it has to be C or 
> nothing.

How much of a problem is it, really?

My field is probably the place where low level programming is most 
ubiquitous.  There are plenty of people who use assembly - for good 
reasons or for bad (or for reasons that some people think are good, 
other people think are bad).  C is the most common choice.

Other languages used for small systems embedded programming include C++, 
Ada, Forth, BASIC, Pascal, Lua, and Micropython.  Forth is the only one 
that could be argued as lower-level or more "directly translated" than C.

The trick to writing low-level code in C (or C++) is not to pretend that 
C is a "directly translated" language, or to fight with your compiler. 
It is to learn how to work /with/ your compiler and its optimisations to 
get what you need.  Complaining that "LTO broke my code" does not make 
your product work.  Arbitrarily disabling optimisations that you feel 
are "bad" or imagine to be non-conforming is just kicking the can down 
the road.  You learn what /actually/ works - as guaranteed by the C 
standards, or by your compiler.

Sometimes that means using compiler-specific or target-specific 
extensions.  That's okay.  No one ever suggested that pure C-standard C 
code was sufficient for all tasks.  C was designed to allow some coding 
to be done in a highly portable and re-usable manner, and also to 
support non-portable systems programming relying on the implementation, 
and this has not changed.  When I write code for low-level use on a 
specific microcontroller, I am not writing portable code anyway.

So what language is lower level than C?  GCC C (or clang C, or IAR C for 
the 8051, or any other specific C compiler).

How would /I/ ensure that after "memset(buffer, 0, sizeof(buffer));" 
that the buffer was really written with zeros?  I'd follow it with:

	asm ("" : "+m" (buffer));

That's a gcc extension, but it will guarantee that the buffer is cleared 
- without any other costs.

(Alternatively, I'd clear the memory using volatile writes, rather than 
memset.)

> 
>>> I don't think anyone seriously wants to switch to assembly for the
>>> sort of tasks they want to use C for.
>>
>> Why not? Assembly provides the kind of control you're looking for; C
>> does not. If that kind of control is important to you, you have to find
>> a language which provides it. If not assembler or C, what would you use?
> 
> Among non-mainstream ones, my own would fit the bill. Since I write the 
> implementations, I can ensure the compiler doesn't have a mind of its own.
> 
> However if somebody else tried to implement it, then I can't guarantee 
> the same behaviour. This would need to somehow be enforced with a 
> precise language spec, or mine would need to be a reference 
> implementation with a lot of test cases.
> 
> 
> -----------------
> 
> Take this program:
> 
>    #include <stdio.h>
>    int main(void) {
>        goto L;
>        0x12345678;
>    L:
>        printf("Hello, World!\n");
>    }
> 
> If I use my compiler, then that 12345678 pattern gets compiled into the 
> binary (because it is loaded into a register then discarded). That means 
> I can use that value as a marker or sentinel which can be searched for.
> 
> However no other compiler I tried will do that. If I instead change that 
> line to:
> 
>      int a = 0x12345678;
> 
> then a tcc-compiled binary will contain that value. So will 
> lccwin32-compiled (with a warning). But not DMC or gcc.
> 
> If I get rid of the 'goto' , then gcc-O0 will work, but still not DMC or 
> gcc-O3.
> 
> Here I can use `volatile` to ensure that value stays in, but not if I 
> put the 'goto' back in!
> 
> It's all too unpredictable.
> 

The /minimum/ requirements of the compiler are very predictable.  The 
details beyond that are not - which is completely as expected.  You are 
trying to achieve an effect that cannot be expressed in C, and thus it 
is folly to expect a simple way to achieve it with any C compiler.  You 
will find that with many C compilers you can get what you want, but you 
have to write it in a way that suits the compiler.  For gcc, you might 
do it by putting a const variable in an explicit linker section using a 
gcc-specific __attribute__.  Maybe you can get it by using a volatile 
and /not/ removing the "goto".

But if you want to do something that has no semantic meaning in the 
language you are using, you can't expect compilers to support a 
particular way to achieve this!

[toc] | [prev] | [next] | [standalone]

#383939

On 23/03/2024 16:51, David Brown wrote:
> On 23/03/2024 12:26, bart wrote:
>> On 23/03/2024 07:26, James Kuyper wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 22/03/2024 17:14, James Kuyper wrote:
>>> [...]
>>>>> If you want to tell a system not only what a program must do, but
>>>>> also how it must do it, you need to use a lower-level language than
>>>>> C.
>>>>
>>>> Which one?
>>>
>>> That's up to you. The point is, C is NOT that language.
>>
>> I'm asking which /mainstream/ HLL is lower level than C. So 
>> specifically ruling out assembly.
>>
>> If there is no such choice, then this is the problem: it has to be C 
>> or nothing.
> 
> How much of a problem is it, really?
> 
> My field is probably the place where low level programming is most 
> ubiquitous.  There are plenty of people who use assembly - for good 
> reasons or for bad (or for reasons that some people think are good, 
> other people think are bad).  C is the most common choice.
> 
> Other languages used for small systems embedded programming include C++, 
> Ada, Forth, BASIC, Pascal, Lua, and Micropython.  Forth is the only one 
> that could be argued as lower-level or more "directly translated" than C.

Well, Forth is certainly cruder than C (it's barely a language IMO). But 
I don't remember seeing anything in it resembling a type system that 
corresponds to the 'i8-i64 u8-u64 f32-f64' types typical in current 
hardware. (Imagine trying to create a precisely laid out struct.)

It is just too weird. I think I'd rather take my chances with C.

 > BASIC, ..., Lua, and Micropython.

Hmm, I think my own scripting language is better at low level than any 
of these. It supports those low-level types for a start. And I can do 
stuff like this:

    println peek(0x40'0000, u16):"m"

    fun peek(addr, t=byte) = makeref(addr, t)^

This displays 'MZ', the signature of the (low-)loaded EXE image on Windows

Possibly it is even better than C; is this little program valid (no UB) 
C, even when it is known that the program is low-loaded:

    #include <stdio.h>
    typedef unsigned char byte;

    int main(void) {
        printf("%c%c\n", *(byte*)0x400000, *(byte*)0x400001);
    }

This works on DMC, tcc, mcc, lccwin, but not gcc because that loads 
programs at high addresses. The problem being that the address involved, 
while belonging to the program, is outside of any C data objects.

[toc] | [prev] | [next] | [standalone]

#383955

On 23/03/2024 22:21, bart wrote:
> On 23/03/2024 16:51, David Brown wrote:
>> On 23/03/2024 12:26, bart wrote:
>>> On 23/03/2024 07:26, James Kuyper wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>> On 22/03/2024 17:14, James Kuyper wrote:
>>>> [...]
>>>>>> If you want to tell a system not only what a program must do, but
>>>>>> also how it must do it, you need to use a lower-level language than
>>>>>> C.
>>>>>
>>>>> Which one?
>>>>
>>>> That's up to you. The point is, C is NOT that language.
>>>
>>> I'm asking which /mainstream/ HLL is lower level than C. So 
>>> specifically ruling out assembly.
>>>
>>> If there is no such choice, then this is the problem: it has to be C 
>>> or nothing.
>>
>> How much of a problem is it, really?
>>
>> My field is probably the place where low level programming is most 
>> ubiquitous.  There are plenty of people who use assembly - for good 
>> reasons or for bad (or for reasons that some people think are good, 
>> other people think are bad).  C is the most common choice.
>>
>> Other languages used for small systems embedded programming include 
>> C++, Ada, Forth, BASIC, Pascal, Lua, and Micropython.  Forth is the 
>> only one that could be argued as lower-level or more "directly 
>> translated" than C.
> 
> Well, Forth is certainly cruder than C (it's barely a language IMO). But 
> I don't remember seeing anything in it resembling a type system that 
> corresponds to the 'i8-i64 u8-u64 f32-f64' types typical in current 
> hardware. (Imagine trying to create a precisely laid out struct.)

Forth can be considered a typeless language - you deal with cells (or 
double cells, etc.), which have contents but not types.  And you can 
define structs with specific layouts quite easily.  (Note that I've 
never tried this myself - my Forth experience is /very/ limited, and you 
will get much more accurate information in comp.lang.forth or another 
place Forth experts hang out.)

A key thing you miss, in comparison to C, is the type checking and the 
structured identifier syntax.

In C, if you have :

	struct foo {
		int32_t x;
		int8_t y;
		uint16_t z;
	};

	struct foo obj;

	obj.x = obj.y + obj.z;

then you access the fields as "obj.x", etc.  Your struct may or may not 
have padding, depending on the target and compiler (or compiler-specific 
extensions).  If "obj2" is an object of a different type, then "obj2.x" 
might be a different field or a compile-time error if that type has no 
field "x".


In Forth, you write (again, I could be inaccurate here) :

	struct
	4 field >x
	1 field >y
	2 field >z
	constant /foo

The names - including the punctuation (punctuation characters can be 
freely used in identifiers in Forth) - are arbitrary.  This is 
equivalent to :

	: >x 0 + ;
	: >y 4 + ;
	: >z 5 + ;
	: /foo 7 ;

You make your instance "obj" by :

	create obj /foo allot

which makes "obj" the address of a block of 7 bytes - but does not give 
it a type in any sense.  ("/foo" simply means "7").

The equivalent of "obj.x = obj.y + obj.z" would be :

	obj >y c@ obj >z w@ + obj >x l!

That is :

1. Put the address of obj on the stack.
2. Add 4 to it (the definition of >y)
3. Use that as an address and fetch the 8-bit value from that address, 
putting it on the stack.
4. Put the address of obj on the stack.
5. Add 5 to it (the definition of >z)
6. Use that as an address and fetch the 16-bit value from that address, 
putting it on the stack.
7. Add the top two values from the stack and put the result on the stack.
8. Put the address of obj on the stack.
9. Add 0 to it (the definition of >x)
10. Use that as an address and store the 32-bit value from the top of 
the stack to that address.


I'm assuming this Forth uses 32-bit stack cells, and ignoring 
signed/unsigned issues for simplicity.  There are, after all, better 
places to find Forth tutorials for the details.


At no point is the definition of the struct type attached to "obj".  In 
fact, there is no struct type - there's just some defined words for 
adding offsets to an address (or adding those values to anything else). 
You can just as well write "10 >y ." to do "printf("%i", 10 + 4);".


There's therefore also no connection between the field accessor words 
and the type, or any requirement that they are only used with the right 
kind of object.  On the other hand, suppose you wanted to dispense with 
storing the field "x" and calculate it as "p->y + p->z" every time you 
needed it.  In C, you'd write:

	int32_t calc_x(const struct foo * p) { return p->x + p->y; }

and replace uses of "obj.x" with "calc_x(&obj)".

In Forth, you might have defined :

	: >x@ >x l@ ;
	: >y@ >y c@ ;
	: >z@ >z w@ ;

and used >x@ as your accessor for reading obj.x (as "obj >x@") in the 
rest of your code.  Now you can remove ">x" from the struct definition 
and write:

	: >x@ dup >y@ over >z@ + ;

and all your uses of "obj >x@" remain unchanged in the rest of your 
code, but now they calculate x on the fly.


This is all /way/ off-topic for comp.lang.c, but it's perhaps 
interesting to see a completely different way of doing things in a very 
different language.

And note that although Forth is often byte-compiled very directly to 
give you exactly the actions you specify in the source code, it is also 
sometimes compiled to machine code - using optimisations.

> 
> It is just too weird. I think I'd rather take my chances with C.

Forth does take some getting used to!

> 
>  > BASIC, ..., Lua, and Micropython.
> 
> Hmm, I think my own scripting language is better at low level than any 
> of these.

These all have one key advantage over your language - they are real 
languages, available for use by /other/ programmers for development of 
products.

> It supports those low-level types for a start. And I can do 
> stuff like this:
> 
>     println peek(0x40'0000, u16):"m"
> 
>     fun peek(addr, t=byte) = makeref(addr, t)^
> 
> This displays 'MZ', the signature of the (low-)loaded EXE image on Windows
> 
> Possibly it is even better than C; is this little program valid (no UB) 
> C, even when it is known that the program is low-loaded:
> 
>     #include <stdio.h>
>     typedef unsigned char byte;
> 
>     int main(void) {
>         printf("%c%c\n", *(byte*)0x400000, *(byte*)0x400001);
>     }
> 
> This works on DMC, tcc, mcc, lccwin, but not gcc because that loads 
> programs at high addresses. The problem being that the address involved, 
> while belonging to the program, is outside of any C data objects.
> 

I think you are being quite unreasonable in blaming gcc - or C - for 
generating code that cannot access that particular arbitrary address! 
The addresses accessible in a program are defined by the OS and the 
target environment, not the language or compiler.  And C has a perfectly 
good way of forcing access to addresses - use "volatile".

[toc] | [prev] | [next] | [standalone]

#383970

On 24/03/2024 14:52, David Brown wrote:
> On 23/03/2024 22:21, bart wrote:

>> Well, Forth is certainly cruder than C (it's barely a language IMO). 
>> But I don't remember seeing anything in it resembling a type system 
>> that corresponds to the 'i8-i64 u8-u64 f32-f64' types typical in 
>> current hardware. (Imagine trying to create a precisely laid out struct.)
> 
> Forth can be considered a typeless language - you deal with cells (or 
> double cells, etc.), which have contents but not types.  And you can 
> define structs with specific layouts quite easily.  (Note that I've 
> never tried this myself - my Forth experience is /very/ limited, and you 
> will get much more accurate information in comp.lang.forth or another 
> place Forth experts hang out.)
> 
> A key thing you miss, in comparison to C, is the type checking and the 
> structured identifier syntax.
> 
> In C, if you have :
> 
>      struct foo {
>          int32_t x;
>          int8_t y;
>          uint16_t z;
>      };
> 
>      struct foo obj;
> 
>      obj.x = obj.y + obj.z;
> 
> then you access the fields as "obj.x", etc.  Your struct may or may not 
> have padding, depending on the target and compiler (or compiler-specific 
> extensions).  If "obj2" is an object of a different type, then "obj2.x" 
> might be a different field or a compile-time error if that type has no 
> field "x".
> 
> 
> In Forth, you write (again, I could be inaccurate here) :
> 
>      struct
>      4 field >x
>      1 field >y
>      2 field >z
>      constant /foo

<...>

Thanks. You've demonstrated perfectly why I would never use Forth. I'd 
rather write in assembly.

But what people want are the conveniences and familiarity of a HLL, 
without the bloody-mindedness of an optimising C compiler.

> And note that although Forth is often byte-compiled very directly to 
> give you exactly the actions you specify in the source code, it is also 
> sometimes compiled to machine code - using optimisations.
> 
>>
>> It is just too weird. I think I'd rather take my chances with C.
> 
> Forth does take some getting used to!
> 
>>
>>  > BASIC, ..., Lua, and Micropython.
>>
>> Hmm, I think my own scripting language is better at low level than any 
>> of these.
> 
> These all have one key advantage over your language - they are real 
> languages, available for use by /other/ programmers for development of 
> products.

My language exists. Anyone is welcome to reimplement elements of the 
design, since most script languages stink at low-level work or dealing 
with FFIs.

It is not necessary for me to provide a concrete implementation for 
others to use. But here's one expressed as C code for 64-bit Linux:

   https://github.com/sal55/langs/blob/master/qu.c

Build using:

   > gcc qu.c -oqu -lm -ldl -fno-builtin

or using:

   > tcc qu.c -o qu -lm -ldl -fdollars-in-identifiers

Run it like this:

   > ./qu -nosys hello

'hello.q' should contain something like like 'println "Hello, World"'.

The -nosys needed as it normally uses a WinAPI-based standard library.

It can't run the 'peek/MZ' example since EXE layouts on Linux are 
different, and, if using gcc, 0x400000 is an illegal address.

For something else, try creating test.q:

     type date = struct
         byte d,m
         u16 year
     end

    d := date(24,3,2024)

    println d, date.bytes

Run as './qu -nosys test'. I don't have docs however. BTW here is your 
Forth example:

     type foo1 = struct
         int32  x
         int8   y
         word16 z
     end

     type foo2 = struct $caligned
         int32  x
         int8   y
         word16 z
     end

     println foo1.bytes
     println foo2.bytes

There are two versions, one has no automatic padding, which is 7 bytes, 
and the other is 8 bytes in size.

>> This works on DMC, tcc, mcc, lccwin, but not gcc because that loads 
>> programs at high addresses. The problem being that the address 
>> involved, while belonging to the program, is outside of any C data 
>> objects.
>>
> 
> I think you are being quite unreasonable in blaming gcc - or C - for 
> generating code that cannot access that particular arbitrary address! 

There were two separate points here. One is that a gcc-compiled version 
won't work because exe images are not loaded at 0x40'0000. The other was 
me speculating whether the access to 0x40'0000, even when valid memory 
for this process, was UB in C.

[toc] | [prev] | [next] | [standalone]

#383973

bart <bc@freeuk.com> writes:
[...]
> But what people want are the conveniences and familiarity of a HLL,
> without the bloody-mindedness of an optimising C compiler.
[...]

Exactly which people want that?

The evidence suggests that, while some people undoubtedly want that (and
it's a perfectly legitimate desire), there isn't enough demand to induce
anyone to actually produce such a thing and for it to catch on.
Developers have had decades to define and implement the kind of language
you're talking about.  Why haven't they?

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#383979

On 24/03/2024 21:49, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
> [...]
>> But what people want are the conveniences and familiarity of a HLL,
>> without the bloody-mindedness of an optimising C compiler.
> [...]
> 
> Exactly which people want that?
> 
> The evidence suggests that, while some people undoubtedly want that (and
> it's a perfectly legitimate desire), there isn't enough demand to induce
> anyone to actually produce such a thing and for it to catch on.

I personally think (or speculate, if you feel the word is more 
appropriate given that I have no real evidence) that a major part of 
this is a lack of agreement on what optimisations these people want or 
don't want.  I expect Kaz and Bart would agree that they want C 
compilers to be required to generate code that does what they mean it to 
do, and be able to optimise within those requirements to do the required 
job as efficiently as possible.  But I expect they would disagree in 
many ways in regard to what they mean by it all - what optimisations are 
allowed, and what code /really/ means in their eyes.

The best we can reasonably hope for is for a carefully considered 
document that describes minimum requirements, and for compilers to 
provide flags to allow fine-tuning so that programmers can get the 
results they want.

And that is /exactly/ what we have with C and quality C compilers. 
Sure, none of this is perfect or an ideal fit for everyone and every 
task - but it is good enough that you'd need to come up with something 
quite extraordinary to make it attractive compared to C.

> Developers have had decades to define and implement the kind of language
> you're talking about.  Why haven't they?
> 

[toc] | [prev] | [next] | [standalone]

#383980

On Sun, 24 Mar 2024 13:49:43 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> bart <bc@freeuk.com> writes:
> [...]
> > But what people want are the conveniences and familiarity of a HLL,
> > without the bloody-mindedness of an optimising C compiler.  
> [...]
> 
> Exactly which people want that?
> 
> The evidence suggests that, while some people undoubtedly want that
> (and it's a perfectly legitimate desire), there isn't enough demand
> to induce anyone to actually produce such a thing and for it to catch
> on.

Such things are produced all the time. A yes, they fail to catch on.
The most recent [half-hearted] attempt that didn't realize yet that it
has no chance is called zig.

> Developers have had decades to define and implement the kind of
> language you're talking about.  Why haven't they?
> 

Because C is juggernaut?

[toc] | [prev] | [next] | [standalone]

#383992

On 24/03/2024 23:42, Michael S wrote:
> On Sun, 24 Mar 2024 13:49:43 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> 
>> bart <bc@freeuk.com> writes:
>> [...]
>>> But what people want are the conveniences and familiarity of a HLL,
>>> without the bloody-mindedness of an optimising C compiler.
>> [...]
>>
>> Exactly which people want that?
>>
>> The evidence suggests that, while some people undoubtedly want that
>> (and it's a perfectly legitimate desire), there isn't enough demand
>> to induce anyone to actually produce such a thing and for it to catch
>> on.
> 
> Such things are produced all the time. A yes, they fail to catch on.
> The most recent [half-hearted] attempt that didn't realize yet that it
> has no chance is called zig.
> 

Languages like this are usually better in some ways than C (there's 
plenty of scope for that with C - we can do a better job of designing a 
language now than 50 years ago, not least because we can expect more 
from tools than we could 50 years ago).

But they can never cover everything people want - people want 
contradictory things.  Thus for everyone (except perhaps the language 
designers themselves) such new languages have big disadvantages as well 
as big advantages, and they will be missing some key features, seen from 
that person's perspective.

And their execution models are invariably either only vaguely defined, 
or defined in terms of behaviour with an "as-if" rule to allow 
optimisation.  Which means they are no better than C for people who 
think compilers should be blind translators.  (And it also means that 
they will be no worse than C for people who understand more about 
programming languages and compilers, and for those that either don't 
know or don't care.)


Zig is a language I've looked at, and it does have some nice things. 
But it will be a /long/ time before it is something I could consider 
using for my work, so it would be hobby only.  And of course it has made 
some design decisions that I think are wrong, and are a big step down 
from the current leading alternative to C in many fields - C++.


>> Developers have had decades to define and implement the kind of
>> language you're talking about.  Why haven't they?
>>
> 
> Because C is juggernaut?
> 

Yes, it has a /huge/ momentum.  That means that even if a new language 
comes along that is better than C in every way, it has to be /much/ 
better to make it worth the effort to change.  Rust is making a fair 
stab at this - it is no easy job.

[toc] | [prev] | [next] | [standalone]

#384004

Michael S <already5chosen@yahoo.com> writes:
> On Sun, 24 Mar 2024 13:49:43 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>> > But what people want are the conveniences and familiarity of a HLL,
>> > without the bloody-mindedness of an optimising C compiler.  
>> [...]
>> 
>> Exactly which people want that?
>> 
>> The evidence suggests that, while some people undoubtedly want that
>> (and it's a perfectly legitimate desire), there isn't enough demand
>> to induce anyone to actually produce such a thing and for it to catch
>> on.
>
> Such things are produced all the time. A yes, they fail to catch on.
> The most recent [half-hearted] attempt that didn't realize yet that it
> has no chance is called zig.

Does Zig have those characteristics because its language definition say
so, or because there's a single implementation that happens to work that
way?  I took a quick look at the documentation and didn't see anything
definitive.

>> Developers have had decades to define and implement the kind of
>> language you're talking about.  Why haven't they?
>> 
>
> Because C is juggernaut?

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#383982

On 24/03/2024 20:49, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
> [...]
>> But what people want are the conveniences and familiarity of a HLL,
>> without the bloody-mindedness of an optimising C compiler.
> [...]
> 
> Exactly which people want that?
> 
> The evidence suggests that, while some people undoubtedly want that (and
> it's a perfectly legitimate desire), there isn't enough demand to induce
> anyone to actually produce such a thing and for it to catch on.
> Developers have had decades to define and implement the kind of language
> you're talking about.  Why haven't they?
> 
Perhaps many settle for using C but using a lesser C compiler or one 
with optimisation turned off.

The language still has the UBs of C, whereas people want it more 
implementation-defined, but a weaker compiler is less likely to leverage 
that UB to do unexpected things or to wreck somebody's expections of how 
a piece of code will behave.

With the dominance of C it's hard to produce a competing language, 
especially it it looks like C. And people still want all the 
optimisations that are possible without taking advantage of UB of 
needing to delete chunks of the user's code.

This is probably a similar discussion to that of makefiles; why isn't 
there a competing build system?

C is often used as an intermediate language by compilers. There is a 
source language where a lot of this stuff is well-defined by its spec. 
There is a known target, or a small range of targets, on which the 
behaviour is also well-defined.

However, in the middle you have C, where much of it isn't well-defined! 
People want a language which is like the hypothetical one discussed, one 
that doesn't get 'in the way' with its crazy ideas. But now it's either 
going to be a lot work to generate C code that behaves as expected, or 
they have to settle for a non-optimising compiler and  cross their fingers.

[toc] | [prev] | [next] | [standalone]

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web