From stdcxx-dev-return-6505-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org Thu Dec 13 23:45:33 2007 Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 35364 invoked from network); 13 Dec 2007 23:45:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Dec 2007 23:45:33 -0000 Received: (qmail 60266 invoked by uid 500); 13 Dec 2007 23:45:21 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 60206 invoked by uid 500); 13 Dec 2007 23:45:21 -0000 Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: stdcxx-dev@incubator.apache.org Delivered-To: mailing list stdcxx-dev@incubator.apache.org Received: (qmail 60195 invoked by uid 99); 13 Dec 2007 23:45:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Dec 2007 15:45:21 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates 209.85.198.185 as permitted sender) Received: from [209.85.198.185] (HELO rv-out-0910.google.com) (209.85.198.185) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Dec 2007 23:44:59 +0000 Received: by rv-out-0910.google.com with SMTP id k20so773167rvb.0 for ; Thu, 13 Dec 2007 15:45:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; bh=kfvUhV2pkggkp4/tlr3QKYZwdrGWVf9sfrDR6Hkcbpc=; b=PcoXx7tZmvEB7zlsBh8JkwAqIsuVf+7ImZc1JOgC5CpEBUE8HZfGBKq4Cv19gTsR661kAIsxDxPcfBq+B4akOTe3rdrmx68sxo/Jw8E5nklffwbPxl9mplpNL09pHr3nMeZPbrkSmK2I1Q9IxspoFqRumpVCwlzP6QCBE7Fosz0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=JKgf0THfIzk1VrWL0om6m2g40kCbVWLHYLTNnRLMo1kW/jFx/+xh+8cqo1XMom9HRZZCK18W3bQgIXWo2rjpLn3qBJxwvpuGFOO/m8Wz3Qk3lMGKl6v2RUV7lH6E4+yd0vq5xuwl/0FXpunSzePnaNWCyYECPIoyE5uKvPMAZuM= Received: by 10.140.128.11 with SMTP id a11mr1505626rvd.232.1197589502213; Thu, 13 Dec 2007 15:45:02 -0800 (PST) Received: from localhost.localdomain ( [71.229.200.170]) by mx.google.com with ESMTPS id k41sm7049706rvb.2007.12.13.15.44.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 Dec 2007 15:44:59 -0800 (PST) Message-ID: <4761C3FA.60602@roguewave.com> Date: Thu, 13 Dec 2007 16:44:58 -0700 From: Martin Sebor Organization: Rogue Wave Software, Inc. User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: stdcxx-dev@incubator.apache.org Subject: Re: [RFC] stdcxx release process, second draft References: <472951EF.6070105@roguewave.com> <13719498.post@talk.nabble.com> <13849210.post@talk.nabble.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Martin Sebor X-Virus-Checked: Checked by ClamAV on apache.org Travis Vitek wrote: > > >> Travis Vitek wrote >> >> Martin Sebor wrote: >>> I've incorporated everyone's feedback and committed an updated >>> version with a number of enhancements of my own. Among the most >>> important are the new Goals section with suggested frequencies of >>> releases, and the integration of the Version Policy (I plan to delete >>> versions.html). Let me know what you think. >>> >>> http://incubator.apache.org/stdcxx/releases.html >>> >> Martin, >> >> I found this page that documents a few do's and dont's of binary >> compatibility. I realize that most of the tricky issues involve inline >> functions or templates, but this gives a list of the common pitfalls. >> >> http://tinyurl.com/2gf38p >> >> Travis > > Here are some examples that I came up with. Each case is written in a > pseudo diff format. Excellent! See my comments below. > > Travis > > // neither source nor binary compatible. not source compatible > // if user might take address of member function A::f. > struct A > { > - int f() const { return 1; } > + int f(int i = 1) const { return i; } > }; > > // alternative is source and binary compatible. can be changed > // to a default argument in next source incompatible release. > struct A > { > int f() const { return 1; } > + int f(int i) const { return i; } > }; > > // is binary compatible, but not be source compatible because > // the compiler has no way to handle A().f(1) > struct A > { > int f(long i) const { return 2; } > + int f(unsigned i) const { return 2; } > }; > I would tend to throw these in the bag of "obvious no-no's." > // not binary compatible, changing access specifier on windows is a > no-no. if the > // new access modifier is more restricted, this may be source > incompatible, but > // only if the user code calls or takes the address of the function. > class A > { > -private: > +public: > int f() const { return 1; } > }; This one is much less obvious and so it might be worth mentioning in the document. > > // source and binary compatible, not functionally compatible. f() will > square v > // in user code, and ctor will square v in library code. if an instance > is > // created in library and passed to user code, it will be squared > twice. if the > // other way, it will not be squared at all. > // > // if the definitions were outlined, this would be compatible. > class A > { > public: > - A(float f) : v(f) { } > - float f() const { return v*v; } > + A(float f) : v(f*f) { } > + float f() const { return v; } > private: > float v; > }; This is an interesting case. Why (when) does it matter that the result of f() is different? What does it mean for STDCXX-226? > > > // binary and source compatible, but not functionally compatible > // because call to g() is inlined. > // > // this would be compatible if f() were outlined, or g() behaved > // the same for input values 2 and 3. > struct A > { > - void f() { g(2); } > + void f() { g(3); } > void g(int i); > }; Same as above. > > > // it appears that this could be fully compatible in some cases. > // it might not be source/functionally compatible if the user is > // exposed to this type. a switch on an E instance might cause a > // default block to be hit, which could trigger a failure in user > // code. > // > // if A::Z is used as a `last enum' marker, this might introduce > // a binary compatibility issue if a global or member array is > // declared to have A::Z elements. > // > // this might also be binary incompatible if the enum is persisted. > struct A > { > - enum E { W, X, Z }; > + enum E { W, X, Y, Z }; > }; I'd say this is both source and binary incompatible. Consider: switch (e) { case A::Z: break; case 4: break; // okay in version 1 but error on version 2 } and: template struct S { }; void foo (S()); // ==> mangled as foo_S_A_2 in version 1 // but foo_S_A_3 in version 2 Thanks again. These are exactly the kind of examples I was hoping for: innocuous looking changes that are fully compatible in most situations but can be actually be breaking in some edge cases. Martin