On 27/09/2013 7:43 a.m., Kinkie wrote:
)Thanks, and sorry for taking so long.
The mail is long, if you want to skip to the main topic, it's the one
about copyright - it is an open point.
On Mon, Aug 26, 2013 at 4:22 AM, Alex Rousskov wrote:
On 07/30/2013 03:56 AM, Kinkie wrote:
Ok, it's now done, including documentation.
lp:~squid/squid/stringng-cherrypick has the most uptodate code.
I found a few bugs in stringng-cherrypick r12764. The rest is polishing.
+SBuf &
+SBuf::append(const char * S, size_type Ssize)
+{
+ Must (Ssize == npos || Ssize >= 0);
+
+ if (S == NULL)
+ return *this;
Do you think we should also add a Must() that NULL S has npos or zero Ssize?
It may lead to greater correctness, but is that an error condition
worth terminating over? I'd rather document that in case of S being
NULL, Ssize is ignored. Which led me to notice that the documentation
was stale. Updated in this regard, let me know if you think we should
Must() regardless.
IIRC exiting on NULL strings is one of the behaviours of xstrdup() which
we were trying to fix with SBuf.
The SBuf buffer existence and size not being in perfect sync is a
critical bug IMHO.
I think a Must() here is worth adding.
+ * SBuf.cc (C) 2008 Francesco Chemolli <kin...@squid-cache.org>
If you do not mind, please drop the copyright statements (here and in
other files you are adding). You are not the only person contributing
this code, and managing per-file copyright claims correctly is
practically impossible (incomplete copyright information in your files
is a case in point).
That would apply to the whole Squid source tree (there's plenty of
files which carry copyright notices by individual contributors).
But this is a matter of copyright policy (and possible assignment
thereof) which should probably be tackled at the Foundation level.
Among other questions, once I remove this, what copyright statement
should I put? Squid Software Foundation (therefore assigning
copyright)? Nothing? Wouldn't then be automatically be reassigned to
the only entity named in the COPYRIGHT file, University of California?
It can be argued that the per-file copyright belongs to the main
contributor, while each additional contributor has copyright over
their respective contributions. This would seem to be in line with
some past contributions...
This is too messy to address here, it'd be however nice if there was a
guideline.
I know you guys have discussed this further. But I disagree with Alex on
what to suggest, at least on new code files like these.
IMHO as the main author of this code you get to choose whether or not
there is a copyright statement or not. Were you a one-off contributor I
would be requesting that you *do* add your copyright statement. It is
the responsibility of later contributors to decide if they want to leave
you with majority copyright or replace with themselves and reference
your work as ispiration (we have many examples of that in the code too).
The whole copyright situation boils down to your choice in the end. Any
guideline we produce will at best be options on *how* to label your
copyrights not *whether* to do so.
As for this code specifically I see the unit tests in StringNG as having
three authors with various parts by each of us three. And the majority
of the main SBuf/MemBlob files being just you (Kinkie) - perhapse
"inspired by" others code.
The ambiguity starts with the fact that we do not yet have a guideline
and nobody is auditing copyright on new contributions so until that
actually starts your new disclaimer now will get slow bitrot like Alex
is worried about. As you pointed out that is nothing new and your choice
about marking your rights is not going to substantially affect the vast
amount of work required to audit the code copyright accuracy once the
guidelines are in place.
FYI: I have a proposal for managing the CREDITS copyright file. But that
discussion is on hold in core@ and has little impact on detailed
accuracy of the statements being collated into it. (Probably time to
shift it here actually, since it is technical details rather than legal.)
I suspect you can fix all of the above without another round of review.
However, please do not forget that you wanted to make (or consider
making?) size_type unsigned once everybody is happy with the code (but
before merging it).
Yes, that's the planned next step.
It seems to be working, however there is an annoyance when someone
passes a negative integer, which gets automatically cast into
veryLargeInteger unless compile-time countermeasures are taken against
automatic type conversion (I've used the technique suggested here:
http://stackoverflow.com/questions/175689/can-you-use-keyword-explicit-to-prevent-automatic-conversion-of-method-parameter);
if this gets done, any integer literal must be explicitly qualified as
unsigned.
Currently being tested at lp:~squid/squid/stringng (without the
-cherrypick). If everyone is ok with this approach, I'm implementing
it throughout.
Thanks for your feedback.
commented on other email.
Amos
