On Saturday, 23 May 2020 at 13:18:38 UTC, Dibyendu Majumdar wrote:
> ...
>>
>> C missed some obviously great ideas. One is nested functions, which fit right in with C's semantics. The other is the fix for:
>>
>> https://www.digitalmars.com/articles/C-biggest-mistake.html
>
> I do not think it was a mistake at all. Treating pointers and arrays uniformly is one of the great innovations in C.

Yeah, because it is so hard to type:

int *ptr = &my_array[0] // instead of int *ptr = my_array;


I guess the benefit is that C developers don't get RSI for their pointer and arrays handling code.

>
> https://www.lysator.liu.se/c/bwk-on-pascal.html

Most of those issues were sorted out by the mid-80's, also PL/I dialects, BLISS, Ada and Modula-2 don't suffer from them.

Ironically, NEWP, a systems programming language 10 years older than C, still exists and Unisys uses its security features as means to sell ClearPath MCP against UNIX based OSes for goverment level security.

Whereas those that still use C get what they deserve,

https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/

"Expert Q&A: C#/C++/Rust WinRT Team"

https://mybuild.microsoft.com/sessions/f22a612d-0030-4e55-b389-2da0f99b8839

"Microsoft's Safe Systems Programming Languages Effort"

https://mybuild.microsoft.com/sessions/61de34c5-b111-4ece-928f-541854875862

And guess what Google is doing starting with Android 11,

> Platform hardening - We’ve expanded use of compiler-based sanitizers in security-critical components, including BoundSan, IntSan, CFI, and Shadow-Call Stack. We’re also enabling heap pointer tagging for apps targeting Android 11 or higher, to help apps catch memory issues in production. These hardening improvements may surface more repeatable/reproducible app crashes in your code, so please test your apps. We've used HWAsan to find and fix many memory errors in the system, and we now offer HWAsan-enabled system images to help you find such issues in your apps.

https://android-developers.googleblog.com/2020/02/Android-11-developer-preview.HTML

Which is just catchin up with what iOS, Solaris SPARC and Azure Sphere are already doing.

So is the trust on C developer's capabilites to actually write memory corruption free code.

On Saturday, 23 May 2020 at 14:33:02 UTC, Chris wrote:

>
> Deleting criticism is certainly not the right approach and will come back to bite you. Sometimes it's easier to just do the dishes than to come up with ever new excuses why you can't do the dishes. Why not write a new clean version of D?

Again, we aren't deleting criticism. If we were, 90% of your posts would have hit the bin by now. I repeat myself: criticism is welcome, the denigration of community members is not.

On Saturday, 23 May 2020 at 16:01:22 UTC, Mike Parker wrote:
> On Saturday, 23 May 2020 at 14:33:02 UTC, Chris wrote:
>
>>
>> Deleting criticism is certainly not the right approach and will come back to bite you. Sometimes it's easier to just do the dishes than to come up with ever new excuses why you can't do the dishes. Why not write a new clean version of D?
>
> Again, we aren't deleting criticism. If we were, 90% of your posts would have hit the bin by now. I repeat myself: criticism is welcome, the denigration of community members is not.

And I should add that if we weren't using a web interface to a newsgroup server, we would most likely have better moderation tools. We'd be able to edit posts. But all we can do is delete them.

On Saturday, 23 May 2020 at 16:03:13 UTC, Mike Parker wrote:
> And I should add that if we weren't using a web interface to a newsgroup server, we would most likely have better moderation tools. We'd be able to edit posts. But all we can do is delete them.

There's really no technical reason why you can't do that now, just editing the server database.

People with a local copy will still see the old one, of course, but that's just like how mailing list users like me don't see any deletion actions either.

On Friday, 22 May 2020 at 15:48:04 UTC, Timon Gehr wrote:
> Which is why they don't want to do that and instead prefer if you comply based on the latent threat of it happening. :P

Yes.  Which is partly why I took the decision to tweak the dragon's tail by arguing that our "off-topic" was actually relevant :-P

> Also, the tone is getting more stern, arguably getting close to or crossing the line of what they would consider acceptable for participants in the actual discussion. Fewer hearts now, too.

Indeed.

On Saturday, 23 May 2020 at 02:26:38 UTC, Walter Bright wrote:
> On 5/22/2020 12:08 AM, Araq wrote:
>> [x] Users had to patch every function in order to get type safety. Check.
>
> They didn't have to change anything. The following code compiles today on gcc:
>
>     foo(i, j) { return i + j; }

It does not compile in C99.

Old style declarations and implicit int are forbidden in C99.

On Saturday, 23 May 2020 at 16:11:30 UTC, Adam D. Ruppe wrote:
> There's really no technical reason why you can't do that now, just editing the server database.
>
> People with a local copy will still see the old one, of course, but that's just like how mailing list users like me don't see any deletion actions either.

Yeah, mod logs and notifications of mod actions are all possible, but like everything, someone needs to step up and implement them.

On 5/23/20 9:18 AM, Dibyendu Majumdar wrote:
> On Saturday, 23 May 2020 at 02:37:23 UTC, Walter Bright wrote:
>> C missed some obviously great ideas. One is nested functions, which fit right in with C's semantics. The other is the fix for:
>>
>> https://www.digitalmars.com/articles/C-biggest-mistake.html
> 
> I do not think it was a mistake at all. Treating pointers and arrays uniformly is one of the great innovations in C.
> 
> https://www.lysator.liu.se/c/bwk-on-pascal.html

The article does not support the argument. The article (section 2.1) discusses statically-sized arrays only, and the problem is that the size is part of the type; however, that's the case in C as well, as it should.

There's no doubt in my mind that the absence of a universal "doped pointer" (pointer plus extent) built-in or standard library in C has caused innumerable problems. The fact that early C versions could not return structs by value might have contributed to that decision.

On 23.05.20 19:08, Andrei Alexandrescu wrote:
> On 5/23/20 9:18 AM, Dibyendu Majumdar wrote:
>> On Saturday, 23 May 2020 at 02:37:23 UTC, Walter Bright wrote:
>>> C missed some obviously great ideas. One is nested functions, which fit right in with C's semantics. The other is the fix for:
>>>
>>> https://www.digitalmars.com/articles/C-biggest-mistake.html
>>
>> I do not think it was a mistake at all. Treating pointers and arrays uniformly is one of the great innovations in C.
>>
>> https://www.lysator.liu.se/c/bwk-on-pascal.html
> 
> The article does not support the argument. The article (section 2.1) discusses statically-sized arrays only, and the problem is that the size is part of the type; however, that's the case in C as well, as it should.
> 
> There's no doubt in my mind that the absence of a universal "doped pointer" (pointer plus extent) built-in or standard library in C has caused innumerable problems. The fact that early C versions could not return structs by value might have contributed to that decision.

I think they also considered it wasteful because lengths would often be stored multiple times, for example if you have multiple arrays of the same length or otherwise related lengths.

Fixed-size arrays where the length is part of the type can actually work well, the type system just has to be a little less naive. This is what I do in my research programming languages.

For example, the following merge sort code uses fixed-size arrays, where the sizes are run-time values:

def merge[a:*](less: a×a→𝔹)[n:ℕ,m:ℕ](xs: a^n, ys: a^m): a^(n+m){
    (i, j) := (0, 0);
    r := []: a[];
    while i<n ∧ j<m{
        if less(xs[i], ys[j]){
            r ~= [xs[i]];
            i += 1;
        }else{
            r ~= [ys[j]];
            j += 1;
        }
    }
    return r ~ xs[i..n] ~ ys[j..m] coerce a^(n+m);
}
def sort[a:*](less: a×a→𝔹)[n:ℕ](xs: a^n): a^n{
    if n<=1{ return xs; }
    rec := sort(less);
    return merge(less)(rec(xs[0..n div 2]), rec(xs[n div 2..n]));
}

On Saturday, 23 May 2020 at 17:08:10 UTC, Andrei Alexandrescu wrote:
> On 5/23/20 9:18 AM, Dibyendu Majumdar wrote:
>> On Saturday, 23 May 2020 at 02:37:23 UTC, Walter Bright wrote:
>>> C missed some obviously great ideas. One is nested functions, which fit right in with C's semantics. The other is the fix for:
>>>
>>> https://www.digitalmars.com/articles/C-biggest-mistake.html
>> 
>> I do not think it was a mistake at all. Treating pointers and arrays uniformly is one of the great innovations in C.
>> 
>
> There's no doubt in my mind that the absence of a universal "doped pointer" (pointer plus extent) built-in or standard library in C has caused innumerable problems. The fact that early C versions could not return structs by value might have contributed to that decision.

A doped pointer or hidden length would not be in the spirit of C.

I would agree that the standard library could have been better designed but that is a different problem.

C was designed as a replacement for assembly - not another high level language.  Of course C is unsafe for general purpose programming - it wasn't designed for that. C treats memory as a blob to be manipulated - types are there to help you do that more easily but that is all they do.