home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c++.moderated      Moderated discussion of C++ superhackery      33,346 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 33,302 of 33,346   
   Chris Vine to Seungbeom Kim   
   Re: rvalue-reference-with-default instea   
   03 Apr 14 21:47:37   
   
   From: chris@cvine--nospam--.freeserve.co.uk   
      
   On Thu,  3 Apr 2014 16:28:00 CST   
   Seungbeom Kim  wrote:   
   > On 2014-04-02 18:11, Florian Weimer wrote:   
   > > * Martin B.:   
   > >>   
   > >>  result.resize(MAX_PATH);   
   > >>  ssize_t ret = readlink(path, &result[0], result.size());   
   > >   
   > > Isn't this technically undefined?  std::string supposedly support a   
   > > non-contiguous representation, and only the data() and c_str()   
   > > members return pointers to const char arrays.   
   >   
   > The contiguity requirement has been pointed out, but is it still   
   > okay to modify the underlying buffer of std::basic_string like this?   
   >   
   > 21.4.7.1 requires that "The program shall not alter any of the values   
   > stored in the character array," and I guess that obviously applies to   
   > modification through c_str() or data(), which already return 'const   
   > charT*' anyway. And their return values should equal &operator[](0),   
   > but 21.4.5 doesn't impose any restriction on modification through   
   > operator[].   
   >   
   > So, am I correct to say it's fine to modify s through &s[0] but UB   
   > through const_cast(s.data()), even though their values are   
   > the same?   
      
   Given that (a) the non-const operator() and the non-const front()   
   methods return a non-const reference, and the non-const begin() method   
   returns an iterator to non-const, and (b) the contiguity requirement,   
   then it seems to me that that must follow.  I have certainly relied on   
   it.   
      
   I suspect that this outcome is a residue of C++98 strings, which did not   
   require contiguity in string storage, but did do so for the return   
   value of the c_str() and data() methods.  So those methods may have   
   copied the non-contiguous string into const contiguous storage.  But I   
   do not think any string implementation ever did so.   
      
   Chris   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca