Henrik Nordstrom wrote:
mån 2007-05-28 klockan 23:17 +0800 skrev Adrian Chadd:
Personally, I think we've all learnt a bit from this experience, and
there's a clearer path forward for tidying up the string (ab)uses going
on in the codebase.
I'm all for calling this a lesson learnt, backing it
-- Please note that I am only [briefly] responding in hope to improve
future SqString patches. I do realize that this is no longer relevant to
Squid 3.0.
On Sat, 2007-05-26 at 18:41 +1200, Amos Jeffries wrote:
Alex Rousskov wrote:
And you want to remove those methods because ...? Can you
Hi guys,
Could we please make a decision about SqString? I'm leaning towards
backing it out for now, releasing Squid-3, and then doing a phased
introduction post squid-3 - starting with just accessor method
changes..
Adrian
Adrian Chadd wrote:
Hi guys,
Could we please make a decision about SqString? I'm leaning towards
backing it out for now, releasing Squid-3, and then doing a phased
introduction post squid-3 - starting with just accessor method
changes..
Adrian
I was waiting on Alex (or anyones) response
On Tue, May 29, 2007, Amos Jeffries wrote:
I was waiting on Alex (or anyones) response to my last email, before
going either way.
well, count this as a reply to your last email. :)
partial backout: proposal (no responses)
full backout: 3 for, 2 wavering with doubts, 1 abstention.
places that worry me:
1) String::buf() did not return NULL for an empty but initialized
String. SqString::empty() does:
WTF? here is the original code:
char const *
String::buf() const
{
return buf_;
}
WHERE: buf_ is either NULL, or a char*. NO initialisation at all going
on there.
WHERE
Is there any reason for:
-if (stringHasWhitespace(host)) {
+if (strpbrk(host, w_space) != NULL) {
Can't you fix stringHasWhitespace, which is more explicit?
Adrian
Alex Rousskov wrote:
On Fri, 2007-05-25 at 20:39 +1200, Amos Jeffries wrote:
I have just been experimenting with a few options short of a full backout.
My initial idea of dropping the constructor drags the changes into areas
the initial patch didn't touch. No go there.
Yes, of course.
I
uncomfortable with the changes in the latest patch because they
change the working code. I did not do full analysis, but here are a few
specific places that worry me:
1) String::buf() did not return NULL for an empty but initialized
String. SqString::empty() does:
-if (target sct
Should we back out SqString for now until the implicit cast issues have
been analyzed in more detail, or try fixing it somehow for the 3.0
release?
http://www.squid-cache.org/bugs/show_bug.cgi?id=1970
My vote is to defer the SqString change to 3.1, or at least after 3.0
has been branched from
On Thu, 2007-05-24 at 11:19 +0200, Henrik Nordstrom wrote:
Should we back out SqString for now until the implicit cast issues have
been analyzed in more detail, or try fixing it somehow for the 3.0
release?
http://www.squid-cache.org/bugs/show_bug.cgi?id=1970
My vote is to defer
Hi there,
Before SqString patch applied, squid3 looked stable, I had days to see a
problem.
The SqString had unpredicted effects in squid3 like the bug 1970. And
maybe there are other issues not appeared yet. It was not enough
analyzed before applied.
Regards,
Christos
PS. Last weekend
On Thu, 2007-05-24 at 11:19 +0200, Henrik Nordstrom wrote:
Should we back out SqString for now until the implicit cast issues have
been analyzed in more detail, or try fixing it somehow for the 3.0
release?
http://www.squid-cache.org/bugs/show_bug.cgi?id=1970
My vote is to defer
On Thu, May 24, 2007, Alex Rousskov wrote:
I still think SqString API changes should not be in 3.0, but I do not
have a strong opinion and do not want to be the one backing them out.
We could adopt a middle-ground solution. The changes limited to renaming
String methods to match std::string
14 matches
Mail list logo
