This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libstdc++/16612, empty basic_strings can't live in shared memory


On Wed, Aug 04, 2004 at 09:48:21AM -0400, Phil Edwards wrote:
> I can't recall ever hearing a good explanation for this requirement.
> If somebody can provide one, I'll change my stance, otherwise I'll go out
> on a limb and suggest we just ignore it.  (And document that we do so.)
> If we do, I will wager $5000ZWD that no real-world programmer will notice
> the omission, nor care.

The idea is probably that given

char const* s1 = "foobar";
std::string s2 = s1;

Then for any 'n' for which s1[n] returns a defined value,
s2[n] returns the same value.

However, since after

char const* p1 = &s2[s2.length() - 1];
char const* p2 = &s2[s2.length()];

still (p1 + 1) != p2, and *(p1 + 1) has undefined behaviour - I think that
indeed this is only confusing.

Worse - if the above causes *p2 to be defined, then what if
we do  char* p3 = &s2[s2.length()];  *p3 = 0;  ?  Core dump
because we try to write to a read-only section?

I agree that this whole extension is very unlogical; one
can't discourage a programmer enough to use it.

-- 
Carlo Wood <carlo@alinoe.com>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]