Re: Adding to G++: Adding a warning on throwing unspecified exceptions.
Thanks for all the links. I knew there were people wanting this but I didn't quite get how big an issue it was. Brain Dessent wrote: > You're essentially trusting that all > exception specifiers for every function in the program and *all* library > code are always present and always correct which is a huge leap of faith > that I don't think is supported by reality. I agree that it won't be very useful initially due to lots of third party code like boost neither defining nor adhering exception restrictions 100% of the time (STL may be guilty also). However, this is a catch 22. Why not provide the mechanism for verifying exception specifications so that these libraries can, in future, become fully compliant? It won't take much work, especially when you can get a warning telling you exactly what you need to change, and the only thing you need to do 99% of the time is add throw() clauses to definitions and declarations. I bet you could get boost & STL compliant within a week even if they had 0 throw() clauses to begin with. Brain Dessent wrote: > The general consensus is that doing this at compile time cannot give you > anything useful, because the compiler can only see one compilation unit > at a time and so the only thing it can know of all the downstream > functions that are in other CUs is what is provided in the exception > specifiers of the prototypes. So, once the other CUs adhere to their prototype exception specifiers, this becomes OK. I definately intend all of my own CUs to adhere. Also, you rely on CUs doing what they say in all other means (eg not modifying const-passed references), why not rely on their exception specifiers as long as they say you can. And if only some (ie your own) CUs adhere, that's by no means worse than none adhering (as long as you are aware that some don't). > You should certainly look at EDoc++, mentioned in the above threads. http://edoc.sourceforge.net/ This is definitely interesting, however our goals are a bit different. EDoc++ is about checking that there is no chance a thrown that actually exists in code can propogate to somewhere where it will terminate the app due to being unhandled. It's not about enforcing code requirements. For example, foo() throw() can call bar() throw(zug) as long as it doesn't actually throw a zug, or call anything that does. I would like an environment where the above example is considered poor practice. One thing I read there that concerned me was when it was said that some compilers do "pessimizations" such as not inlining functions with throw clauses or placing try/catch blocks around calls to these. I hope that these compilers aren't mainstream. Also, I don't think that consideration of current bad implementations should factor into the decision. If people decide to use exception specifications more these compilers will either get fixed or become slower. So overall: - Lots of people request it (for good reasons or bad). Even bad reasons mean there's an advantage from providing this as an option, ie showing that it doesn't do what they want. - Nobody has yet shown me any fundamental problems with implementing this, apart from my typedefs of function pointers not being allowed exception specifications which, while annoying, can be avoided. - It helps code comply with what it says (if you read the throw() clause in what seems to be its spirit: as an indication of what may be thrown). - It's fully optional, and off by default. - The only real issue is that it will complain about third party code that doesn't yet "comply". But by this same token this helps third party code become "compliant" if the authors desire it to be. There's also the possibility of adding a modification that could ignore calls to functions declared inside a whitelist of headers like to further reduce this. - GCC probably doesn't do the above pessimizations (I guess I'll have to look into this). Where's the downside?
Re: Adding to G++: Adding a warning on throwing unspecified exceptions.
> I agree that it won't be very useful initially due to lots of third > party code like boost neither defining nor adhering exception > restrictions 100% of the time (STL may be guilty also). However, this > is a catch 22. Why not provide the mechanism for verifying exception > specifications so that these libraries can, in future, become fully > compliant? It won't take much work, especially when you can get a > warning telling you exactly what you need to change, and the only > thing you need to do 99% of the time is add throw() clauses to > definitions and declarations. I bet you could get boost & STL > compliant within a week even if they had 0 throw() clauses to begin > with. > > One of the problems i see with this is generic template classes like the STL containers. The author of the template class or container can't know what types of exceptions will be thrown from them, so you must define them as being able to throw all exceptions (which is how they are currently). Then if those containers are used all over the place then you are back to square one. Personally i am starting to see that usage of the exception specifier in C++ is "almost" useless (I find them a bit more useful with EDoc++ but i still only use them very rarely). I initially thought the same way as you are now, but in the end decided it was necessary to construct a complete list of exceptions that can be thrown before then applying such rules. This is what EDoc++ does. It first calculates all possible exceptions, then it performs all sorts of analysis to enforce things like exception specifiers (and much more). After developing EDoc++, i have also realized how pervasive exceptions can be in C++ code, which works against the sorts of checks that can be done within a single translation unit. I had to go to lengths to provide a "suppressions" system for EDoc++, simply because almost all code can throw all sorts of exceptions i had never heard of before. A developer "generally" is not interested in exceptions like: __gnu_cxx::recursive_init. But after writing EDoc++ i found exceptions like this turn up all over the place, though they should not occur in normal operation... With all this said though. If your purpose is to learn more about GCC internals, then i think it would be a good project to undertake to achieve that. You may have to do so though, with the understanding that the maintainers may not choose to accept your patch into the official GCC release. I don't know if they would or not, as i am not a GCC maintainer but it would be worth getting clarification before doing the task. On a slight side note, there is a feature i have been postponing from EDoc++ until "the distant future". It is to provide "meta-data" or code "markup" which can be used to enforce certain restrictions on code being used. This is primarily of use for defining a "contract" when writing template code that wants to define a certain "exception guarantee". For example, i assume you are familiar with the various "guarantees" that have been described in literature about exceptions in C++ (if not then it is worth looking up. It sure opened my eyes to writing safer and better code in the presence of exceptions). To make some generic container satisfy the "strong guarantee" will require certain restrictions on the type used to instantiate the template. A good example of this is that the destructor for the type must not throw an exception. For a given generic implementation, there may be additional restrictions as well. If these restrictions are not met, then the container will no longer meet the "strong guarantee". I wish to define a method of marking up source code such that those requirements are described inline in the code of the template implementation such that someone who instantiates the template with a particular type can then run EDoc++ over their code and be warned when that particular instantiation may break the requirements. Anyhow, this is a preliminary idea and i just don't have the time now to look at implementing it. It will likely require changes to the C++ parser and front end to insert extra nodes into the tree for this markup. I am also not sure if others would accept such a modification into the official GCC release unless it was generic enough to be used for other purposes (maybe such as providing optimization hints for certain segments of code or other forms of markup). Thanks, Brendon.
Re: char* problems
I have no gcc 4.1.2 at hand. but I just had a try with gcc-4.1.0 and gcc-4.2.0 which compiled a simple testcase with no errors or warnings. additionally, I had a try with some other compiler than gcc to compile it. a warning issued. I think it's possibly too strict of gcc raising a error on sch case. any options that you added when compiling? 2008/9/15 Douglas Gemignani <[EMAIL PROTECTED]>: > Dear friends, > > I have serious issues when compiling using gcc 4.1.2, everytime i try > to pass a unsigned char* to a function that receives char*, i got > errors, it also happens when passing const char* to char* or unsigned > char* functions. > > This is really annoying and the code is a working one in other system, > i would like to foce the compilation, i already tryed to use the > following flags: > -fno-const-strings > -Wwrite-strings > -funsigned-char > > but none of them worked. > > Is there something that i can tell to gcc, other than making casts all > over the code? > Thanks > > []s > Douglas > -- Best wishes! Yours, Lijuan Hai _ _ (_)(_) (,,) =()= ((__)\ _|L\___/
Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
Peter O'Gorman wrote: > Yuhong Bao wrote: >> and Apple uses GCC (which is now under GPLv3) and Mac OS X on it. >> Unfortunately, the iPhone is incompatible with GPLv3, if you want more see >> the link I mentioned. > > Apple does not use a GPLv3 version of GCC. Ah, actually I think I now see the OP's point. Apple is scared of the GPLv3 because the iPhone might violate it, so they are not contributing to anything that falls under the GPLv3. It is indeed in-topic. There are four Darwin maintainers listed in MAINTAINERS: darwin port Dale Johannesen [EMAIL PROTECTED] darwin port Mike Stump [EMAIL PROTECTED] darwin port Eric Christopher[EMAIL PROTECTED] darwin port Stan Shebs [EMAIL PROTECTED] and three of them are not allowed to read the GCC patches mailing list. They might do something if CCed, but not necessarily so. Same for Objective-C/C++: objective-c/c++ Mike Stump [EMAIL PROTECTED] objective-c/c++ Stan Shebs [EMAIL PROTECTED] Now I wonder: 1) does it make sense to keep a maintainer category that is known to be inactive? 2) who should then get maintainership of darwin? note that there are some patches for darwin like this one: http://article.gmane.org/gmane.comp.gcc.patches/172498 It's sad, but I think that there is need for the SC to take action on this. Paolo
Re: Adding to G++: Adding a warning on throwing unspecified exceptions.
Brendon Costa said:
> The author of the template class or container can't know
> what types of exceptions will be thrown from them, so you must define
> them as being able to throw all exceptions (which is how they are
> currently).
Ouch, you have a point. But couldn't you put this round the other way.
Place the onus on the user of the template to comply with the
exception guarantees inside the template. Unfortunately that would
likely cause problems with some existing code.
I'm trying to think whether this would actually prevent well-designed
future code. All I can really come up with so far is copying a vector
of vectors and having bad_alloc thrown during a copy constructor
partway through, but I think bad_alloc should be allowed. Other
things, such as constructing a vector of N thread objects that can
throw on failed thread creation, might be better off undergoing a
redesign.
In other words, would you gain more from a tight exception
specification than you'd lose by not being able to do this?
Another thought that could be a workaround: Is it possible to do
anything like this?
===
template
int foo() throw(E) {}
===
IE using a template parameter to specify what can be thrown. (Esp with
a C++0X variadic).
Sorry I won't be near a compiler to test this for many an hour, if I
test it and can get it working I'll reply.
Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
On Wed, Sep 24, 2008 at 11:47:18AM +0200, Paolo Bonzini wrote: > Peter O'Gorman wrote: > > Yuhong Bao wrote: > >> and Apple uses GCC (which is now under GPLv3) and Mac OS X on it. > >> Unfortunately, the iPhone is incompatible with GPLv3, if you want more see > >> the link I mentioned. > > > > Apple does not use a GPLv3 version of GCC. > > Ah, actually I think I now see the OP's point. Apple is scared of the > GPLv3 because the iPhone might violate it, so they are not contributing > to anything that falls under the GPLv3. > > It is indeed in-topic. There are four Darwin maintainers listed in > MAINTAINERS: > > darwin port Dale Johannesen [EMAIL PROTECTED] > darwin port Mike Stump [EMAIL PROTECTED] > darwin port Eric Christopher[EMAIL PROTECTED] > darwin port Stan Shebs [EMAIL PROTECTED] > > and three of them are not allowed to read the GCC patches mailing list. >They might do something if CCed, but not necessarily so. Same for > Objective-C/C++: > > objective-c/c++ Mike Stump [EMAIL PROTECTED] > objective-c/c++ Stan Shebs [EMAIL PROTECTED] > > > Now I wonder: > > 1) does it make sense to keep a maintainer category that is known to be > inactive? > > 2) who should then get maintainership of darwin? note that there are > some patches for darwin like this one: > http://article.gmane.org/gmane.comp.gcc.patches/172498 > > It's sad, but I think that there is need for the SC to take action on this. > > Paolo Well at least that explains their total inactivity in the last year. Is Dale the one still allowed to read the gcc-patches mailing list? I recall that he posted in the last year that he would be more active in gcc (but I can't find that message at the moment). I had attributed the fact that they were not active to the emphasis on llvm at Apple. However if GPLv3 is such a huge issue at Apple, it does make one wonder if llvm will ever see a gcc front-end newer than the current 4.2 one. Jack
Re: Apple, iPhone, and GPLv3 troubles
"Yuhong Bao" <[EMAIL PROTECTED]> writes: >> 1) This is offtopic. > Yeah, but I want to bring this up because I can tell it is affecting GCC > development. > >>From http://gcc.gnu.org/ml/gcc/2008-02/msg00523.html: > "> If someone steps forward, are you allowed to follow the patches list > We can't read the patches nor gcc list. >> and give feedback and/or approve patches for new contributors? I assume >> this is possible since you helped out with objc++ review for me just >> recently. > Only because I was cced on it." > >>From http://gcc.gnu.org/ml/gcc/2008-02/msg00516.html: > "> Are current Darwin maintainers working on fixing anything in the FSF > sources? > Currently no. The transition to GPL v3 is problematic for us in the > short/mid term. :-( Longer term, we'll see how it goes." Apple's dislike of GPLv3 is a problem for gcc, yes. However, Apple is moving to a new free compiler, LLVM, so they have little incentive to fix the problem. My understanding of Apple's current position is that they won't take any action until they see the final version of the gcc runtime license. gcc's runtime libraries have not yet been updated to GPLv3, because the FSF has not yet settled on the final version of the appropriate license to use for those libraries (yes, this has taken a ridiculously long time, largely because the FSF is trying to get the plugin license right at the same time). Until the runtime library licenses have been updated, there is little point in discussing Apple's future contributions to gcc. Since Apple is moving to a new compiler, it is likely that Apple will have negligible future contributions to gcc in any case, though some individuals employed by Apple may be able to once again contribute on their own time. >> 2) You didn't say what the problem is. I certainly can't figure it >> out from the links you posted. > Basically, what happened is that Apple created a Tivoized device called the > iPhone, > and Apple uses GCC (which is now under GPLv3) and Mac OS X on it. > Unfortunately, the iPhone is incompatible with GPLv3, if you want more see > the link I mentioned. Using gcc to compile your code does not impose any licensing requirements on that code. Many people use gcc to create proprietary software. This is understood and is in fact desirable. This is not a problem to be solved. Morevoer, as Peter pointed out, GPLv3 is a total red herring here, since Apple has very carefully avoided any use of it. Not that gcc being under GPLv3 makes any difference whatsoever, as the iPhone would still be permitted regardless. Ian
Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
> Well at least that explains their total inactivity in the last year. Is Dale > the one still allowed to read the gcc-patches mailing list? No, that would be Stan just because he's not at Apple. It must be said also that Mike Stump accepted to review/discuss Darwin/ObjC patches that he was CCed on, but most people don't know that they need to do so. As a side note, Mike also wrote this last February: > The SC knows of the issue Still, after six months it would be nice to have a clearer idea of what will happen with respect to Darwin/ObjC, especially since the previous statement (which I suppose was "as clear as" Mike could do) was buried under an unrelated thread. Paolo
Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
Paolo Bonzini <[EMAIL PROTECTED]> writes: > Ah, actually I think I now see the OP's point. Apple is scared of the > GPLv3 because the iPhone might violate it, so they are not contributing > to anything that falls under the GPLv3. ... > 1) does it make sense to keep a maintainer category that is known to be > inactive? > > 2) who should then get maintainership of darwin? note that there are > some patches for darwin like this one: > http://article.gmane.org/gmane.comp.gcc.patches/172498 > > It's sad, but I think that there is need for the SC to take action on this. I personally don't think there is any need to remove them as maintainers until the FSF finally produces the GPLv3 version of the runtime library license. At that point Apple will be out of excuses, and will have to finally decide in or out on future gcc developmnt. It's worth noting that in a larger sense, Apple is simply not interested in contributing to gcc. If they were interested, they would contribute. They (for some version of "they") are using GPLv3 as a tactic to get out of the gcc game while blaming it on us. They have not raised any actual substantial issue with the GPLv3, which is not surprising, since the GPLv3 does not impose any additional requirements on them beyond GPLv2. However, the gcc community can't call them on that until the runtime library license is complete, as its absence is indeed a valid objection. Jack Howarth <[EMAIL PROTECTED]> writes: > However if GPLv3 is such a huge issue > at Apple, it does make one wonder if llvm will ever see a gcc front-end newer > than the current 4.2 one. The LLVM folks are writing a new frontend anyhow. In the future they presumably plan to stop using the gcc frontend. gcc's code is so tangled anyhow, it's not like using the gcc frontend somehow makes LLVM compile code the same way gcc does. Ian
Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
> > However if GPLv3 is such a huge issue > > at Apple, it does make one wonder if llvm will ever see a gcc front-end > > newer > > than the current 4.2 one. > > The LLVM folks are writing a new frontend anyhow. In the future they > presumably plan to stop using the gcc frontend. gcc's code is so > tangled anyhow, it's not like using the gcc frontend somehow makes > LLVM compile code the same way gcc does. I'm quite interested in porting llvm-gcc to gcc head, in order to get better Ada support. Apple isn't planning Ada support in their new compiler (clang) as far as I know :) Duncan. PS: I have no connection with Apple.
Runtime library license, was Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
Ian Lance Taylor wrote:
Paolo Bonzini <[EMAIL PROTECTED]> writes:
It's sad, but I think that there is need for the SC to take action on this.
I personally don't think there is any need to remove them as
maintainers until the FSF finally produces the GPLv3 version of the
runtime library license. At that point Apple will be out of excuses,
and will have to finally decide in or out on future gcc development.
I am probably not alone to be extremely interested in understanding more
clearly what is happening on the runtime library license side,
especially with relation to plugins.
The recent thread http://gcc.gnu.org/ml/gcc/2008-09/msg00292.html
"Defining a common plugin machinery" is particularly concerned with this
issue (of runtime library license). I'm guessing that since Diego
Novillo asked something, he was expecting/dreaming/knowing? about some
evolution on this.
Is it top secret information only available to some few members of the
Steering Committee, or is some information sharable on this list? Just
knowing that indeed a runtime library license will be finalized before
Christmas (ie in 2008) and that GPL-ed plugins will be somehow "blessed"
by the SC (or is it the FSF) will be a big relief.
Is something happening on runtime library license, or is there some
unexpected issue which affects existing branches experimenting plugins
(e.g. MELT)?
The only thing I know about runtime library license is the stuff I heard
and read at the june 2008 GCC summit, and I am guessing that a lot of
things happened since. IIRC, I remember having heard in june 2008 that
we have only months, not years, to wait (I did not understood exactly
for what, but it was runtime licence related).
In particular, if dlopen-ing GPL-ed (and even FSF copyright-ed) code is
still a taboo in GCC, I would be glad to be informed...
[I'm writing in some proposals, to get money to work on GCC, that
plugins are indeed appearing in GCC; I hope that I am not entirely wrong]
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Runtime library license, was Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes: > Is it top secret information only available to some few members of the > Steering Committee, or is some information sharable on this list? Just > knowing that indeed a runtime library license will be finalized before > Christmas (ie in 2008) and that GPL-ed plugins will be somehow > "blessed" by the SC (or is it the FSF) will be a big relief. I have no additional information. I just want to make the point that these issues involve lawyers, and they involve RMS, and it's not a major priority for any of them. It takes time. It's frustrating. But it is most likely not the case that secret negotiations are happening. It is far more likely that nothing is happening at all. There is a simple technique which anybody is free to use to make this happen much faster: make a large donation to the SFLC and/or the FSF, contingent on this issue being finished. In the absence of that, it will happen in the time that people have available to work on it. Ian
Mainline bootstrap failure on powerpc64-darwin, but looks generic
I'm just not having any luck bootstrapping this thing ... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37639
Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
On Wed, Sep 24, 2008 at 04:33:35PM +0200, Paolo Bonzini wrote: > > Well at least that explains their total inactivity in the last year. Is Dale > > the one still allowed to read the gcc-patches mailing list? > > No, that would be Stan just because he's not at Apple. > > It must be said also that Mike Stump accepted to review/discuss > Darwin/ObjC patches that he was CCed on, but most people don't know that > they need to do so. > > As a side note, Mike also wrote this last February: > > > The SC knows of the issue > > Still, after six months it would be nice to have a clearer idea of what > will happen with respect to Darwin/ObjC, especially since the previous > statement (which I suppose was "as clear as" Mike could do) was buried > under an unrelated thread. > > Paolo Do we know if Apple still intends to update the ObjC in FSF gcc to v2.0? Jack
Re: Runtime library license, was Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
On Wed, Sep 24, 2008 at 11:26 AM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes: > >> Is it top secret information only available to some few members of the >> Steering Committee, or is some information sharable on this list? Just >> knowing that indeed a runtime library license will be finalized before >> Christmas (ie in 2008) and that GPL-ed plugins will be somehow >> "blessed" by the SC (or is it the FSF) will be a big relief. > > I have no additional information. I just want to make the point that > these issues involve lawyers, and they involve RMS, and it's not a > major priority for any of them. It takes time. It's frustrating. > But it is most likely not the case that secret negotiations are > happening. It is far more likely that nothing is happening at all. > > There is a simple technique which anybody is free to use to make this > happen much faster: make a large donation to the SFLC and/or the FSF, > contingent on this issue being finished. In the absence of that, it > will happen in the time that people have available to work on it. How large is large?
Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
On Sep 24, 2008, at 8:51 AM, Jack Howarth wrote: The SC knows of the issue Still, after six months it would be nice to have a clearer idea of what will happen with respect to Darwin/ObjC, especially since the previous statement (which I suppose was "as clear as" Mike could do) was buried under an unrelated thread. Paolo Do we know if Apple still intends to update the ObjC in FSF gcc to v2.0? Jack We don't have any short-term plans to do so. However, all the code for ObjC 2.0 and even the new C Blocks feature is available in the llvm-gcc repository. One potential issue is that while Apple has a blanket copyright assignment with the FSF, I don't know whether code in the llvm-gcc repo is auto-assigned to the FSF. -Chris
Re: Apple, iPhone, and GPLv3 troubles
On Sep 24, 2008, at 7:06 AM, Ian Lance Taylor wrote: fix the problem. My understanding of Apple's current position is that they won't take any action until they see the final version of the gcc runtime license. Basically, what happened is that Apple created a Tivoized device called the iPhone, and Apple uses GCC (which is now under GPLv3) and Mac OS X on it. Unfortunately, the iPhone is incompatible with GPLv3, if you want more see the link I mentioned. Using gcc to compile your code does not impose any licensing requirements on that code. I'm not speaking for Apple here, and I am not a lawyer. However, the last draft of the runtime library exception clause (which is quite old by now) imposed licensing restrictions on the executables generated by GCC (due to linked runtime libraries) if you did certain things to the compiler. I'm personally very eager to see the final wording, because the draft I saw (again, which is old and has certainly changed) was extremely aggressive. -Chris
Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
On Sep 24, 2008, at 8:02 AM, Duncan Sands wrote: However if GPLv3 is such a huge issue at Apple, it does make one wonder if llvm will ever see a gcc front-end newer than the current 4.2 one. The LLVM folks are writing a new frontend anyhow. In the future they presumably plan to stop using the gcc frontend. gcc's code is so tangled anyhow, it's not like using the gcc frontend somehow makes LLVM compile code the same way gcc does. I'm quite interested in porting llvm-gcc to gcc head, in order to get better Ada support. As Duncan says here, Apple and the LLVM Project really are separable entities. As a developer on the LLVM Project, I'd love to see a new version of llvm-gcc based on ToT GCC. I'm not sure how technically feasible it is, but it would be even better for future versions of llvm-gcc to be based on the new GCC plugin model. -Chris
Re: Apple, iPhone, and GPLv3 troubles
On Sep 24, 2008, at 10:01 AM, Chris Lattner wrote: requirements on that code. I'm not speaking for Apple here, and I am not a lawyer. However, the last draft of the runtime library exception clause (which is quite old by now) I'm sorry, to be clear, I meant "the last draft *that I saw* (which is quite old..." -Chris
Re: Apple, iPhone, and GPLv3 troubles
On Wed, Sep 24, 2008 at 10:05:37AM -0700, Chris Lattner wrote: > > On Sep 24, 2008, at 10:01 AM, Chris Lattner wrote: > > >>requirements on that code. > > > >I'm not speaking for Apple here, and I am not a lawyer. However, > >the last draft of the runtime library exception clause (which is > >quite old by now) > > I'm sorry, to be clear, I meant "the last draft *that I saw* (which is > quite old..." While I'm not eager to continue this thread, the draft you saw was rejected by pretty much everyone (in particular, the SC pushed back hard) and has been replaced by much narrower language, so I hope that no one panics based on your message.
Re: Runtime library license, was Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
NightStrike <[EMAIL PROTECTED]> writes: >> There is a simple technique which anybody is free to use to make this >> happen much faster: make a large donation to the SFLC and/or the FSF, >> contingent on this issue being finished. In the absence of that, it >> will happen in the time that people have available to work on it. > > How large is large? More than you want to pay personally. Think: enough to hire another staff member to work on it. To be clear, I'm not saying it won't get done. It will get done. But it is in effect like any other volunteer job. Our position with regard to the people who need to do the work is like a gcc user's position with regard to us. Ian
Re: Apple, iPhone, and GPLv3 troubles
Chris Lattner <[EMAIL PROTECTED]> writes: > On Sep 24, 2008, at 7:06 AM, Ian Lance Taylor wrote: >> fix the problem. My understanding of Apple's current position is that >> they won't take any action until they see the final version of the gcc >> runtime license. > >>> Basically, what happened is that Apple created a Tivoized device >>> called the >>> iPhone, >>> and Apple uses GCC (which is now under GPLv3) and Mac OS X on it. >>> Unfortunately, the iPhone is incompatible with GPLv3, if you want >>> more see >>> the link I mentioned. >> >> Using gcc to compile your code does not impose any licensing >> requirements on that code. > > I'm not speaking for Apple here, and I am not a lawyer. However, the > last draft of the runtime library exception clause (which is quite old > by now) imposed licensing restrictions on the executables generated by > GCC (due to linked runtime libraries) if you did certain things to the > compiler. I'm personally very eager to see the final wording, because > the draft I saw (again, which is old and has certainly changed) was > extremely aggressive. I do not know what draft you saw, but I don't think I ever saw it, unless we disagree on the meaning of "extremely aggressive." In the general sense, you are most likely correct: if you modify gcc by adding GPL-incompatible software used to generate code, it is likely that you will not be granted any exception to the GPL when using the runtime library. In other words, if you 1) add an optimization pass to gcc using the (hypothetical) plugin architecture, and 2) that optimization pass is not licensed under a GPL-compatible license, and 3) you generate object code using that optimization pass, and 4) you link that generated object code with the gcc runtime library (e.g., libgcc or libstdc++-v3), then you will not be permitted to distribute the resulting executable except under the terms of the GPL. This does not of course affect LLVM, which is not under a GPL-incompatible license. This is intended to be a mechanism to use the runtime libraries as a hook to prevent people from distributing GPL-incompatible plugins for gcc. This message is not intended to describe the final version of the runtime library license, which does not exist. Nor does it represent the official position of the gcc steering committee, the FSF, the SFLC, or, for that matter, Google. This describes my personal understanding of the intent of the current drafting process. Ian
Re: Apple, iPhone, and GPLv3 troubles
Chris Lattner <[EMAIL PROTECTED]> writes: > > I'm not speaking for Apple here, and I am not a lawyer. However, the > > last draft of the runtime library exception clause (which is quite old > > by now) imposed licensing restrictions on the executables generated by > > GCC (due to linked runtime libraries) if you did certain things to the > > compiler. I'm personally very eager to see the final wording, because > > the draft I saw (again, which is old and has certainly changed) was > > extremely aggressive. On Wed, Sep 24, 2008 at 10:50:13AM -0700, Ian Lance Taylor wrote: > I do not know what draft you saw, but I don't think I ever saw it, > unless we disagree on the meaning of "extremely aggressive." There was a first version that had some problems, forbidding things that weren't intended to be forbidden and with muddy language making the scope of the GCC exception unclear. But this was never intentional.
Re: Apple, iPhone, and GPLv3 troubles
On Sep 24, 2008, at 10:50 AM, Ian Lance Taylor wrote: I'm not speaking for Apple here, and I am not a lawyer. However, the last draft of the runtime library exception clause (which is quite old by now) imposed licensing restrictions on the executables generated by GCC (due to linked runtime libraries) if you did certain things to the compiler. I'm personally very eager to see the final wording, because the draft I saw (again, which is old and has certainly changed) was extremely aggressive. I do not know what draft you saw, but I don't think I ever saw it, unless we disagree on the meaning of "extremely aggressive." In the general sense, you are most likely correct: if you modify gcc by adding GPL-incompatible software used to generate code, it is likely that you will not be granted any exception to the GPL when using the runtime library. In other words, if you 1) add an optimization pass to gcc using the (hypothetical) plugin architecture, and 2) that optimization pass is not licensed under a GPL-compatible license, and 3) you generate object code using that optimization pass, and 4) you link that generated object code with the gcc runtime library (e.g., libgcc or libstdc++-v3), then you will not be permitted to distribute the resulting executable except under the terms of the GPL. Again, speaking for myself as an individual: This was many months ago, and I did not retain a copy of the draft. In any case, it doesn't really matter because the draft probably has changed. However, the intent of pieces of the exception clause was pretty much what you said above. This does not of course affect LLVM, which is not under a GPL-incompatible license. Right. However, the wording I saw was much broader than just the plugin model. It was vague and poorly worded, and you could interpret it as saying that use of a non-GPL assembler or linker was also not allowed to build or link the libraries. My personal feeling on the matter is that it seems very strange to talk about *compiler plugins* in the license for *runtime libraries*. Considering that there are already widely available alternative libraries (e.g. the apache stdc++ library and many others) it seems potentially damaging to the GCC community to try to address the plugin issue this way. In any case, this thread should probably be killed, as we won't know until the FSF publishes the final proposed wording what the end result will be. I am (personally) looking forward to this, and I (personally) wish that the FSF was a lot more transparent on this issue, for the sake of the GCC community. -Chris
Re: Apple, iPhone, and GPLv3 troubles
On Wed, Sep 24, 2008 at 11:11:41AM -0700, Chris Lattner wrote: > Right. However, the wording I saw was much broader than just the > plugin model. It was vague and poorly worded, and you could interpret > it as saying that use of a non-GPL assembler or linker was also not > allowed to build or link the libraries. That's the version that was dumped, exactly for the reasons you state.
Re: Apple, iPhone, and GPLv3 troubles
On Wed, Sep 24, 2008 at 11:22 AM, Joe Buck <[EMAIL PROTECTED]> wrote: > On Wed, Sep 24, 2008 at 11:11:41AM -0700, Chris Lattner wrote: >> Right. However, the wording I saw was much broader than just the >> plugin model. It was vague and poorly worded, and you could interpret >> it as saying that use of a non-GPL assembler or linker was also not >> allowed to build or link the libraries. > > That's the version that was dumped, exactly for the reasons you state. > Excellent. I'm glad to hear that since I had also seen it and thought that it was unacceptable in general (speaking for myself). Anyhow, I hope to see all of this resolved at some point. -eric
Re: Runtime library license, was Re: Apple-employed maintainers (was Re: Apple, iPhone, and GPLv3 troubles)
Ian Lance Taylor wrote:
NightStrike <[EMAIL PROTECTED]> writes:
There is a simple technique which anybody is free to use to make this
happen much faster: make a large donation to the SFLC and/or the FSF,
contingent on this issue being finished. In the absence of that, it
will happen in the time that people have available to work on it.
How large is large?
More than you want to pay personally. Think: enough to hire another
staff member to work on it.
To be clear, I'm not saying it won't get done. It will get done. But
it is in effect like any other volunteer job. Our position with
regard to the people who need to do the work is like a gcc user's
position with regard to us.
I fully understand that position, but it triggers another question: what
company (or kind of companies) would want GCC plugins to happen really fast?
Is there any big coorporation, already contributing to GCC, which needs
plugin quickly? I cannot name any.
My feeling is that plugin will become progressively extremely useful to
*new* companies, which are not yet working within GCC. This mostly is
the case because in my perception plugins will open new use of GCC, like
illustrated by the "replacing sed & grep by gcc" papers from Mozilla
folks (Tarek et al.). My intuition is that plugins will mostly enhance
all the non-code-generation activities in GCC.
Big hardware companies (those traditionally investing in GCC, like
Intel, AMD, Apple, ...) probably do not need plugins (except if they
wanted to provide *proprietary* plugins, which I believe the next
runtime license will try to prohibit), they can and do contribute to GCC
inside.
Big software or services companies (IBM, Google) probably also don't
need plugins (except to enhance GCC with a plugin that they use only in
house and do not intend to distribute, but for that use an inhouse
patched GCC is enough).
So I cannot guess a company willing to invest big bucks on the runtime
license issue, but I am probably wrong (and not naive enough to believe
that companies will discuss their GCC related strategies & motivations
here, publicly, on this list).
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Apple, iPhone, and GPLv3 troubles
On Sep 24, 2008, at 11:22 AM, Joe Buck wrote: On Wed, Sep 24, 2008 at 11:11:41AM -0700, Chris Lattner wrote: Right. However, the wording I saw was much broader than just the plugin model. It was vague and poorly worded, and you could interpret it as saying that use of a non-GPL assembler or linker was also not allowed to build or link the libraries. That's the version that was dumped, exactly for the reasons you state. I look forward to seeing the updated version - someday. -Chris
Re: Apple, iPhone, and GPLv3 troubles
On Wed, Sep 24, 2008 at 4:06 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > Apple's dislike of GPLv3 is a problem for gcc, yes. Well, excuse me for being a-political, but I don't see this problem. The relationship between GCC and Apple has never been really good AFAIK, but that hasn't hampered either to be quite successful. And w.r.t. GCC development - I don't know where/how the money flows, but at least the publicly the contributions from Apple to the FSF GCC are pretty marginal. Gr. Steven
Re: Apple, iPhone, and GPLv3 troubles
Steven Bosscher wrote: > On Wed, Sep 24, 2008 at 4:06 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: >> Apple's dislike of GPLv3 is a problem for gcc, yes. > > Well, excuse me for being a-political, but I don't see this problem. > The relationship between GCC and Apple has never been really good > AFAIK, but that hasn't hampered either to be quite successful. I agree with you, but if you don't look at GCC as a whole -- but rather at the small intersection represented by FSF GCC on Darwin -- it *has* hampered it. Apple GCC is basically a fork nowadays, and it is often impossible to compile Leopard application using FSF GCC (in turn because of the lack of Objective-C 2.0 support). Sometimes I wonder why Darwin is still part of FSF GCC, just like it is not supported in binutils or gdb... I guess just for the sake of GCC developers that are working on a Mac. Even outside *-*-darwin*, what caused the development of two separate Objective-C runtimes, the one in FSF GCC being a big chainball for the removal of dead code from the compiler? Note that basically all Objective-C code in existence either does not care about the runtime, or has support for both runtimes; so it would not be a problem to deprecate libobjc if Apple contributed their own implementation. (There is now a third runtime, named Étoilé). Paolo ps: of course, there is no offense intended for poor Mike who's CCed in this thread.
Re: C/C++ FEs: Do we really need three char_type_nodes?
Joe Buck wrote: On Tue, Sep 23, 2008 at 05:51:23PM -0400, Jason Merrill wrote: Mark Mitchell wrote: Is that desirable? Type-based alias analysis should be able to take advantage of the difference between them; a "char **" and a "signed char **" cannot point at the same thing, for example. They can. In C++, a char* (or unsigned char*) can alias anything, and any signed/unsigned type can alias the other signage. Right, but a char** points to a char*, and a signed char** points to a signed char*. The aliasing exception for char pointers doesn't cover this case the way it does for the "one star" case. Oops, I was overlooking the second *. Jason
RE: Apple, iPhone, and GPLv3 troubles
BTW, one of the reason I posted this was that I wanted to privately talk about the politics behind this issue with someone internal to Apple, and forward some of that to RMS and the FSF. Can this be done or is the politics all under NDA? Because this issue isn't just limited to GCC, it is locking Apple out of an entire body of FOSS code. Yuhong bao > Date: Wed, 24 Sep 2008 21:14:42 +0200 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED]; [EMAIL PROTECTED]; gcc@gcc.gnu.org; [EMAIL PROTECTED] > Subject: Re: Apple, iPhone, and GPLv3 troubles > > Steven Bosscher wrote: >> On Wed, Sep 24, 2008 at 4:06 PM, Ian Lance Taylor wrote: >>> Apple's dislike of GPLv3 is a problem for gcc, yes. >> >> Well, excuse me for being a-political, but I don't see this problem. >> The relationship between GCC and Apple has never been really good >> AFAIK, but that hasn't hampered either to be quite successful. > > I agree with you, but if you don't look at GCC as a whole -- but rather > at the small intersection represented by FSF GCC on Darwin -- it *has* > hampered it. > > Apple GCC is basically a fork nowadays, and it is often impossible to > compile Leopard application using FSF GCC (in turn because of the lack > of Objective-C 2.0 support). Sometimes I wonder why Darwin is still > part of FSF GCC, just like it is not supported in binutils or gdb... I > guess just for the sake of GCC developers that are working on a Mac. > > Even outside *-*-darwin*, what caused the development of two separate > Objective-C runtimes, the one in FSF GCC being a big chainball for the > removal of dead code from the compiler? Note that basically all > Objective-C code in existence either does not care about the runtime, or > has support for both runtimes; so it would not be a problem to deprecate > libobjc if Apple contributed their own implementation. (There is now a > third runtime, named Étoilé). > > Paolo > > ps: of course, there is no offense intended for poor Mike who's CCed in > this thread. _
Re: char* problems
On Wed, Sep 24, 2008 at 2:47 AM, Lijuan Hai <[EMAIL PROTECTED]> wrote: > I have no gcc 4.1.2 at hand. but I just had a try with gcc-4.1.0 and > gcc-4.2.0 which compiled a simple testcase with no errors or warnings. > additionally, I had a try with some other compiler than gcc to compile > it. a warning issued. > I think it's possibly too strict of gcc raising a error on sch case. > any options that you added when compiling? Well lets put it this way, this is invalid code as char, signed char, and unsigned char are three distant types so the pointers to each of them are not compatible which means you need an explicit cast. The C++ compiler errors out by default, you can change the error to a warning with -fpermissive. While the C front-end warns by default, you can change the warning to an error with -pedantic-errors. Thanks, Andrew Pinski
Re: Apple, iPhone, and GPLv3 troubles
Yuhong Bao <[EMAIL PROTECTED]> writes: > BTW, one of the reason I posted this was that I wanted to privately > talk about the politics behind this issue with someone internal to > Apple, and forward some of that to RMS and the FSF. Can this be done > or is the politics all under NDA? Well, good luck. The people you need to talk to, with respect to Apple and GPLv3, are not reading this mailing list. We've already talked to some of them, and the situation as I understand it is what I already outlined, with the obvious proviso that I do not work at Apple. A couple of people from Apple have now commented on this thread; go ahead and mail them directly. Ian
Re: Apple, iPhone, and GPLv3 troubles
Chris Lattner <[EMAIL PROTECTED]> writes: > My personal feeling on the matter is that it seems very strange to > talk about *compiler plugins* in the license for *runtime libraries*. > Considering that there are already widely available alternative > libraries (e.g. the apache stdc++ library and many others) it seems > potentially damaging to the GCC community to try to address the plugin > issue this way. Here's the problem: the FSF doesn't really want to permit plugins. Many members of the gcc community, including myself, think they are very important. The FSF doesn't want plugins because they are concerned that people will start distributing proprietary plugins to gcc. I personally think this is a fear from twenty years ago which shows a lack of understanding of today's compiler market, but, that said, the FSF wants to cover themselves for the future as well. So, how do we permit plugins while prohibiting proprietary plugins, and how do we do it while staying within the bounds of copyright law which is the basis of the GPL? It's not an easy problem to solve. Using the runtime library license to solve it is a nice little bit of legal jujitsu. Presumably we could go ahead and use a simple runtime library license, similar to the existing one, which doesn't address the plugin issue. But we still want plugins, and then how do we get them? Separating the problems doesn't make them easier to solve. You are clearly right that the runtime license is potentially damaging to the GCC community. However, it's not like the people working on this are stupid, and it's not like they are going to force it on everybody without accepting comments. So I think it's premature to worry overly much about this. The FSF has not yet made a major licensing mistake. Ian
Re: Apple, iPhone, and GPLv3 troubles
On Sep 24, 2008, at 12:57 PM, Ian Lance Taylor wrote: Chris Lattner <[EMAIL PROTECTED]> writes: My personal feeling on the matter is that it seems very strange to talk about *compiler plugins* in the license for *runtime libraries*. Considering that there are already widely available alternative libraries (e.g. the apache stdc++ library and many others) it seems potentially damaging to the GCC community to try to address the plugin issue this way. Here's the problem: the FSF doesn't really want to permit plugins. So, how do we permit plugins while prohibiting proprietary plugins, and how do we do it while staying within the bounds of copyright law which is the basis of the GPL? Does the obvious answer work?: add it to the license that covers the code in question. Specifically, I think that it would be much more reasonable to add "plugin" wording to the license that covers the GCC compiler code itself. This means that you couldn't use *GCC* if you did something the FSF found objectionable, closing an easy work-around. -Chris
gcc-4.2-20080924 is now available
Snapshot gcc-4.2-20080924 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080924/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 140646 You'll find: gcc-4.2-20080924.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20080924.tar.bz2 C front end and core compiler gcc-ada-4.2-20080924.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20080924.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20080924.tar.bz2 C++ front end and runtime gcc-java-4.2-20080924.tar.bz2 Java front end and runtime gcc-objc-4.2-20080924.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20080924.tar.bz2The GCC testsuite Diffs from 4.2-20080917 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Apple, iPhone, and GPLv3 troubles
That is why I'm CCing someone from Apple. -- From: "Ian Lance Taylor" <[EMAIL PROTECTED]> Sent: Wednesday, September 24, 2008 12:47 PM To: "Yuhong Bao" <[EMAIL PROTECTED]> Cc: "Paolo Bonzini" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; Subject: Re: Apple, iPhone, and GPLv3 troubles Yuhong Bao <[EMAIL PROTECTED]> writes: BTW, one of the reason I posted this was that I wanted to privately talk about the politics behind this issue with someone internal to Apple, and forward some of that to RMS and the FSF. Can this be done or is the politics all under NDA? Well, good luck. The people you need to talk to, with respect to Apple and GPLv3, are not reading this mailing list. We've already talked to some of them, and the situation as I understand it is what I already outlined, with the obvious proviso that I do not work at Apple. A couple of people from Apple have now commented on this thread; go ahead and mail them directly. Ian
Re: Apple, iPhone, and GPLv3 troubles
Chris Lattner <[EMAIL PROTECTED]> writes: > On Sep 24, 2008, at 12:57 PM, Ian Lance Taylor wrote: > >> Chris Lattner <[EMAIL PROTECTED]> writes: >> >>> My personal feeling on the matter is that it seems very strange to >>> talk about *compiler plugins* in the license for *runtime libraries*. >>> Considering that there are already widely available alternative >>> libraries (e.g. the apache stdc++ library and many others) it seems >>> potentially damaging to the GCC community to try to address the >>> plugin >>> issue this way. >> >> Here's the problem: the FSF doesn't really want to permit plugins. > >> So, how do we permit plugins while prohibiting proprietary plugins, >> and how do we do it while staying within the bounds of copyright law >> which is the basis of the GPL? > > Does the obvious answer work?: add it to the license that covers the > code in question. Specifically, I think that it would be much more > reasonable to add "plugin" wording to the license that covers the GCC > compiler code itself. This means that you couldn't use *GCC* if you > did something the FSF found objectionable, closing an easy > work-around. This doesn't work, because it breaks out of the basic framework of copyright law. Nobody signs anything or accepts any terms in order to use gcc. The FSF wants to stop people from distributing proprietary binary plugins to gcc. The copyright on gcc does not apply to those plugins. If gcc got a new, non-GPL, license which attempted to control those plugins, that license would only be binding to the extent that people explicitly accepted it. There is no shrinkwrap EULA on gcc. Or, perhaps I should say, we could perhaps make that work, but we would give up other desirable properties of the current regime. Ian
Re: Adding to G++: Adding a warning on throwing unspecified exceptions.
Simon Hill wrote: > Brendon Costa said: >> The author of the template class or container can't know >> what types of exceptions will be thrown from them, so you must define >> them as being able to throw all exceptions (which is how they are >> currently). > Ouch, you have a point. But couldn't you put this round the other way. > Place the onus on the user of the template to comply with the > exception guarantees inside the template. Unfortunately that would > likely cause problems with some existing code. > > ... > > In other words, would you gain more from a tight exception > specification than you'd lose by not being able to do this? > You as an author of a new template class "could" define it the other way. The issue here is that doing so restricts usage of the generic component. In specific cases this may be desirable, but not for generic components like STL containers or those in boost. For generic components you want to make them as useful as possible. Even if at the time of writing the container you do not foresee that throwing any type of exception is a good idea, users may come up with some way of using it that you just never thought about. I.e. I think the general philosophy is to define only what restrictions are necessary to implement the template, not necessarily what we think constitute good uses of the template at the time we created it. Brendon.
