Re: stringng-cherrypick r12764

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 <kinkie_at_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
Received on Fri Sep 27 2013 - 09:53:04 MDT