He's now at Goldman Sachs.
edit: Also depends on the jurisdiction, http://en.wikipedia.org/wiki/Threshold_of_originality#Exampl... - and you don't necessarily have to change your own license, a valid resolution is also to stop distributing versions of your program that incorporate GPL'd code.
IANAL, but at what point do you need to change the license of the entire project? 1 line of code, 3 lines, 5 lines, what constitutes using code from another project? If you call memcpy and your parameters are named the same as the parameters in my project for a memcpy call, who gets to declare his license over that line and thus the project, if it so happens that you once looked at my project? The first one who "invented" it?
This distinction is important because someone could take the non-GPL part and distribute it separately under the original license.
Here's VC++'s strcat_s:
const char *strSource
If strlcpy/strlcat aren't available on a target platform, I stick them them in a util.h/util.c, wrapped in #ifndefs. Like so: https://github.com/ggreer/the_silver_searcher/commit/a43dc87...
aborting is correct: unexpected truncation is always a logic bug. Truncation can lead to unexpected behavior, so better to fail fast than to get into a state about which you probably haven't reasoned. If you really want strlcpy-like truncation, use strncpy_s (which, unlike strncpy, acts sanely with respect to NUL termination and filling). Of course, on untrusted input copied into a fixed-size buffer, you should be using strncpy_s instead of aborting. Use the right tool for the job.
> In VC++, numberOfElements is the size of strDestination. In the C11 spec, that parameter is the maximum number of bytes to copy into strDestination.
That's not actually a distinction. The purpose of the function is to ensure that the code writes no more than numberOfElements bytes into strDestination. Both versions of the function do that.
Note that the wide character versions of these functions are both specified in number of elements. (So are the narrow character versions, but the difference in moot because sizeof(char) == 1).)
> If strlcpy/strlcat aren't available on a target platform, I stick them them in a util.h/util.c, wrapped in #ifndefs.
Or you can use https://slibc.googlecode.com/svn/api-doc/html/index.html
How does a function knows what a programmer expects... A lot of use for those potentially truncating functions are for display purpose, where truncating is expected and not a logic bug...
A library function potentially exiting is mostly useless.
> He's now at Goldman Sachs.
A much better fit for both parties, from a cultural / personality perspective.
It's hard to remember, but back in 1997 forking was considered really terrible and to be avoided at all costs. When we split off to form egcs the main resistance was to the idea that there would be a fork at all. Gcc, and a bunch of other programs, had a single person who controlled the "official" release. The fact that Cygnus maintained its own release tree for its customers (it was still free -- it simply wasn't identical to the mainline, and in fact advanced a lot faster) was the cause of much angst and even some mistrust.
My reason for making this fork was because the mainline was so far behind us, and we had a commitment to folding all our changes back into the main line. Since the gcc maintainer was the bottleneck, we simply declared our tree a new fork with the support and participation of other major developers. We were trying to be the opposite of exclusivist. But even so it took me months of mailing, calling and negotiating. Many hours on the phone with rms who of course predicted the doom of free software if we went ahead.
And we developed a steering committee, the first as far as I know for a free software project.
In those two ways egcs was a watershed; plenty of developers thankfully now know no other way.
So last year glibc went the opposite way: it decided it no longer needed a steering committee. Cool!
He's a difficult person, or so I observed when we were in the same social circle, later when I was working for LMI while he was replicating the most essential new Zetalisp functionality, when we both had given up on that and were roommates when he launched the GNU project, and afterwords when for a while I worked for a "Software Hoarder", specifically the company that actually had a license for (James) Goslings Emacs, which GNU Emacs is an illicit fork of. (He even accused that company of setting fire to his apartment building; in truth it was pretty generic arson by "a couple of kids", not surprising because it was in a not so nice part of Cambridge.)
It seems emacs has been steadily, if somewhat slowly, improving (new releases etc).
I dare you to top that.
I'm a little bit proud that I one time he told me "That's a good catch" (after verbally abusing someone else previously on the same bug).
Alas, it appears un-googlable.
No excuse for rudeness, but I understand why he may have gotten that way.
Can you imagine the number of silly bugs the glibc maintainer has to go through? Year, after year? Especially when people don't give enough evidence.
That is bug twelve thousand seven hundred and one. Developing a way to deal with all of those badly reported bugs quickly would be to do it like this. Just tell the people they are wrong, and have them provide more detail to prove their case. If you say, "Can you please provide more information", often bug reports just sit there.
Again, I don't condone the behaviour personally, since I would put people above the software. But I can see how maintaining glibc for many years would warp a person.
If anything, I think the problem is that he provided too much detail, since that detail alone should have been dispositive.
Perhaps if bug-lists are so awful to read (and I have no doubt that they are) then the people reading them need more [close] buttons.
[close - no ref to standard]; [close - no test example code]; etc, and these provide templated replies that ask people for correct reports.
"We closed this bug. You MUST provide a clear reference to the specification showing how $THING is non-compliant.
you MUST provide a test example code snippet".
This would help de-stress people reading the bugs, and might prompt people providing bugs to provide correct information.
I agree that templates are often hateful nasty things - templates on Wikipedia are really nasty approach. But here the alternative is, well, also pretty unpleasant for some people.
I've been a fan of "search" not categorise for bugs for this reason. People are more likely to blog about, or tweet about a bug than put it into a bug tracker.
The role of an issue gardener is a really useful one too. A person whose job it is to go into issues, and make them useful for developers. To communicate with all sides, and enhance the process for everyone.
A great example of this is when @pyalot tested out various webgl implementations on different browsers. Then he went to all the bug trackers, and made notes. Then linked to various specifications, and pointed to test cases.
This one guy through this has done a massive service to WebGL and the web. I've seen too often various bugs and issues go through 2-3 browser iterations because that's how long it takes for people to seriously test out features and report bugs.
The collaboration going on now because of open bug trackers in web browsers is amazing.
drepper's skill is in goading that response out of people, sometimes unconsciously, sometimes consciously. Take note of where the rudeness began before spending 143 words apologizing for and defending him.
I struggle to think what additional information could be included in this bug report, as you request, since:
f(x) -> y /* erroneous */
f(x) -> z /* correct */
The bug report does not follow the projects standard for reporting bugs.
The main problem is that it does not link to the specification, and explain why it is not up to spec. This is required by the glibc bug reporting standards.
Later the reporter checks the scanf function against another implementation, as is asked for by the glibc documentation. Later the reporter also explains why it is wrong against the specification. If the reporter had read the guidelines initially and done these things, that would have been an acceptable bug report. To not do so is wasting the maintainers time. It is rude if the reporter knew about the bug reporting guidelines, and decided to waste the maintainers time anyway.
In this particular case, I think the reporter and the maintainer could have done a better job.
That's the main job of a good open source maintainer really. Asking for people to provide more information, test cases, and documentation.
In this case, the maintainer queried the behaviour (in a rude way granted), and was not sure why it was wrong. All that attitude from the maintainer was definitely not needed.
If someone reports a bug to your project, make them feel welcome! Numerous times, I've seen these single bug reporter people turn into long time contributors. All it takes is a bit of attention, giving them credit, and providing a nice environment for them.
Anyway, it's good there is a much more functional team heading glibc these days.
Tarballs are a completely outdated concept.
A lot of people are against forks that they deem frivolous or unnecessary, but I think it's one of the most pragmatic and important parts of free software. It's a failsafe, a Second Amendment, if you will.
I even compiled new versions of gcc + glibc (and installed them into $HOME, to run new binaries on older installations). You think I should have noticed that there was no glibc on the host system to begin with. But actually, the only thing I noticed is that the glibc (and gcc) build system is a bit crazy, and that it definitely will benefit from a new project lead.