220 8742 <1006922a-7e3c-45d8-9a93-773c0df5d9f1@isocpp.org> article Path: news.gmane.org!not-for-mail From: Paul Tessier Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: string_view::is_null() Date: Mon, 20 Jan 2014 09:18:00 -0800 (PST) Lines: 159 Approved: news@gmane.org Message-ID: <1006922a-7e3c-45d8-9a93-773c0df5d9f1@isocpp.org> References: <104254A6-C69A-4571-8455-89D7E466D493@gmail.com> <6a95bf9c-55c9-4ae2-966f-d1b1f4df6a37@isocpp.org> <52D9E336.1060801@knejp.de> <1B534FD7-B385-4A7E-A718-3C73F0AB61DC@gmail.com> <11f13f8f-1270-427c-8942-94027a181ff4@isocpp.org> <20140119174431.GA16875@faust.lysator.liu.se> <20140119192238.GA19497@faust.lysator.liu.se> <60842af6-5ec4-4364-b2d5-a0be9d578bd6@isocpp.org> <6c82c4ae-c144-443a-81b2-ea1a6b645601@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_375_31824433.1390238281051" X-Trace: ger.gmane.org 1390238276 32506 80.91.229.3 (20 Jan 2014 17:17:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jan 2014 17:17:56 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDDYTQX56INBBSNU6WLAKGQEUQBBYQA@isocpp.org Mon Jan 20 18:18:03 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f199.google.com ([209.85.223.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W5IU7-0004Z0-GN for gclcip-std-proposals@m.gmane.org; Mon, 20 Jan 2014 18:18:03 +0100 Original-Received: by mail-ie0-f199.google.com with SMTP id x13sf29353171ief.10 for ; Mon, 20 Jan 2014 09:18:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=MqUMiLp72DanA2Ru4PGimfdht8f0reo0K1xdQWDKFyA=; b=mxWcr8oJ1ygVchoFgMRj25JgF4u3f5lZHfaPia6lMNX3N5OC42F4ook8CqqK81MA7n B0seUS3SSl2pch5AUdGTFGVh2YLtNnLG0NNyCTQUVEZYFkSMSAKW87oYXj4F4EMrA2xY pJr9M1y1n8AP19kvbAtItvYEnYBydvUTdryEsiFLepHPEe7huAK3jRsLGSmuuZAhRAiG 2JAMYe5e3qpRAAcuk4++ymR1Ie2vfAHGl/waXQHII3WCd91BN7+/NTUcPURFsjl5jJVm 9DvhWkWpfmfH/eqVn8Mcm7Qd2y8C45cHinuDsfGegcjxaVD50YW2P+C0lw8aUxjWXR7a StNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=MqUMiLp72DanA2Ru4PGimfdht8f0reo0K1xdQWDKFyA=; b=jGSLDPZOWBQBcrOLHkIhO/set5V6Ar6mDQtyGVK++ZvDvnbkB+C3ilOSWlI2RCykEd j3IgNkpBjC8zqlulxOkS8MwgBG9zOceXYMiSUcwk4mYv2+5cFt3osth590J64pcW+53r YX7tX0gLSIkmdqV1Pn0edPfE9QFnBLFVxlGCQ3FYzjyrqc9kpmVV1xPQ6M4+8gnTjDg6 9159EtsgMrRzkg0cTJClOYeKm1XaYzcNEV9oZcCdQ+3ZAtcUxamFHQfRMj+OcVPpXIiW UtvmbI6zlDn4y+pUahqQzitlfaQ6ANgBPitxg0skHs/Bb8+3BASfmHHyqt64WJ6zGJy2 CWQw== X-Gm-Message-State: ALoCoQl0J6r+uvT4HfBLWHjsmPdfWroBZilOeYrOQACbBCo+7sAXMuQyQaeKQY0+e6utK+9XloDh X-Received: by 10.182.104.200 with SMTP id gg8mr1149541obb.45.1390238282275; Mon, 20 Jan 2014 09:18:02 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.72.66 with SMTP id b2ls1675150qev.36.gmail; Mon, 20 Jan 2014 09:18:01 -0800 (PST) X-Received: by 10.140.109.244 with SMTP id l107mr25230qgf.28.1390238281718; Mon, 20 Jan 2014 09:18:01 -0800 (PST) In-Reply-To: X-Original-Sender: phernost@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:8742 Archived-At: ------=_Part_375_31824433.1390238281051 Content-Type: text/plain; charset=UTF-8 On Monday, January 20, 2014 1:25:58 AM UTC-5, Nevin ":-)" Liber wrote: > > On 20 January 2014 00:12, Jeffrey Yasskin > > wrote: > >> > My personal preference for all this is that string_view(nullptr, 0) be >> > allowed, and it is a Quality of Implementation issue whether or not >> > sv.data() can ever return a nullptr; i.e., it would be allowed to >> return any >> > legal pointer it wants for an empty string_view. >> >> That's interesting. It's easier to both specify and implement to just >> say that string_view(x, y).data()==x and string_view(x, y).size()==y, >> assuming [x, x+y) is a valid range. Why would you special-case data() >> to return arbitrary things when y==0? >> > > A debugging implementation may want to ensure that developers aren't > dependent on "knowing" that a nullptr was passed in. > -- > Nevin ":-)" Liber > (847) > 691-1404 > A simple implementation would be much better. Allowing the pointer and size to pass through directly would allow one to track down their origins, if it is a cause for concern. Preventing null solves nothing, a mishandled view will still be mishandled. Mutating a null input is equally pointless in debugging aspect, as you have allowed a logical input to be changed into a different input which will be harder to trace back to the origin. None of these arguments against have been of the fashion of preventing common programming pitfalls. Just because std::string will never produce or accept a range beginning a null, does not mean it is logical or reasonable in all cases. [ P, P+N ) is a valid range for any non-negative N, therefore [ P, P ) is a valid range, for any P, even when P is in a protected segment. Validity of a range only describes if it is rational. It does not describe if it is rational to use it in all contexts. Any P in a protected segment will trap when dereferenced. There is no way to protected against this. Dereferencing an empty range is almost always a mistake, no matter where it is located. I would also argue against string_view( char* ) doing runtime null checks and creating an empty view, as this only defends against ( P == null ) and not P being in protected memory, of which null falls into. Asserts on null, would be more reasonable. Although in this case it can be argued the other way as it is a common practice to signal an empty C string with a null. Empty C strings should be "" and not null but, there is no changing the past. string_view( null ) being [ null, null ) is not my preference but, something that I cannot argue against as being unreasonable. ( string_view( null ) : string_view( rand(), 0 ) {} ) on the other hand is not reasonable. If string_view cannot accept C string valid ranges, but only the ranges allow by std:string, it's C string constructors and support should be deleted. It should work as any novice would expect. A range passed in will be the same range returned. Nothing more complicated than a thin wrapper around a valid range with string helper methods. -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_375_31824433.1390238281051 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Monday, January 20, 2014 1:25:58 AM UTC-5, Nevi= n ":-)" Liber wrote:
On 20 January 2014 00:12, Jeffrey Yasskin <jyas...@google.com> wrote:=
> My personal preference for all thi= s is that string_view(nullptr, 0) be
> allowed, and it is a Quality of Implementation issue whether or not > sv.data() can ever return a nullptr; i.e., it would be allowed to retu= rn any
> legal pointer it wants for an empty string_view.

That's interesting. It's easier to both specify and implement to just=
say that string_view(x, y).data()=3D=3Dx and string_view(x, y).size()=3D=3D= y,
assuming [x, x+y) is a valid range. Why would you special-case data()
to return arbitrary things when y=3D=3D0?

A debugging implementation may want to ensure that developers aren't dep= endent on "knowing" that a nullptr was passed in.
--
 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  (847) 691-1404

A simple implementation would be much bet= ter.  Allowing the pointer and size to pass through directly would all= ow one to track down their origins, if it is a cause for concern.  Pre= venting null solves nothing, a mishandled view will still be mishandled.&nb= sp; Mutating a null input is equally pointless in debugging aspect, as you = have allowed a logical input to be changed into a different input which wil= l be harder to trace back to the origin.

None of these arguments aga= inst have been of the fashion of preventing=20 common programming pitfalls.  Just because std::string will never=20 produce or accept a range beginning a null, does not mean it is logical=20 or reasonable in all cases. [ P, P+N ) is a valid range for any non-negativ= e N, therefore [ P, P ) is a valid range, for any P, even=20 when P is in a protected segment.  Validity of a range only describes = if it is rational.  It does not describe if it is rational to use it i= n all contexts.  Any P in a protected segment will trap when dereferen= ced.  There is no way to protected against this.  Dereferencing a= n empty range is almost always a mistake, no matter where it is located.
I would also argue against string_view( char* ) doing runtime null che= cks and creating an empty view, as this only defends against ( P =3D=3D nul= l ) and not P being in protected memory, of which null falls into.  As= serts on null, would be more reasonable.  Although in this case it can= be argued the other way as it is a common practice to signal an empty C st= ring with a null.  Empty C strings should be "" and not null but, ther= e is no changing the past. string_view( null ) being [ null, null ) is not = my preference but, something that I cannot argue against as being unreasona= ble.  ( string_view( null ) : string_view( rand(), 0 ) {} ) on the oth= er hand is not reasonable.

If string_view cannot accept C string val= id ranges, but only the ranges allow by std:string, it's C string construct= ors and support should be deleted.  It should work as any novice would= expect.  A range passed in will be the same range returned.  Not= hing more complicated than a thin wrapper around a valid range with string = helper methods.




--
 
---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_375_31824433.1390238281051-- .