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

Groups > comp.lang.c++ > #120652 > unrolled thread

"Safe C++ is A new Proposal to Make C++ Memory-Safe"

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

Contents

  "Safe C++ is A new Proposal to Make C++ Memory-Safe" Lynn McGuire <lynnmcguire5@gmail.com> - 2024-10-08 20:40 -0500
    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-09 14:14 +0300
    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Lynn McGuire <lynnmcguire5@gmail.com> - 2024-10-09 15:02 -0500
      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-09 23:46 +0300
        Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-10-10 08:34 +0000
          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-10 12:51 +0300
            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-10-10 10:20 +0000
              Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-10 13:44 +0300
                Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-10-10 10:50 +0000
                  Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-10 14:10 +0300
                    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-10-10 13:11 +0000
                      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-10 16:54 +0300
                        Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Paavo Helde <eesnimi@osa.pri.ee> - 2024-10-10 18:08 +0300
                          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-10-10 23:37 +0800
                            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Paavo Helde <eesnimi@osa.pri.ee> - 2024-10-10 19:03 +0300
                          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-10 19:11 +0300
                            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" David Brown <david.brown@hesbynett.no> - 2024-10-10 20:01 +0200
            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-10 07:56 -0700
              Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-10 18:56 +0300
      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-10-20 10:13 -0700
    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-10-10 12:13 -0400
    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-10 18:29 +0200
    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Vir Campestris <vir.campestris@invalid.invalid> - 2024-10-20 12:37 +0100
      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Michael S <already5chosen@yahoo.com> - 2024-10-20 14:46 +0300
        Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-10-20 14:23 +0000
    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-10-27 19:09 -0400
      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-10-27 20:40 -0400
        Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-10-28 09:22 +0800
          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-27 21:18 -0700
            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-10-28 12:25 -0400
              Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-10-30 12:56 -0400
                Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-30 12:50 -0700
                  Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-10-30 16:31 -0400
                    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-04 12:47 -0800
                Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-11-07 07:02 -0500
                Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Lynn McGuire <lynnmcguire5@gmail.com> - 2024-11-07 20:14 -0600
                  Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-11-08 09:40 -0500
                  Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" scott@slp53.sl.home (Scott Lurndal) - 2024-11-08 14:48 +0000
                    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-11-08 14:54 +0000
                      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 12:40 -0800
                        Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@dastardlyhq.com - 2024-11-09 12:01 +0000
                          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-09 12:39 -0800
                            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-11-11 09:56 +0000
                              Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-11 13:36 -0800
                                Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@DastartdlyHQ.org - 2024-11-12 08:28 +0000
                                  Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-12 13:56 -0800
                                    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-12 13:59 -0800
                                    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-12 16:20 -0800
                        Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-10 13:02 -0800
                          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-11-10 13:05 -0800
                      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 12:46 -0800
                        Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 05:18 +0800
                          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 13:23 -0800
                          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 05:25 +0800
                          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 13:27 -0800
                            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 06:02 +0800
                              Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 14:09 -0800
                                Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 06:35 +0800
                                  Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 14:37 -0800
                                    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 06:47 +0800
                                      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 14:58 -0800
                                        Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 07:09 +0800
                                          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 15:35 -0800
                                            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" scott@slp53.sl.home (Scott Lurndal) - 2024-11-08 23:50 +0000
                                              Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 18:11 -0800
                                  Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 14:39 -0800
                                    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 06:58 +0800
                                      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 15:01 -0800
                                        Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 07:13 +0800
                                          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 15:40 -0800
                                            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" wij <wyniijj5@gmail.com> - 2024-11-09 08:19 +0800
                                              Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-08 18:15 -0800
                                                Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" scott@slp53.sl.home (Scott Lurndal) - 2024-11-09 16:23 +0000
                                                  Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-09 12:42 -0800
                                                    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" scott@slp53.sl.home (Scott Lurndal) - 2024-11-09 23:23 +0000
                                                      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Paavo Helde <eesnimi@osa.pri.ee> - 2024-11-10 11:00 +0200
                                                        Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-12 16:56 -0800
                                                          Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-12 16:59 -0800
                                                            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-12 17:05 -0800
                                            Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@dastardlyhq.com - 2024-11-09 12:01 +0000
                                    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Muttley@dastardlyhq.com - 2024-11-09 12:01 +0000
                                      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-11-09 12:50 -0800
      Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-04 06:59 -0800
    Re: "Safe C++ is A new Proposal to Make C++ Memory-Safe" jseigh <jseigh_es00@xemaps.com> - 2024-11-30 10:03 -0500

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

#120692

On 10/8/24 21:40, Lynn McGuire wrote:
> "Safe C++ is A new Proposal to Make C++ Memory-Safe"
>     https://www.infoq.com/news/2024/10/safe-cpp-proposal/
> 
> "The goal of the Safe C++ proposal is extending C++ by defining a 
> superset of the language that can be used to write code with the strong 
> safety guarantees similarly to code written in Rust. The key to its 
> approach is introducing a new safe context where only a rigorously safe 
> subset of C++ is allowed."
> 
> "The Safe C++ proposal, set forth by Sean Baxter and Christian Mazakas, 
> originates from the growing awareness that C++ memory unsafety lies at 
> the root of a large part of vulnerabilities and memory exploits. The 
> only existing safe language, say Baxter and Mazakas, is Rust, but their 
> design differences limit interoperability, thus making it hard to 
> migrate from one language to the other. For example, Rust lacks function 
> overloading, templates, inheritance, and exceptions, while C++ lacks 
> traits, relocation, and borrow checking."
> 
> Lynn
> 

For some definition of safe.

A lot of the problem is logically most stuff is treat as if
it was all move or copy by value.  That's not feasible for
large data structures or where storage requirements aren't
known at compile time.  So references get used and that's
problemantic since 2 references can share all or some of
their memory.  So it looks like Rust does a lot of work
on detecting or managing aliasing.

Also there's ownership, responsibility to run the dtor,
deallocate heap storage, etc...  RAII take care of a lot
of that but problems can occur when concurrency enters
the picture.  Language architects and standards committees
don't have a very good understanding of concurrency and
tend to architect some really sub-optimal stuff from a
concurrent programming point of view.  Just look at
rustaceans trying to explain how ARC ownership works.
There's no formal ownership mechanism there,  it just
gets swept under the Rust rug of unsafe.

Rust unsafe is how they punt on the issue.  Basically
you use unsafe to code stuff Rust doesn't have the
mechanisms for but the authors of said code have to
guarantee their code meets Rust safety at the api
level.  Do you feel lucky?

Also it's very telling that restaceans claim that
Rust is super fast and yet promote reference counting
as the way to share objects when reference counting
is one of the least performant ways of doing that.


Traits are nice.  Nothing to do with safety AFAIK.  They are sort
of like Java interfaces or C++ abstract methods except they can
be defined outside of the class definition.  I would have
really liked something like that in Java.  Shouldn't be too
hard to add to C++, though it would be nice that if the type
was known at compile time they avoid the virtual method
vtables and inline where possible and feasible.

Joe Seigh

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

#120693

Am 09.10.2024 um 03:40 schrieb Lynn McGuire:
> "Safe C++ is A new Proposal to Make C++ Memory-Safe"
>     https://www.infoq.com/news/2024/10/safe-cpp-proposal/
> 
> "The goal of the Safe C++ proposal is extending C++ by defining a 
> superset of the language that can be used to write code with the strong 
> safety guarantees similarly to code written in Rust. The key to its 
> approach is introducing a new safe context where only a rigorously safe 
> subset of C++ is allowed."
> 
> "The Safe C++ proposal, set forth by Sean Baxter and Christian Mazakas, 
> originates from the growing awareness that C++ memory unsafety lies at 
> the root of a large part of vulnerabilities and memory exploits. The 
> only existing safe language, say Baxter and Mazakas, is Rust, but their 
> design differences limit interoperability, thus making it hard to 
> migrate from one language to the other. For example, Rust lacks function 
> overloading, templates, inheritance, and exceptions, while C++ lacks 
> traits, relocation, and borrow checking."
> 
> Lynn
> 

I try to make C++ as safe as possible by using iterator debugging.
All pointers on flat memory with attached immediately into a span
iterator to care for bounds like with the where-iterator in the
following code.

	str.resize_and_overwrite( (views.length() + ...), [&]( 
String::value_type *p, size_t n )
		{
			auto where = span( p, n ).begin();
			((where = copy( views.begin(), views.end(), where )), ...);
			return n;
		} );

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

#120741

On 09/10/2024 02:40, Lynn McGuire wrote:
> "Safe C++ is A new Proposal to Make C++ Memory-Safe"
>     https://www.infoq.com/news/2024/10/safe-cpp-proposal/
> 
> "The goal of the Safe C++ proposal is extending C++ by defining a 
> superset of the language that can be used to write code with the strong 
> safety guarantees similarly to code written in Rust. The key to its 
> approach is introducing a new safe context where only a rigorously safe 
> subset of C++ is allowed."
> 
> "The Safe C++ proposal, set forth by Sean Baxter and Christian Mazakas, 
> originates from the growing awareness that C++ memory unsafety lies at 
> the root of a large part of vulnerabilities and memory exploits. The 
> only existing safe language, say Baxter and Mazakas, is Rust, but their 
> design differences limit interoperability, thus making it hard to 
> migrate from one language to the other. For example, Rust lacks function 
> overloading, templates, inheritance, and exceptions, while C++ lacks 
> traits, relocation, and borrow checking."
> 
> Lynn
> 
I hiccuped at this point:

 > a superset of the language

This means it has everything that C++ has, and some more stuff as well. 
I'm pretty sure they mean a subset.

Andy

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

#120743

On Sun, 20 Oct 2024 12:37:45 +0100
Vir Campestris <vir.campestris@invalid.invalid> wrote:

> On 09/10/2024 02:40, Lynn McGuire wrote:
> > "Safe C++ is A new Proposal to Make C++ Memory-Safe"
> >     https://www.infoq.com/news/2024/10/safe-cpp-proposal/
> > 
> > "The goal of the Safe C++ proposal is extending C++ by defining a 
> > superset of the language that can be used to write code with the
> > strong safety guarantees similarly to code written in Rust. The key
> > to its approach is introducing a new safe context where only a
> > rigorously safe subset of C++ is allowed."
> > 
> > "The Safe C++ proposal, set forth by Sean Baxter and Christian
> > Mazakas, originates from the growing awareness that C++ memory
> > unsafety lies at the root of a large part of vulnerabilities and
> > memory exploits. The only existing safe language, say Baxter and
> > Mazakas, is Rust, but their design differences limit
> > interoperability, thus making it hard to migrate from one language
> > to the other. For example, Rust lacks function overloading,
> > templates, inheritance, and exceptions, while C++ lacks traits,
> > relocation, and borrow checking."
> > 
> > Lynn
> >   
> I hiccuped at this point:
> 
>  > a superset of the language  
> 
> This means it has everything that C++ has, and some more stuff as
> well. I'm pretty sure they mean a subset.
> 
> Andy

Ignore clueless Sergio De Simone. His article couses nothing but
misunderstanding.
Go straight to the proposal.
https://safecpp.org/P3390R0.html#relocation-object-model

"The goal of this proposal is to advance a superset of C++ with a
rigorously safe subset."

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

#120744

On Sun, 20 Oct 2024 14:46:55 +0300
Michael S <already5chosen@yahoo.com> boring babbled:
>On Sun, 20 Oct 2024 12:37:45 +0100
>Vir Campestris <vir.campestris@invalid.invalid> wrote:
>
>> On 09/10/2024 02:40, Lynn McGuire wrote:
>> > "Safe C++ is A new Proposal to Make C++ Memory-Safe"
>> >  =A0=A0 https://www.infoq.com/news/2024/10/safe-cpp-proposal/
>> >=20
>> > "The goal of the Safe C++ proposal is extending C++ by defining a=20
>> > superset of the language that can be used to write code with the
>> > strong safety guarantees similarly to code written in Rust. The key
>> > to its approach is introducing a new safe context where only a
>> > rigorously safe subset of C++ is allowed."
>> >=20
>> > "The Safe C++ proposal, set forth by Sean Baxter and Christian
>> > Mazakas, originates from the growing awareness that C++ memory
>> > unsafety lies at the root of a large part of vulnerabilities and
>> > memory exploits. The only existing safe language, say Baxter and
>> > Mazakas, is Rust, but their design differences limit
>> > interoperability, thus making it hard to migrate from one language
>> > to the other. For example, Rust lacks function overloading,
>> > templates, inheritance, and exceptions, while C++ lacks traits,
>> > relocation, and borrow checking."
>> >=20
>> > Lynn
>> >  =20
>> I hiccuped at this point:
>>=20
>>  > a superset of the language =20
>>=20
>> This means it has everything that C++ has, and some more stuff as
>> well. I'm pretty sure they mean a subset.
>>=20
>> Andy
>
>Ignore clueless Sergio De Simone. His article couses nothing but
>misunderstanding.
>Go straight to the proposal.
>https://safecpp.org/P3390R0.html#relocation-object-model
>
>"The goal of this proposal is to advance a superset of C++ with a
>rigorously safe subset."

Why bother. All thats needed is a new keyword, perhaps "safe".

Trivial example:

safe
{
	int i[10];
	int j = 10;
	cout << i[j];
};

This would fail to compile or if the check couldn't be done at compile time 
any invalid memory accesses within the "safe" block could runtime abort with a 
useful error instead of just ploughing ahead and crashing or corrupting the
code later anyway with the expense of runtime checking costs.

Possibly even a handler function could be set for this eventuality (no, 
catching a SIGSEGV/BUS isn't the same as you don't know whats been corrupted 
so can't do anything useful in the sig handler anyway).

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

#120754

On 10/8/24 21:40, Lynn McGuire wrote:
> "Safe C++ is A new Proposal to Make C++ Memory-Safe"
>     https://www.infoq.com/news/2024/10/safe-cpp-proposal/
> 
> "The goal of the Safe C++ proposal is extending C++ by defining a 
> superset of the language that can be used to write code with the strong 
> safety guarantees similarly to code written in Rust. The key to its 
> approach is introducing a new safe context where only a rigorously safe 
> subset of C++ is allowed."
> 
> "The Safe C++ proposal, set forth by Sean Baxter and Christian Mazakas, 
> originates from the growing awareness that C++ memory unsafety lies at 
> the root of a large part of vulnerabilities and memory exploits. The 
> only existing safe language, say Baxter and Mazakas, is Rust, but their 
> design differences limit interoperability, thus making it hard to 
> migrate from one language to the other. For example, Rust lacks function 
> overloading, templates, inheritance, and exceptions, while C++ lacks 
> traits, relocation, and borrow checking."
> 
> Lynn
> 

Dealing with nullable pointers.  Apparently some get really
freaked out by NPEs.  Could be worse.  I worked on platforms
where address 0 was readable without causing a segfault or
protection exception right away.  You'd get a core dump but
with no indication of what code loaded the null ptr without
checking or why.  Fortunately, on this platform you could
run an instruction trace to the terminal and wait for it
to stop. You'd then just go backward thru the trace until
the ip matched actual code.  Anyway ...

You create a new nullable attribute for pointers. That
would make the pointer behave like void* instead of T*.
You could move, copy, and compare, but you could not
dereference them.  If you wanted to dereference them
you would have to apply a special not_null unary predicate
to them.  What makes it special is the boolean result
is only valid inside a conditional expression.  It's
not copyable or referencable.  You could have 1 or
more of these in a conditional expression along with
ordinary predicates with the restriction that the
expression has to be formed such that if any of the
not_null terms are false, the expression has to
evaluate as false.

The other thing that makes not_null is that inside
if the conditional statements true blocks, the
nullable pointer gets it T* properties back, so
you can dereference it, but again only in the
true blocks.  So for example

nullable T* p = &something;

T p2 = *p;	// invalid, compiler thinks you are trying
                 // do dereference void*

not_null(p);	// invalid, not inside conditional expression

if (not_null(p)
   p2 = *p;      // valid
else
   p2 = *p;      // invalid


Traversing a linked list would look like

T* p = head;
while (not_null(p)) {
   ...
   p = p->next;	// valid, inside while true block
}

not_null would look like
__predicate_bool not_null(T *&)
It would make a const copy of T*, test that,
cast to T*, use it for the true block.

So no NPEs possible for pointer with this
attribute.

AFAICT, you can't do this with templates.

Joe Seigh

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

#120756

On 10/27/24 19:09, jseigh wrote:
> On 10/8/24 21:40, Lynn McGuire wrote:

> Traversing a linked list would look like
> 
> T* p = head;
> while (not_null(p)) {
>    ...
>    p = p->next;    // valid, inside while true block
> }
> 

I should add, the p->next is also nullable so the
assignment to p makes it nullable again.  The
goal is to make the code look like normal code
while ensuring null pointer safety.

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

#120757

On Sun, 2024-10-27 at 20:40 -0400, jseigh wrote:
> On 10/27/24 19:09, jseigh wrote:
> > On 10/8/24 21:40, Lynn McGuire wrote:
> 
> > Traversing a linked list would look like
> > 
> > T* p = head;
> > while (not_null(p)) {
> >    ...
> >    p = p->next;    // valid, inside while true block
> > }
> > 
> 
> I should add, the p->next is also nullable so the
> assignment to p makes it nullable again.  The
> goal is to make the code look like normal code
> while ensuring null pointer safety.
> 

C++ is an object oriented language. 
In C++, programming in C concept makes little sense.

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

#120762

On 10/27/2024 6:22 PM, wij wrote:
> On Sun, 2024-10-27 at 20:40 -0400, jseigh wrote:
>> On 10/27/24 19:09, jseigh wrote:
>>> On 10/8/24 21:40, Lynn McGuire wrote:
>>
>>> Traversing a linked list would look like
>>>
>>> T* p = head;
>>> while (not_null(p)) {
>>>     ...
>>>     p = p->next;    // valid, inside while true block
>>> }
>>>
>>
>> I should add, the p->next is also nullable so the
>> assignment to p makes it nullable again.  The
>> goal is to make the code look like normal code
>> while ensuring null pointer safety.
>>
> 
> C++ is an object oriented language.
> In C++, programming in C concept makes little sense.
> 

Well, sometimes for some exotic algorithms we can steal a bit and say 
this is a null (the bit is set) even though its not equal to nullptr. 
It's null but it still points to a node. This can be called a so-called 
dummy node, sometimes. The logic with dummy nodes can be beneficial.

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

#120764

On 10/28/24 00:18, Chris M. Thomasson wrote:
> On 10/27/2024 6:22 PM, wij wrote:
>> On Sun, 2024-10-27 at 20:40 -0400, jseigh wrote:
>>> On 10/27/24 19:09, jseigh wrote:
>>>> On 10/8/24 21:40, Lynn McGuire wrote:
>>>
>>>> Traversing a linked list would look like
>>>>
>>>> T* p = head;
>>>> while (not_null(p)) {
>>>>     ...
>>>>     p = p->next;    // valid, inside while true block
>>>> }
>>>>
>>>
>>> I should add, the p->next is also nullable so the
>>> assignment to p makes it nullable again.  The
>>> goal is to make the code look like normal code
>>> while ensuring null pointer safety.
>>>
>>
>> C++ is an object oriented language.
>> In C++, programming in C concept makes little sense.
>>
> 
> Well, sometimes for some exotic algorithms we can steal a bit and say 
> this is a null (the bit is set) even though its not equal to nullptr. 
> It's null but it still points to a node. This can be called a so-called 
> dummy node, sometimes. The logic with dummy nodes can be beneficial.

The whole nullable pointer thing was a unrelated spin off of a
solution I did for addressing pointer provenance as discussed in
https://lwn.net/Articles/993484/ in the comments.

The nullable pointer solution I proposed is not super clear
as it depends on behavior not presently in c++ so hard to
show how the solution would work.

At any rate, I don't have problems with nullable pointers or
dealing with pointer provenance, and I don't have spare
cycles to implement solutions for the latter, solutions I
don't need.

Joe Seigh

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

#120797

On 10/28/24 12:25, jseigh wrote:
...
> The whole nullable pointer thing was a unrelated spin off of a
> solution I did for addressing pointer provenance as discussed in
> https://lwn.net/Articles/993484/ in the comments.
> 
> The nullable pointer solution I proposed is not super clear
> as it depends on behavior not presently in c++ so hard to
> show how the solution would work.
> 
> At any rate, I don't have problems with nullable pointers or
> dealing with pointer provenance, and I don't have spare
> cycles to implement solutions for the latter, solutions I
> don't need.
> 

I worked on this some more so I've gotten a better idea of
what they mean by pointer provenance.  I don't think will
solve all the issues they think it will.  I can come up
with some pretty trivial examples that will break their
proposed solutions.  I think they are unicorn hunting here.

One of the issues they brought up is the ABA problem.  Yet
C/C++ has abjectly refused to support 50 year old hardware
features that would help for some ABA issues.  Kind of hard
to take the pointer provenance problem seriously.

Joe Seigh

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

#120800

On 10/30/2024 9:56 AM, jseigh wrote:
> On 10/28/24 12:25, jseigh wrote:
> ...
>> The whole nullable pointer thing was a unrelated spin off of a
>> solution I did for addressing pointer provenance as discussed in
>> https://lwn.net/Articles/993484/ in the comments.
>>
>> The nullable pointer solution I proposed is not super clear
>> as it depends on behavior not presently in c++ so hard to
>> show how the solution would work.
>>
>> At any rate, I don't have problems with nullable pointers or
>> dealing with pointer provenance, and I don't have spare
>> cycles to implement solutions for the latter, solutions I
>> don't need.
>>
> 
> I worked on this some more so I've gotten a better idea of
> what they mean by pointer provenance.  I don't think will
> solve all the issues they think it will.  I can come up
> with some pretty trivial examples that will break their
> proposed solutions.  I think they are unicorn hunting here.
> 
> One of the issues they brought up is the ABA problem.  Yet
> C/C++ has abjectly refused to support 50 year old hardware
> features that would help for some ABA issues.  Kind of hard
> to take the pointer provenance problem seriously.

Are you referring to DWCAS? There has to be a compiler out there that 
can handle it wrt it being, always lock-free ala:
__________________
​0​ for the built-in atomic types that are never lock-free,
1 for the built-in atomic types that are sometimes lock-free,
2 for the built-in atomic types that are always lock-free.
__________________

Damn it! ;^/

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

#120802

On 10/30/24 15:50, Chris M. Thomasson wrote:
> On 10/30/2024 9:56 AM, jseigh wrote:
>> On 10/28/24 12:25, jseigh wrote:
>> ...
>>> The whole nullable pointer thing was a unrelated spin off of a
>>> solution I did for addressing pointer provenance as discussed in
>>> https://lwn.net/Articles/993484/ in the comments.
>>>
>>> The nullable pointer solution I proposed is not super clear
>>> as it depends on behavior not presently in c++ so hard to
>>> show how the solution would work.
>>>
>>> At any rate, I don't have problems with nullable pointers or
>>> dealing with pointer provenance, and I don't have spare
>>> cycles to implement solutions for the latter, solutions I
>>> don't need.
>>>
>>
>> I worked on this some more so I've gotten a better idea of
>> what they mean by pointer provenance.  I don't think will
>> solve all the issues they think it will.  I can come up
>> with some pretty trivial examples that will break their
>> proposed solutions.  I think they are unicorn hunting here.
>>
>> One of the issues they brought up is the ABA problem.  Yet
>> C/C++ has abjectly refused to support 50 year old hardware
>> features that would help for some ABA issues.  Kind of hard
>> to take the pointer provenance problem seriously.
> 
> Are you referring to DWCAS? There has to be a compiler out there that 
> can handle it wrt it being, always lock-free ala:
> __________________
> ​0​ for the built-in atomic types that are never lock-free,
> 1 for the built-in atomic types that are sometimes lock-free,
> 2 for the built-in atomic types that are always lock-free.
> __________________
> 
> Damn it! ;^/
> 

No. AFAIK everyone uses assembler.  gcc has a builtin that
calls a library function which uses locks because soemwhere
in a museum there is an x86 computer that doesn't have
cmpxchg16b and in theory it someone port new versions of
linux and gcc to it, it wouldn't work.  It sound stupid
because it is stupid.

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

#120837

On 10/30/2024 1:31 PM, jseigh wrote:
> On 10/30/24 15:50, Chris M. Thomasson wrote:
>> On 10/30/2024 9:56 AM, jseigh wrote:
>>> On 10/28/24 12:25, jseigh wrote:
>>> ...
>>>> The whole nullable pointer thing was a unrelated spin off of a
>>>> solution I did for addressing pointer provenance as discussed in
>>>> https://lwn.net/Articles/993484/ in the comments.
>>>>
>>>> The nullable pointer solution I proposed is not super clear
>>>> as it depends on behavior not presently in c++ so hard to
>>>> show how the solution would work.
>>>>
>>>> At any rate, I don't have problems with nullable pointers or
>>>> dealing with pointer provenance, and I don't have spare
>>>> cycles to implement solutions for the latter, solutions I
>>>> don't need.
>>>>
>>>
>>> I worked on this some more so I've gotten a better idea of
>>> what they mean by pointer provenance.  I don't think will
>>> solve all the issues they think it will.  I can come up
>>> with some pretty trivial examples that will break their
>>> proposed solutions.  I think they are unicorn hunting here.
>>>
>>> One of the issues they brought up is the ABA problem.  Yet
>>> C/C++ has abjectly refused to support 50 year old hardware
>>> features that would help for some ABA issues.  Kind of hard
>>> to take the pointer provenance problem seriously.
>>
>> Are you referring to DWCAS? There has to be a compiler out there that 
>> can handle it wrt it being, always lock-free ala:
>> __________________
>> ​0​ for the built-in atomic types that are never lock-free,
>> 1 for the built-in atomic types that are sometimes lock-free,
>> 2 for the built-in atomic types that are always lock-free.
>> __________________
>>
>> Damn it! ;^/
>>
> 
> No. AFAIK everyone uses assembler. 

Ahh shit. This brings back memories of coding things up in asm... The 
wayback machine has some of my old code on it:

https://web.archive.org/web/20060214112345/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_gcc_asm.html

;^o


> gcc has a builtin that
> calls a library function which uses locks because soemwhere
> in a museum there is an x86 computer that doesn't have
> cmpxchg16b and in theory it someone port new versions of
> linux and gcc to it, it wouldn't work.  It sound stupid
> because it is stupid.
> 
> 

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

#120841

On 10/30/24 12:56, jseigh wrote:
> On 10/28/24 12:25, jseigh wrote:
> ...
>> The whole nullable pointer thing was a unrelated spin off of a
>> solution I did for addressing pointer provenance as discussed in
>> https://lwn.net/Articles/993484/ in the comments.
>>
>> The nullable pointer solution I proposed is not super clear
>> as it depends on behavior not presently in c++ so hard to
>> show how the solution would work.
>>
>> At any rate, I don't have problems with nullable pointers or
>> dealing with pointer provenance, and I don't have spare
>> cycles to implement solutions for the latter, solutions I
>> don't need.
>>
> 
> I worked on this some more so I've gotten a better idea of
> what they mean by pointer provenance.  I don't think will
> solve all the issues they think it will.  I can come up
> with some pretty trivial examples that will break their
> proposed solutions.  I think they are unicorn hunting here.
> 
> One of the issues they brought up is the ABA problem.  Yet
> C/C++ has abjectly refused to support 50 year old hardware
> features that would help for some ABA issues.  Kind of hard
> to take the pointer provenance problem seriously.
> 
I did come up with an interesting solution.  It should work
on top of the proxy stuff but is not integral to it.  But
I need to finish porting the proxy stuff to c++.

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

#120842

On 10/30/2024 11:56 AM, jseigh wrote:
> On 10/28/24 12:25, jseigh wrote:
> ...
>> The whole nullable pointer thing was a unrelated spin off of a
>> solution I did for addressing pointer provenance as discussed in
>> https://lwn.net/Articles/993484/ in the comments.
>>
>> The nullable pointer solution I proposed is not super clear
>> as it depends on behavior not presently in c++ so hard to
>> show how the solution would work.
>>
>> At any rate, I don't have problems with nullable pointers or
>> dealing with pointer provenance, and I don't have spare
>> cycles to implement solutions for the latter, solutions I
>> don't need.
>>
> 
> I worked on this some more so I've gotten a better idea of
> what they mean by pointer provenance.  I don't think will
> solve all the issues they think it will.  I can come up
> with some pretty trivial examples that will break their
> proposed solutions.  I think they are unicorn hunting here.
> 
> One of the issues they brought up is the ABA problem.  Yet
> C/C++ has abjectly refused to support 50 year old hardware
> features that would help for some ABA issues.  Kind of hard
> to take the pointer provenance problem seriously.
> 
> Joe Seigh

What is the ABA problem ?

Lynn

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

#120844

On 11/7/24 21:14, Lynn McGuire wrote:
> On 10/30/2024 11:56 AM, jseigh wrote:
>> On 10/28/24 12:25, jseigh wrote:
>> ...
>>> The whole nullable pointer thing was a unrelated spin off of a
>>> solution I did for addressing pointer provenance as discussed in
>>> https://lwn.net/Articles/993484/ in the comments.
>>>
>>> The nullable pointer solution I proposed is not super clear
>>> as it depends on behavior not presently in c++ so hard to
>>> show how the solution would work.
>>>
>>> At any rate, I don't have problems with nullable pointers or
>>> dealing with pointer provenance, and I don't have spare
>>> cycles to implement solutions for the latter, solutions I
>>> don't need.
>>>
>>
>> I worked on this some more so I've gotten a better idea of
>> what they mean by pointer provenance.  I don't think will
>> solve all the issues they think it will.  I can come up
>> with some pretty trivial examples that will break their
>> proposed solutions.  I think they are unicorn hunting here.
>>
>> One of the issues they brought up is the ABA problem.  Yet
>> C/C++ has abjectly refused to support 50 year old hardware
>> features that would help for some ABA issues.  Kind of hard
>> to take the pointer provenance problem seriously.
>>
>> Joe Seigh
> 
> What is the ABA problem ?
> 

Things like using single word compare and swap to pop something
off a stack where the stack was modified between the initial
load of the stack head and the top of stack is same but
the item after it is different.

Stack at initial load
   x -> a -> b ...

Stack before cas of x from a to b for pop operation
because it changed.
   x -> a -> c ...

Stack after pop
   x -> b (b having possibly unknown memory state)

System370 has cds (double wide cas) to avoid the ABA problem
in the 70's.

Supporting DWCAS in C/C++ is NOT a technical problem.

Joe Seigh

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

#120845

Lynn McGuire <lynnmcguire5@gmail.com> writes:
>On 10/30/2024 11:56 AM, jseigh wrote:
>> On 10/28/24 12:25, jseigh wrote:
>> ...
>>> The whole nullable pointer thing was a unrelated spin off of a
>>> solution I did for addressing pointer provenance as discussed in
>>> https://lwn.net/Articles/993484/ in the comments.
>>>
>>> The nullable pointer solution I proposed is not super clear
>>> as it depends on behavior not presently in c++ so hard to
>>> show how the solution would work.
>>>
>>> At any rate, I don't have problems with nullable pointers or
>>> dealing with pointer provenance, and I don't have spare
>>> cycles to implement solutions for the latter, solutions I
>>> don't need.
>>>
>> 
>> I worked on this some more so I've gotten a better idea of
>> what they mean by pointer provenance.  I don't think will
>> solve all the issues they think it will.  I can come up
>> with some pretty trivial examples that will break their
>> proposed solutions.  I think they are unicorn hunting here.
>> 
>> One of the issues they brought up is the ABA problem.  Yet
>> C/C++ has abjectly refused to support 50 year old hardware
>> features that would help for some ABA issues.  Kind of hard
>> to take the pointer provenance problem seriously.
>> 
>> Joe Seigh
>
>What is the ABA problem ?
>
>Lynn
>
https://en.wikipedia.org/wiki/ABA_problem

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

#120846

On Fri, 08 Nov 2024 14:48:16 GMT
scott@slp53.sl.home (Scott Lurndal) boring babbled:
>Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>On 10/30/2024 11:56 AM, jseigh wrote:
>>> On 10/28/24 12:25, jseigh wrote:
>>> ...
>>>> The whole nullable pointer thing was a unrelated spin off of a
>>>> solution I did for addressing pointer provenance as discussed in
>>>> https://lwn.net/Articles/993484/ in the comments.
>>>>
>>>> The nullable pointer solution I proposed is not super clear
>>>> as it depends on behavior not presently in c++ so hard to
>>>> show how the solution would work.
>>>>
>>>> At any rate, I don't have problems with nullable pointers or
>>>> dealing with pointer provenance, and I don't have spare
>>>> cycles to implement solutions for the latter, solutions I
>>>> don't need.
>>>>
>>> 
>>> I worked on this some more so I've gotten a better idea of
>>> what they mean by pointer provenance.  I don't think will
>>> solve all the issues they think it will.  I can come up
>>> with some pretty trivial examples that will break their
>>> proposed solutions.  I think they are unicorn hunting here.
>>> 
>>> One of the issues they brought up is the ABA problem.  Yet
>>> C/C++ has abjectly refused to support 50 year old hardware
>>> features that would help for some ABA issues.  Kind of hard
>>> to take the pointer provenance problem seriously.
>>> 
>>> Joe Seigh
>>
>>What is the ABA problem ?
>>
>>Lynn
>>
>https://en.wikipedia.org/wiki/ABA_problem

Why's it a problem? Its why mutexes exist. Why would anyone expect non
synchronised RW memory access to work? The exact same problem occurs
in databases with dirty reads.

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

#120847

On 11/8/2024 6:54 AM, Muttley@DastartdlyHQ.org wrote:
> On Fri, 08 Nov 2024 14:48:16 GMT
> scott@slp53.sl.home (Scott Lurndal) boring babbled:
>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>> On 10/30/2024 11:56 AM, jseigh wrote:
>>>> On 10/28/24 12:25, jseigh wrote:
>>>> ...
>>>>> The whole nullable pointer thing was a unrelated spin off of a
>>>>> solution I did for addressing pointer provenance as discussed in
>>>>> https://lwn.net/Articles/993484/ in the comments.
>>>>>
>>>>> The nullable pointer solution I proposed is not super clear
>>>>> as it depends on behavior not presently in c++ so hard to
>>>>> show how the solution would work.
>>>>>
>>>>> At any rate, I don't have problems with nullable pointers or
>>>>> dealing with pointer provenance, and I don't have spare
>>>>> cycles to implement solutions for the latter, solutions I
>>>>> don't need.
>>>>>
>>>>
>>>> I worked on this some more so I've gotten a better idea of
>>>> what they mean by pointer provenance.  I don't think will
>>>> solve all the issues they think it will.  I can come up
>>>> with some pretty trivial examples that will break their
>>>> proposed solutions.  I think they are unicorn hunting here.
>>>>
>>>> One of the issues they brought up is the ABA problem.  Yet
>>>> C/C++ has abjectly refused to support 50 year old hardware
>>>> features that would help for some ABA issues.  Kind of hard
>>>> to take the pointer provenance problem seriously.
>>>>
>>>> Joe Seigh
>>>
>>> What is the ABA problem ?
>>>
>>> Lynn
>>>
>> https://en.wikipedia.org/wiki/ABA_problem
> 
> Why's it a problem? Its why mutexes exist. 

What if one did not want to use a mutex?


> Why would anyone expect non
> synchronised RW memory access to work? The exact same problem occurs
> in databases with dirty reads.
> 

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

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

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

csiph-web