Re: memcpy(p,p,len)
Just a quick comment than Jan-Benedict's opinion is widely shared by the specification and by the Linux glibc manpage: DESCRIPTION The memcpy() function copies n bytes from memory area src to memory area dest. The memory areas should not overlap. Use memmove(3) if the memory areas do overlap. It doesn't matter if it sometimes works. Sometimes works programs are sometimes doesn't work programs. :-) Cheers, mark On 04/30/2010 10:25 AM, Jan-Benedict Glaw wrote: On Fri, 2010-04-30 16:14:36 +0200, Joakim Tjernlundjoakim.tjernl...@transmode.se wrote: Jan-Benedict Glawjbg...@lug-owl.de wrote on 2010/04/30 16:10:42: On Fri, 2010-04-30 16:08:15 +0200, Joakim Tjernlund joakim.tjernl...@transmode.se wrote: Is memcpy supposed to work when the src and dest are the same: memcpy(p, p, 100); It may work, but you cannot rely on it. Use memmove() alternatively. My view too, but gcc 3.4.6 on gcc does this: [...] Surely, it may/will work here and there. But it's not portable :) And I won't rely on a it worked once fact. MfG, JBG
Re: Why not contribute? (to GCC)
On 04/25/2010 11:27 PM, Dave Korn wrote: On 26/04/2010 01:12, Mark Mielke wrote: The real reason for FSF copyright assignment is control. The FSF wants to control GCC. Yes. Specifically, they want to be able to enforce the GPL. Since only the copyright holder can license code to anyone, whether under GPL or whatever terms, FSF has to hold the copyright, or it can't sue anyone who breaches the GPL, and therefore cannot enforce it. If the software was truly free - and not limited use - there would be no need to enforce it. It would be free. mode. I don't see how this benefits me in any way. If I'm giving software that I write to the community for free, why do I care what they will do with it? If I control how they can use it - it's not free. It's limited use. You're only looking at it from one side, that of an author. The benefits of the GPL are primarily to users. Since all us authors are also users of software, we should weigh up the inconveniences against the benefits. This presumes that the benefits of truly free software are not sufficient on their own to result in benefits for the users. There are many non-GPL free software projects, that continue to be distributed for free, without the heavy handed enforcement defined by the GPL. The GPL is just one model for free software. It is not the only model, nor it is the most free model. There is value for me, as a user, in the existence of free software that can't be restricted by proprietary acts of enclosure. The GPL is unashamedly a political strategy with a goal that can be seen to benefit all, even without your needing to agree with the political stance: that goal is to create a commons, and to make it impossible for there ever to be a tragedy of that commons. Whether you agree about the value (social or financial) or likelihood of success of the exercise or not, you still benefit from that commons, under pretty much any philosophical or political stance except for the most extreme everything is a zero-sum game and therefore anything that benefits anyone except me is a harm to me viewpoints. Or so I think, anyway. I think that other licenses exist which are both more free (less limited use), and would provide the same sorts of value in creating a commons. I think the creation of a commons should be about practical merit, and not some weird copyright protection that acts like a virus in that it infiltrates every derived software of the original software. I think people should do the right thing because it makes sense, not because the FSF crafted a clever way to lock people in to a certain model and never escape from it. So, why should you care what others will do with it? Enlightened self-interest. You and others both benefit from the common wealth of free software, therefore both you and others should, in theory, not want anyone to try and hoard those benefits to themselves, because that's how tragedies of commons arise. This is what can happen with the proprietarisation of open source software, the GPL is a way to avoid that from happening by caring about what others do with it, hence you should care what others do with it. You release your software to the world because you hope people will benefit from it, for the same reason you should continue to care what happens to it afterward. I have no fear of hoarding, because I believe that the merits of free software extend beyond a legal requirement to honour a copyright license. I believe companies generally discover that it is cheaper to contribute back to the project than to maintain patches off stream for extended periods of time. I believe that the users have power in requesting that the companies provide the software under an open source or free software license. I believe that free software has a significant place in this world which is compelling and self evident even to greedy self-interests. And if somebody doesn't get it, and hoards their own copy? I don't care. I as a user, can choose to not buy their solution. I as a user, can choose to contribute to an alternative to their solution. So what if somebody profits from my work? Companies such as RedHat profit from GPL work today. The copyright assignment part only goes so far in terms of protection. Personally, I have no problem with companies profiting from work which I have chosen to give away for free. Referring to the people and employees who have gone through the copyright assigment and employer disclaimers in the past and saying (they didn't have a problem signing) isn't evidence that the process is practical, efficient, or acceptable. These people probably just felt they had no other choice. If given the option of NOT doing this process, I'm sure most of them would happily have chosen option B. (Heh. Making arbitrary claims about how many people you suppose or not would make a certain choice or not and what their motives
Re: Why not contribute? (to GCC)
On 04/25/2010 11:44 PM, Dave Korn wrote: On 26/04/2010 04:30, Richard Kenner wrote: Yes. Specifically, they want to be able to enforce the GPL. Since only the copyright holder can license code to anyone, whether under GPL or whatever terms, FSF has to hold the copyright, or it can't sue anyone who breaches the GPL, and therefore cannot enforce it. Unless I'm missing something, that argues that the FSF must have copyright to SOME of the code. I don't see how having copyright for all of the code would be needed to do that. Well, if the FSF don't own all the code, they can only license the bits they do own. That would leave the rest of it vulnerable to predation, at least. ... they can only license the bits they do own isn't quite right. The can only license the bits they have permission to license. Under the GPL, anybody with a legally obtained copy can re-license the software the same version of the GPL or a later version of the GPL. Perhaps you mean they can only sue the bits they do own - but even that sounds suspect. If I have the rights to re-license software, and I re-license the software, why do I not have permission to enforce these rights? It doesn't make sense to me. But, I'm willing to assume the FSF lawyers know something I don't about copyright law, probably something about how only the actual owner (either due to being the original author or due to implicit copyright assignment to an employer or due to explicit copyright assignment to a third party such as the FSF?) can raise the law suit. If so, then yes, it would seem to, unfortunately, mean that you would need to get the author of the code that you want to sue about involved in the process. Personally, this whole issue is problematic to me. I really can't see why I would ever sue somebody for using software that I had declared free. It wouldn't be worth my time and I have trouble understanding how I could demonstrate personal loss making the law suit worth persuing in the first place. Perhaps I do not run an organization such as the FSF or own a company that makes money off dual-licensing GPL/Commercial, so I don't have the same perspective as they do... Cheers, mark
Re: Why not contribute? (to GCC)
On 04/26/2010 12:31 AM, Ian Lance Taylor wrote: Mark Mielkem...@mark.mielke.cc writes: Wouldn't contributing a patch to be read by the person who will be solving the problem, but without transferring of rights, introduce risk or liability for the FSF and GCC? I thought clean room implementation implies not seeing how somebody else did it first, as the clean part is tainted after somebody examines the patch? Clean room implementation techniques are not required to avoid copyright violations. Copyright only covers the expression of an idea; it does not cover the idea itself. Expressing the same idea in different code is not a copyright violation. Even independent identical expressions are not copyright violations if they are truly independent. And if there is only one possible way to express an idea, then copyright does not apply at all, as there is no creative aspect to the work. They aren't truly independent if you use the patch as a model to work from. Demonstrating to a judge that your work is unique might be a lot more difficult if you confess to reading the original before writing the new. What are clean room implementations for if not for avoiding copyright violation? At my company, we took things seriously to the point of dividing the GPL designers from the non-GPL designers to prevent code fragments from being leaked to one side or the other, even if just a faint memory that ends up resulting in code that looks just about exactly like the original, even if the author cannot identify what the original was. Cheers, mark
Re: Why not contribute? (to GCC)
On 04/26/2010 03:23 PM, Ian Lance Taylor wrote: Chris Lattnerclatt...@apple.com writes w.r.t. hoarding, I'll point out that (in the context of GCC) being able to enforce copyright is pretty useless IMO. While you can force someone to release their code, the GPL doesn't force them to assign the copyright to the FSF. In practice this means that you can force someone to release their GCC changes, but you can't merge them back to mainline GCC. In a warped way you could argue that the FSF using the GPL encourages their software to fork :-) Again, just for the record. History shows that this is not entirely useless. People at NeXT wrote the Objective C frontend to GCC. They did not intend to release the source code. The FSF objected. In the end, NeXT wound up contributing the code, and that is why GCC has an Objective C frontend. In other words, the whole process worked as the GPL intended. This presumes that NeXT would not have discovered the value of free software and done the right thing eventually anyways. I think anybody who truly believes in free software should believe in it for practical reasons. It's not just a religion - it's the right way to do business. Business can understand dollars, and free software can be demonstrated to provide value in terms of $$$. I think anybody who truly believes in the *merit* of free software, should be approaching companies who do not understand the merit with a business plan, not a class action law suit. Of course, if you don't believe in the *merit* of free software, and just think it's something cool to screw around with and force ideas down other people's throats -- Feel free to pursue the class action law suit approach, or consolidate ownership with the FSF and make it a straight forward law suit instead. Cheers, mark P.S. Objective C in particular has a sour taste in my mouth, as it seems to be a key component to Apple's vendor lock in strategy. If you can't lock people in through closed source - just choose a barely used open source project extension to base the entire front end of your software on and cross your fingers the rest of the world won't bother to catch up any time soon because it is simply too much effort.
Re: Why not contribute? (to GCC)
On 04/26/2010 11:11 AM, Alfred M. Szmidt wrote: If I have the rights to re-license software, and I re-license the software, why do I not have permission to enforce these rights? Because you have the permission to re-DISTRIBUTE (not re-LICENSE) the software and nothing else. In case of GCC, you have the explicit permission to relicense the work under a later version of the GPL. In the case of the GNU Lesser GPL, you have explicit permission to relicense the work under the GPL. So depending on the license, you might have permission to relicense the work. I think the ability to re-license in the sense of changing the license to a different license (as allowed) is a significant freedom offered by the GPL. It's a significant enough freedom that Linus chose to deny it for Linux as he apparently felt it provided the wrong sort of freedom, at least at the time he made that call. However, that isn't only/quite what I meant. My understanding of copyright law is that it *only* protects distribution rights of the works. For example, as long as I use the software internally within a single legal entity (company, house hold, or whatever is acceptable to the courts), I do not need to abide by *any* of the rules listed in the license, as I am not re-distributing the works. Most licenses, specifically including the GPL, specify rules that define what requirements I must meet before I am allowed to re-distribute the works. If re-distribute these works according to requirements, and then somebody down stream from me obtains a copy through me and then violates their licensing agreement in such a that I can demonstrate loss to a judge. I think I can sue. Or, rather, I don't see why I wouldn't be able to sue. I am required to include the license in the copy I distribute. They accepted the license as I provided. They violated the license. I can demonstrate losses as a result. How is this not a valid law suit? Why do I have to own the software to have a case? I think I just have to prove that a violation exists that I was the victim which resulted in a direct loss to me. I don't know where this own requirement comes from. But then, as I said in the thread two back that both of you are responding to - I am not a lawyer, and maybe the FSF knows something I do not. I think I've seen cases where users of software have leaned on companies to produce software under threat of a law suit, without necessarily involving each and every owner of the software. The WRT54G situation leaps right up to the top for me. I think the must legally own the works to be listed as a victim with losses in a law suit is not a true requirement. I think it might be convenient and might improve the chance of success - but I don't think that one requires access and commitment from the owners in order to create a law suit. As somebody else pointed out, the freedoms of the GPL are designed for the users. The people who are the most likely to be the victims are the users. The authors gave the software away for free, so attempting to demonstrate losses on something you give away for free is almost laughable (I'm sure many here would not laugh). It is the *users* who should be able to create the law suit, because it is the *users* who are impacted, and it is the *users* who can put a $$$ figure on their losses. In the Objective C case, users can claim that without the Objective C code being contributed back, it would take X million man hours @ $N/hour to re-create the code for use in future projects. This is a loss which can be accurately demonstrated. Sue NeXT for X*N+penalties. They have the option of paying out the full amount, funding the free software community to create their own (hopefully better) Objective C implementation, settling for a smaller amount (if agreeable to the users), or releasing their software. So again, I think copyright assignment is a matter of convenience and optimization - and not a legal requirement. But then, what do I really know... Cheers, mark
Re: Why not contribute? (to GCC)
On 04/26/2010 07:41 AM, Paolo Bonzini wrote: On 04/26/2010 11:23 AM, Mark Mielke wrote: Personally, this whole issue is problematic to me. I really can't see why I would ever sue somebody for using software that I had declared free. Because (a derivative of) it is being made nonfree? How does this hurt me? Instead of being concerned how people might try to exploit my code, why shouldn't I be spending effort making sure that the best solution for all parties, including greedy corporations, is to work with me, to make sure the code is kept in a small number of branches all available in the free and open source community? Why can't I demonstrate the merits of free software in such a way that even the most stubborn of CEOs will understand what I am offering to them? It wouldn't be worth my time and I have trouble understanding how I could demonstrate personal loss making the law suit worth persuing in the first place. Perhaps because you know the code better than anyone else, so you could provide paid support on that derivative as well. This is true whether the code is GPL or truly free. Or maybe because you have to. There was a case of a free software project (JMRI) being sued for patent infringement by a proprietary software company. It turned out that the proprietary software included source code from the free software project without attribution (copyleft was not even necessary, as the project was under the Artistic License!). In this case, the possibility to counter-sue saved the free software programmer from having to pay millions of dollars. I think this might be an over simplification. There were many statements in this history (new to me - just read it all - good read) that demonstrate that the patents were incorrectly granted. The copyright issue was involved, and the defense of free / open source copyrights was involved, but it looks pretty clear to me that JMRI wanted to shut down *all* violations. They wanted the incorrectly granted patents dropped, and they wanted their copyrights held intact. Was the latter required for the former victory, or was that just how things played out? I'll also note that even if it was required, it was the Artistic License, and it was demonstrated as being valid in a court of law. So, the GPL was not really part of this equation, and therefore not really part of this discussion, as off topic as it has gone. From my perspective, licenses like the Artistic License, the Apache license, or the BSD license, are great choices for free software projects. I see your point that the possibility to counter-sue is valid, but I think the scope is the scenario provided is limited to the scope of ensuring that the copyright is valid at all, rather than any additional restrictions that the GPL defines. I think, though, that this is somewhat self-evident, and that the case really shows how a clever lawyer can confuse judges into providing poor judgements. This will always be a risk, and copyright is not the ultimate defense against this risk. It was an option in the case you listed, but I think there were other options. It's unfortunate that persuing options in court can cost large amount of money, but that's the society we live in. The best direction to take from the above case is to attack the problem at the source. 1) Patents, at least under the current system, are evil, and provide a lot of risk for what is becoming a questionable amount of value. 2) The courts need a better way to figure out when somebody is lying in their court room. As demonstrated, there exists adequate laws to protect copyrights. No changes required on this front, at least for this scenario. Cheers, mark
Re: Why not contribute? (to GCC)
Copying David Daney's response to contrast against it: GCC is a mature piece of software that works really well and it is in a programming domain which is not as well understood and for people such as myself, I would be intimidated from the start, to delve in and expect any contributions I make to be valuable enough to bother the existing machine with. :-) But yes, if I overcame that intimidation, I'm sure David Daney's comments would describe the *next* barrier to overcome... Cheers, mark On 04/23/2010 03:33 PM, David Daney wrote: On 04/23/2010 11:39 AM, Manuel López-Ibáñez wrote: This seems to be the question running around the blogosphere for several projects. And I would like to ask all people that read this list but hardly say or do anything. What reasons keep you from contributing to GCC? I am going to answer why I think it is, even though I like to think that I do do something. GCC has high standards, so anybody attempting to make a contribution for the first time will likely be requested to go through several revisions of a patch before it can be accepted. After having spent considerable effort developing a patch, there can be a sense that the merit of a patch is somehow related to the amount of effort expended creating it. Some people don't have a personality well suited to accepting criticism of something into which they have put a lot of effort. The result is that in a small number of cases, people Bad Mouth GCC saying things like: The GCC maintainers are a clique of elitist idiots that refuse to accept good work from outsiders. Personally I don't agree with such a view, and I don't think there is much that can be done about it. There will always be Vocal Discontents, and trying to accommodate all of them would surly be determental to GCC. I think that some potential contributors are discouraged from contributing because they have been frightened away (by the Vocal Discontents mentioned above) before they can get started. David Daney
Re: Why not contribute? (to GCC)
On 04/23/2010 06:18 PM, Alfred M. Szmidt wrote: My personal opinion is that this legal reason is a *huge* bottleneck against external contributions. In particular, because you need to deal with it *before* submitting any patch, which, given the complexity (4MLOC) and growth rate (+30% in two years) of GCC, means in practice that people won't even start looking seriously inside GCC before getting that legal paper. Simply not true, you can submit patches without the legal leg work done. The patch cannot be commited to the tree though. And the time it takes to do this is less than it took me to read your message... I don't follow this comment... Wouldn't contributing a patch to be read by the person who will be solving the problem, but without transferring of rights, introduce risk or liability for the FSF and GCC? I thought clean room implementation implies not seeing how somebody else did it first, as the clean part is tainted after somebody examines the patch? Cheers, mark
Re: Why not contribute? (to GCC)
On 04/23/2010 08:37 PM, Basile Starynkevitch wrote: However, I would believe that most GCC contributors do not actively check their patch against the US patent system (because I perceive the US patent system to be very ill w.r.t. software). I confess I don't do that - it would be a full time boring job. At some companies, the lawyers specifically request that employees do NOT check for violation of patents or research any patents before writing code, as this process actually increases liability. It's similar to the clean room implementation model. If I look, then my ability to say I wrote this myself without any input is tainted. If I just write it myself without researching what others have done, then I can at least claim I never copied any ideas, and although I might still be found in violation of a patent, this can be addressed if and when it is found (either pay license/royalty fees or re-write the code to NOT use the now-known-to-be-patented ideas). Just thought that this opposite approach might be interesting to readers... :-) Cheers, mark
Re: Why not contribute? (to GCC)
On 04/23/2010 08:47 PM, Ian Lance Taylor wrote: Basile Starynkevitchbas...@starynkevitch.net writes: I also never understood what would happen if I had a brain illness to the point of submitting illegal patches (I have no idea if such things could exist; I am supposing today that if I wrote every character of every patch I am submitting to GCC they cannot be illegal.), The liability for the action would land on you rather than on the FSF. That is what matters for the future of the gcc project. ... There is no unlimited liability in the copyright assignment, either in words or in action. In the first quote The liability... you agree that there is liability. In the second you say no unlimited liability. So how much liability is required for somebody to accept in order to be allowed to contribute to GCC? Cheers, mark
Re: Why not contribute? (to GCC)
On 04/25/2010 11:20 AM, H.J. Lu wrote: On Sun, Apr 25, 2010 at 8:04 AM, Chris Lattnerclatt...@apple.com wrote: On Apr 25, 2010, at 7:59 AM, Manuel López-Ibáñez wrote: So, is the copyright disclaimer implicit in the patch submission? Who defines the conditions? That web page is everything that there is. I am aware that this is not as legally air-tight as the FSF disclaimer, but empirically many companies seem to have no problem with it. Can't resist. So in theory, someone can sue LLVM and win. If it is the case, I may not want to use LLVM as my system compiler. Considering that Linux, as the system kernel for many of us, is in a similar position, I don't see why the compiler, which isn't even a necessary part of a running system, would need to be more strict... In any case, the FSF disclaimer is paper work. It may help in some theoretical situation - or maybe it will be called invalid at the time it is presented. The question is whether the added paper work is really providing protection, or is it just slowing contributions? I don't have the answer to that - I only see that LLVM and many other projects under various free / open source licenses are proceeding just fine without such paper work, so on the surface, it does seem like an overall loss for GCC. One day might it prove its value? Who knows... Cheers, mark
Re: Why not contribute? (to GCC)
On 04/25/2010 05:49 PM, Richard Kenner wrote: So how much liability is required for somebody to accept in order to be allowed to contribute to GCC? This was answered already. It's the same for EVERY software project (not unique to GCC): if I steal somebody's copyrighted material and contribute it to a software project, I am liable for the FULL EXTENT of damages that my action caused. This is true whether I sign an assignment document or not. Yep - but that's my point. Full extent without any number listed is effectively unlimited liability. I saw people trying to suggest unlimited = infinity and that it will not be infinity, therefore it is not unlimited - but this just sounds like a wording game. One poster tried to argue that it was limited by describing that it was only 3 times some unspecified amount. But they missed that unspecified is unlimited. 3 times unspecified = 3 times unlimited = unlimited. The fact is, it is unlimited liability because no limit has been set. Whether this is unique to copyright assignment vs the more common shared ownership model? It's a good point that in either case, the liability may exist. This is where it becomes a bit complicated to me. As a for example, I could see somebody suing the FSF because it is a funded organization that can be easily listed as the defendant, whereas an open source project with hundreds of committers each with individual assignments for the parts they contributed, would be very difficult to list as the defendant, so they would have to target the people involved with the specific patch - or me. I couldn't see somebody suing me (my bank account hovers pretty low most of the time). Companies are not going to sue nobodies such as myself because there is no money in it. So, in practice, is there a difference or not? I think there is. With the assignment comes responsibility - except the FSF is explicitly requiring unlimited liability indemnity from the author, so they are accepting responsibility for the value, but not accepting responsibility for the risk. I can see why the FSF would want this - but I cannot see why I would want this. What's in it for me? Honestly, this discussion has resurrected my concerns about the FSF in general. And since I don't really want to argue about this here, I think I'll cut it off by just repeating that there are a lot of GPL / BSD / etc. projects out there that don't seem to have the problems that are being predicted. The only one I see of any value is the ability to change the license in the future, without my explicit consent. Honestly, I'm a bit concerned about having my code be distributed under a different license without my explicit consent, especially as my definition of free does not match the definition of free provided by the FSF. Cheers, mark
Re: Why not contribute? (to GCC)
On 04/25/2010 06:27 PM, Richard Kenner wrote: I couldn't see somebody suing me (my bank account hovers pretty low most of the time). Companies are not going to sue nobodies such as myself because there is no money in it. So, in practice, is there a difference or not? No, because then the FSF wouldn't sue you EITHER! There's NO DIFFERENCE in theory or in practice as to your liability whether there's an assignment or not and whether it's GCC or some other project. Obviously there is a difference, otherwise FSF wouldn't be requesting copyright assignment. The difference is that the FSF owns the entire project. Does this affect liability in theory or in practice? You say no. I say it might. Consolidated ownership means an easy target for a greedy company and a lazy judge (neither of which are in poor abundance). Under such a model, this easy target, if successfully sued and if damages are awarded, would pull up the copyright assignment agreement and hold me liable for the amount. Distributed ownership provides a difficult target and a less likely candidate for either a law suit in the first place, or a high $$$ amount once they figure out that they can only really sue me (and not a well funded organization). The ultimate in free, for me, is if every single person in the world contributed at least one line of code to the project, and retains ownership to their piece. Each person is then liable to each other person, and a true community owned project exists. Consolidated ownership can't do this. The real reason for FSF copyright assignment is control. The FSF wants to control GCC. This presents a chore for potential contributors with very little value (if any) in return for their efforts. The published explanation (why-assign.html) states clearly that the FSF believes it is easier to defend the software and all derived software as being free (as defined by the FSF) using a consolidated ownership mode. I don't see how this benefits me in any way. If I'm giving software that I write to the community for free, why do I care what they will do with it? If I control how they can use it - it's not free. It's limited use. In some ways, I wish a group did fork GCC under GPL and drop the copyright assignment requirement. In other ways, this entire issue is just so minor to me that it isn't worth going beyond this thread. GCC works, but so do other compilers (Intel CC, LLVM, ...). GCC is distributed under the GPL, so if the FSF ever becomes a real problem (as opposed to merely having a political agenda), it can be forked at this later time. All in all, pretty minor. GCC wants FSF copyright assignment and employer disclaimers? GCC will not have as many contributors. Your choice. There are plenty of projects that we (lurkers / non contributors) can contribute to other projects that are not as mature and require more attention, or even other compilers (LLVM?). Referring to the people and employees who have gone through the copyright assigment and employer disclaimers in the past and saying (they didn't have a problem signing) isn't evidence that the process is practical, efficient, or acceptable. These people probably just felt they had no other choice. If given the option of NOT doing this process, I'm sure most of them would happily have chosen option B. Cheers, mark
Re: trivial trailing whitespace issue
On 11/26/2009 08:18 AM, Michael Matz wrote: How, for goodness sake, can pure trailing whitespace changes, which by necessity you can't even _see_ in an editor (except if you activate modes that explicitely show them e.g. in different color) clean up code? Have you looked at the patch or fallout from it? If not, why do you speak in favor of it? I'm an outside observer with professional ties to SCM. This issue is similar in scope to TAB vs SPACE for indenting. Whether you can see it or not is not indicative of whether it has downstream effects or not. Generally, whitespace on the end of lines is bad, and cleanup eventually becomes necessary. It is bad because people will accidentally change lines without realizing them, and these changed lines show up in patches and annotations. This goes both ways - a lot of people browse code in vi, and accidentally add space to the end of lines they don't even intend to change. Or, maybe their editor automatically strips whitespace at end of line when they re-indent. Who knows? Same happens with TAB changed to SPACE or back and forth. Once these start to accumulate - they create downstream consequences that multiply. You can't see it, but every program that the file passes through *does* see them. Is cleanup in bulk the right approach? You either clean up over time or you do it in bulk. In my own projects, some of the designers I worked with had horrible habits in this regard. Every second line would have whitespace on the end. The longer it is left, the worse the effect. As software architect for our project, I notified the team I was doing a cleanup, and did it in bulk. Due to the notification, everything went smooth. It sounds like the idea should have been proposed and accepted. Everybody would have been ready for it, and nobody would be upset. Oh well. It's been entertaining. gcc@gcc.gnu.org is normally pretty dull to read... :-) Cheers, mark -- Mark Mielkem...@mielke.cc
Re: GPL (probably a FAQ)
On 07/23/2009 11:28 PM, graham_k wrote: Can someone tell me definitively - if I use a ten line GPLed function, say quicksort, in 500,000 lines of code which I write myself, do I need to GPL all of my source code and make the ode free for all? If you want a definitive answer you should contact a lawyer. What makes you think 10 lines would be exempt? Is there some part of the GPL that makes you think this? Realistically - the GPL would have some sort of limits that the copyright owner would have difficulty enforcing. For example, a copyright license is not the same as a patent or trademark and the chances that I write 10 lines the exact same as 10 of your lines, for a well known algorithm, are actually pretty high. If you GPL'ed your lines, and I never looked at your lines - the GPL cannot stop me from using my 10 lines even if they exactly match yours. However, it would raise questions, and if you sued me, I would probably have to show evidence that I had never seen your lines before. This is why it's bad to even LOOK at GPL code. Above, it hints that you have looked. If you have looked - how can you truly say that the lines you reproduce from your head are not a derivation? Sure you could change the variables around and move some of the blocks around to achieve the same effect while making it look different - but in truth, you have derived their source, and if you do not put the GPL on your software, you are violating their rights. You would be stealing their implementation without a valid license (in effect even if not in intent). That all said - I see the GPL as being similarly evil to patents. The concept is that the idea can be owned by a person or entity, and this ownership grants the person the right to limit access to the idea. The GPL is not a free license. It is a restrictive license that plays with the concept of *enforcing* freedom. I want to see the patent office closed, and I'd like to see the GPL invalidated in a court of law. 10 lines of code that provide nothing exceptionally unique that could be easily re-written by somebody else who has knowledge of the algorithm should not be possible to protect in ANY way. It is not providing unique value that requires protection in order to encourage people to contribute. The proof of this for me is that other licenses that are far more free have communities that thrive just as well as the GPL communities. People like the GPL, or they like the BSD license. But, when it really comes down to it, a person looking to contribute to a project does not usually say I refuse to participate in your project because it has a BSD license. The GPL is evil and deserves to be struck down. Oops - I think this will get me kicked out of the gcc@gcc.gnu.org list. :-) Cheers, mark -- Mark Mielkem...@mielke.cc
Re: machine figure
Jason mclaughlin wrote: Say pieces on a board, make each a pair with another piece. like... |55|44|66| |44|66|55| so figure out how a piece can move. This is the second post I've seen like this - and no responses. What is the proposed value of this line of thinking? Is there some particular optimization that can be designed as a result? Do you have verifiable evidence that it will provide value? Perhaps sample C code and the theoretical assembler code you think should be generated alongside the current assembler code generated by GCC? Or is this rambling thoughts on a subject? I'm interested in reading about the former. I have no interest at all in reading about the latter. :-) Cheers, mark -- Mark Mielke [EMAIL PROTECTED]
Re: Optimization of conditional access to globals: thread-unsafe?
Michael Matz wrote: Yes, and of course GCC doesn't move stores or loads over functions calls. That's not the issue at all. The issue is, that people want to write this: if (condition) *p = value; (i.e. without any synchronization primitive or in fact anything else after the store in the control region) and expect that the store indeed only happens in that control region. And this expectation is misguided. If this is correct (condition makes no function calls and no volatiles are used, then I understand and agree. Cheers, mark -- Mark Mielke [EMAIL PROTECTED]
Re: Optimization of conditional access to globals: thread-unsafe?
David Miller wrote: From: Michael Matz [EMAIL PROTECTED] Date: Sun, 28 Oct 2007 18:08:23 +0100 (CET) I mean who am I to demand that people write correct code, I must be insane. Correctness is defined by pervasive common usage as much as it is by paper standards. Reading this thread, I find myself confused. GCC is used regularly for both multi-threaded and single-threaded code. It is impractical to require all variables that may be shared between threads to be declared volatile. Worse, I find myself suspecting it may be impossible. Any particular library may be used from a multi-threaded context or a single-threaded context, with a very common belief that the access can be protected by wrapping all accesses to the thread-unsafe resource with a mutex. Are some people here really suggesting that all variables everywhere be declared volatile? I remain unconvinced that declaring these shared variables volatile is correct. Certainly, if the ordering of reads and writes must be carefully controlled completely by the programmer, volatile should be used. Most uses are not like this. Most uses require only lose ordering. The lose ordering is providing by a mutex or other synchronization primitive. As any function call might call a synchronization primitive, this would mean that any function call should ensure that all scheduled reads or writes to shared data before the function is called, be performed before the function is called. Similarly, all such data may have changed by the time the function returns. Unless the function can be proven to have no effect (global optimization analysis? function inlining?), this is expected behavior. Am I stating the obvious? Is this an unreasonable expectation for some reason? Do I not understand the issue? Cheers, mark -- Mark Mielke [EMAIL PROTECTED]
Re: Optimization of conditional access to globals: thread-unsafe?
Dave Korn wrote: On 29 October 2007 01:38, David Miller wrote: You'll be back. Next week, you'll discover a corner case where caching a shared variable in a register can be a bad thing when one thread uses locks and the other doesn't, and you'll be back to demand that optimisation is removed as well. Why would David ask for something so unreasonable? Why do you believe that the use of mutex to synchronize access to a shared resource, without the use of volatile on the shared resource being accessed, as documented in countless real life examples, is unreasonable or incorrect? I do not understand your position. Cheers, mark -- Mark Mielke [EMAIL PROTECTED]
