We use the linux kernel implementation at neovim. But a libc (and possibly asm optimized) implementation would be nice too (it could avoid two runs over the data). Not that it's likely to be a big improvement, strlen and memcpy are usually some of the most optimized functions there are.
Only if the implementation details (aside from what is dictated by the spec) of strlcpy meets the originality threshold of a copyrightable work, no?
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.
If you would care to look at the code, it is obvious that this is one of the simplest ways to build strlcpy (basically a call to strlen and memcpy and some branching), perhaps I should've said linux kernel-style such that readers familiar with it would know it without needing to look. It is trivial to come up with such an implementation.
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?
If they include work derivative of a GPLed work they don't have to change the license. The license just has to be compatible and redistribution has to conform to the requirements of the GPL.
This distinction is important because someone could take the non-GPL part and distribute it separately under the original license.
Actually, there are big problems with strcpy_s and strcat_s. First, strcpy_s abort()s the process if there would have been an overflow, making it useless for most programs. Second, Microsoft already has a function named strcat_s, and it behaves differently than the spec.
In VC++, numberOfElements is the size of strDestination. In the C11 spec, that parameter is the maximum number of bytes to copy into strDestination. People are going to search for strcat_s docs, find the MSDN page, and write buffer overflows.
> Actually, there are big problems with strcpy_s and strcat_s. First, strcpy_s abort()s the process if there would have been an overflow, making it useless for most programs
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.
"aborting is correct: unexpected truncation is always a logic bug"
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.
aborting is a terrible, terrible way to signal an error. strlcpy has a return code to report truncation. Discipline around return codes is already required in C. It's not a huge burden to bear (and if you're doing it right there should be lints to detect when checks are missing).
This seems like a very similar situation to egcs and gcc: a fork created because the original project proved too painful to work with, and folded back in after sorting out the project governance issues that caused the fork in the first place.
It's not quite as drastic: with egcs they basically just killed gcc and renamed egcs, while here it was more of a merger of the projects. Very similar, though.
They are in a funny way opposite (and I certainly know whereof I speak: look at who wrote this message [0]).
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!
The former might be true, but it's very unlikely the latter, hard and harsh experience has shown that in the long term few things can impede development more than having RMS as a gatekeeper.
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.)
I wish I could find his rant about his refusal to add binary coded decimals to the C standard, his refusal to allow anyone to add them to glibc, and his assertion that BCD is useless.
Strikes me that a certain stiffness of attitude will serve Dr Drepper well in his new job. Perhaps people need to find a place/community that fits their cognitive style?
The reporter didn't provide enough detail to begin with, and was rude as well.
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.
I am not sure why you've been so heavily downvoted, other than "lots of people disagree".
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.
AND
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.
Yeah, the more information you require the less likely people are to fill it in.
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.
> The reporter didn't provide enough detail to begin with, and was rude as well.
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 */
...is about the most perfectly-written bug you can ask for and was enough context for drepper to understand.
I don't apologise for him, or defend him. However, I do have some insight into what may have caused this unsettling behaviour.
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.
You don't need the spec to see that "0xz" doesn't match "%x%c". The man page for scanf is sufficient, as is having read K&R. This is extremely basic C standard library stuff; it's not an odd corner case.
Sure. A good maintainer would see that, and perhaps ask politely for the missing required information.
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.
Odd. I had always been convinced that they switched back to glibc again a while ago, but it seems they're beginning to do it only now.
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.
Wow, Debian (and by extension Ubuntu) has been using eglibc for five years and I haven't noticed?
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.
You would not notice because it's practically the same. All files have the same names (afaik) for example. They are compatible, and eglibc was like a drop-in replacement. I believe they share nearly all code.
He's now at Goldman Sachs.
https://www.linkedin.com/in/ulrichdrepper