Boost :

benedict_at_[hidden]

-- 
Rainer Deyke (rainerd_at_[hidden])
------------------------------
Message: 7
Date: Fri, 13 May 2022 18:20:40 +0000
From: David Bien <davidbien_at_[hidden]>
To: "boost_at_[hidden]" <boost_at_[hidden]>
Cc: Peter Dimov <pdimov_at_[hidden]>
Subject: Re: [boost] cstring_view
Message-ID:
	<MWHPR1801MB1934DE34D9E7AE1678101098B1CA9_at_MWHPR1801MB1934.namprd18.prod.outlo>
	
Content-Type: text/plain; charset="Windows-1252"
Exactly. But then it should just be called cstring_wrapper ? calling it cstring_view seems to impart qualities to it that it doesn?t have ? like I would assume that I could get a cstring_view that is a subview of an existing cstring_view for instance.
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows
From: Peter Dimov via Boost<mailto:boost_at_[hidden]>
Sent: Friday, May 13, 2022 12:19 PM
To: boost_at_[hidden]<mailto:boost_at_[hidden]>
Cc: Peter Dimov<mailto:pdimov_at_[hidden]>
Subject: Re: [boost] cstring_view
Marshall Clow wrote:
> On May 13, 2022, at 10:42 AM, David Bien via Boost <boost_at_[hidden]>
> wrote:
> >
> > I guess when I read the impl I think to myself: What this is missing is a
> _length member. But then it just becomes boost::string_view.
> >
> > What value added is there to this impl except that it is smaller than
> boost::string_view due to lacking a _length member?
>
> If you?re careful and don?t do much with it, it can hand you back a null
> terminated string.
???
In what scenarios will it not give you a null-terminated string?
_______________________________________________
Unsubscribe & other changes: https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.boost.org%2Fmailman%2Flistinfo.cgi%2Fboost&amp;data=05%7C01%7C%7Cf61e2ab6e0b04fcd8a4508da350d0f78%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637880627456487826%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=itiI6gcF%2FXnNr41BGxmxrqbPRAq%2FqhjBYRVXXG3UbwM%3D&amp;reserved=0
------------------------------
Message: 8
Date: Fri, 13 May 2022 21:37:36 +0200
From: Rainer Deyke <rdeyke_at_[hidden]>
To: boost_at_[hidden]
Subject: Re: [boost] MySql review
Message-ID: <t5mc20$87r$1_at_[hidden]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 13.05.22 17:23, Phil Endecott via Boost wrote:
> The aim should be "secure by default". Users are lazy. The
> particular danger in this case is that they do an initial test with
> the password in the source, and then move it somewhere secure later,
> but the password is still exposed in their revision control history.
> At this point in history, there is no excuse to repeat the mistakes
> that have lead to really very serious security problems in the past.
> Make the default mechanism, and the first one that you describe in
> the docs, the most secure one.
Looking for credentials in a file on disk may be more secure than 
embedding the credentials in code, but it is most definitely the most 
secure mechanism.  The most secure mechanism is to always ask the user 
at program start-up.  Or better yet, ask each time a connection is 
created, and then immediately wipe the credentials from RAM in order to 
mitigate RAM scanning attacks.
-- 
Rainer Deyke (rainerd_at_[hidden])
------------------------------
Message: 9
Date: Fri, 13 May 2022 12:33:50 -0700
From: Robert Ramey <ramey_at_[hidden]>
To: Peter Dimov via Boost <boost_at_[hidden]>
Subject: Re: [boost] The Future of C++ and Boost - C++ Modules
Message-ID: <4134c080-20bb-16d2-ff81-0c6b6dc52d75_at_[hidden]>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 5/13/22 5:24 AM, Peter Dimov via Boost wrote:
> John Maddock wrote:
>> I'm afraid my conclusion is that modules are simply not yet ready for
>> prime time.
> 
> If they ever are.
> 
> Modules can work for leaf libraries, but for libraries used as dependencies
> by other libraries, you'll encounter a situation where the same translation
> unit imports boost.lib or "boost/lib.hpp" in one place and then includes
> "boost/lib/something.hpp" in another, which is probably never going to
> work correctly.
This is sounds like how I thought it had to work to be effective.  If I 
understand this correctly, the whole modules concept is in fundamental 
conflict with the anything which uses the boost inclusion/dependency 
model - which is every module includes what it uses and nothing else.
In my view the whole modules idea is misconceived.  One more nail in 
coffin of C++ xx standard libraries.
It's time for use to seriously start moving on.
Robert Ramey
------------------------------
Message: 10
Date: Sat, 14 May 2022 00:16:26 +0300
From: "Peter Dimov" <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
Subject: Re: [boost] The Future of C++ and Boost - C++ Modules
Message-ID: <01f501d8670e$b57a64d0$206f2e70$@gmail.com>
Content-Type: text/plain;	charset="utf-8"
Robert Ramey wrote:
> On 5/13/22 5:24 AM, Peter Dimov via Boost wrote:
> > John Maddock wrote:
> 
> >> I'm afraid my conclusion is that modules are simply not yet ready for
> >> prime time.
> >
> > If they ever are.
> >
> > Modules can work for leaf libraries, but for libraries used as
> > dependencies by other libraries, you'll encounter a situation where
> > the same translation unit imports boost.lib or "boost/lib.hpp" in one
> > place and then includes "boost/lib/something.hpp" in another, which is
> > probably never going to work correctly.
> 
> This is sounds like how I thought it had to work to be effective.  If I understand
> this correctly, the whole modules concept is in fundamental conflict with the
> anything which uses the boost inclusion/dependency model - which is every
> module includes what it uses and nothing else.
> 
> In my view the whole modules idea is misconceived.  One more nail in coffin of
> C++ xx standard libraries.
> 
> It's time for use to seriously start moving on.
Looks like I was mistaken, though. At least with header units, i.e.
`import "boost/lib.hpp"`, it all seems to "just work" under MSVC. That is, the
compiler automatically merges the identical definitions from the sub-#includes.
------------------------------
Message: 11
Date: Fri, 13 May 2022 15:16:19 -0700
From: Marshall Clow <mclow.lists_at_[hidden]>
To: Boost Developers List <boost_at_[hidden]>
Cc: Rainer Deyke <rdeyke_at_[hidden]>
Subject: Re: [boost] cstring_view
Message-ID: <3C70E2E0-DC7A-4263-9D93-FCD8220A39BE_at_[hidden]>
Content-Type: text/plain;	charset=utf-8
On May 13, 2022, at 12:29 PM, Rainer Deyke via Boost <boost_at_[hidden]> wrote:
> 
> On 13.05.22 20:39, Marshall Clow via Boost wrote:
>> On May 13, 2022, at 11:18 AM, Peter Dimov via Boost <boost_at_[hidden]> wrote:
>>> In what scenarios will it not give you a null-terminated string?
>> 	char arr[6] = ?hello";
>> 	cstring_view csv(arr);
>> 	assert(strlen(csv.data())) == 5);
>>         arr[5] = ?!?;
>> 	assert(strlen(csv.data())) == 5);  // boom
>> ? Marshall
>> PS. It promises to give you a null-terminated string, but has no way to actually guarantee that.
> 
> That's an issue with views in general, not just cstring_view.
> 
>  std::string s = "hello";
>  string_view sv = s;
>  assert(sv.size() == 5);
>  s += "!";
>  assert(sv.size() == 5); // boom
I don?t see the problem here (and when I run the code I get no error - after adding the missing ?std::').
No assertion failure; no undefined behavior (unlike the cstring_view example)
? Marshall
------------------------------
Message: 12
Date: Sat, 14 May 2022 01:19:33 +0300
From: "Peter Dimov" <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
Subject: Re: [boost] cstring_view
Message-ID: <01fc01d86717$873b2a60$95b17f20$@gmail.com>
Content-Type: text/plain;	charset="utf-8"
Marshall Clow wrote:
> On May 13, 2022, at 12:29 PM, Rainer Deyke via Boost
> <boost_at_[hidden]> wrote:
> >
> > On 13.05.22 20:39, Marshall Clow via Boost wrote:
> >> On May 13, 2022, at 11:18 AM, Peter Dimov via Boost
> <boost_at_[hidden]> wrote:
> >>> In what scenarios will it not give you a null-terminated string?
> >> 	char arr[6] = ?hello";
> >> 	cstring_view csv(arr);
> >> 	assert(strlen(csv.data())) == 5);
> >>         arr[5] = ?!?;
> >> 	assert(strlen(csv.data())) == 5);  // boom ? Marshall PS. It
> >> promises to give you a null-terminated string, but has no way to actually
> guarantee that.
> >
> > That's an issue with views in general, not just cstring_view.
> >
> >  std::string s = "hello";
> >  string_view sv = s;
> >  assert(sv.size() == 5);
> >  s += "!";
> >  assert(sv.size() == 5); // boom
> 
> I don?t see the problem here (and when I run the code I get no error - after
> adding the missing ?std::').
> 
> No assertion failure; no undefined behavior (unlike the cstring_view example)
Only because "hello!" fits into the small buffer, I suspect. If `s` reallocates,
`sv` would be left dangling.
------------------------------
Subject: Digest Footer
_______________________________________________
Unsubscribe &amp; other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
------------------------------
End of Boost Digest, Vol 6704, Issue 5
**************************************