Well point #1 does matter because it does show to the uninformed public that Linus does not rant at Johannes Weiner for creating the patch but rants at Andrew Morton who approved of the patch and is the one that should know better than that.
This is Linux and LKML, nothing is done in private. All conversations and development is done in public. And I have yet to see Linus rant against "new unknown guy" unless said person have really really fucked up beyond repair (I somehow recall a situation some years ago where an individual was trying to get in a patch in order to get "Linux Kernel developer" in his CV so he submitted bad patch after bad patch until Linus lost it), he only rants at people who both can take it and that should know better.
Andrew might actually appreciate the rant believe it or not. Given a rant from Linus means that you provide something of great value to him and that you have an opportunity to improve. In organisations where things like this gets swept under the rug you one day wake up realising that you have stalled in your performance and are no longer relevant. It would have been a completely different thing if Linus has given him a rant on a regular basis like how supposedly Bill Gates management style was.
you really thinks that he personally reviews and approves all those patches? This work is "outsourced" to the various subsystem maintainers, incidentally it's one such maintainer that Linux is directing the rant for approving the patch in question.
ok that sucks. Too bad that the vendors that you have to deal with is so slow moving. One can only wonder why they have such complex scripts in the first place, most of the ones that I have seen have been trying to replicate functionality that is now supported natively by systemd so there I could just simply strip it away completely. Perhaps you are allowed to post these scripts somewhere so that others can see what they are trying to do if the vendors themselves are not interested in helping out.
I do feel your pain but I cannot really see this as the fault of systemd but more of these particular vendors. And it should be trivial for them so why they don't is something that they have to answer for themselves, not the first time that external vendors have not done things regardless of how trivial they are.
No I don't say that it's not relevant, I say that it's not a choice between a rock and a hard stone but between a hard place and a stinging nettle. Having your machine taken over completely for what ever sinister means is in my book far far worse than a local (non-remote) user can stall the init system. Is it bad? Yes, is it the end of the world? No.
So does C so I don't really get your logic here. In fact most if not all languages lets you choose. The choice might render more work in the end in some language vs another but that is besides the point.
Yes that is correct of course. For most other situations however the reference will be set dynamically outside the compilers reach, for example via external input, and when that happens it cannot optimize away the constraints. For the specific bad example from parent with a constant it should even trigger a compiler error if the C++ compiler where smart enough.
Desktop manager and Window manager? Are you somehow referring to Gnomes dependency of logind, that they (i.e Gnome) did because there was no other or better solution for that they wanted than logind?
Because my string function does things differently than the standard string class in C++? Because working with strings is not all that I do? So why should I switch languages just because they happen to do one thing by default that otherwise have to write some small code once in order to have? Do you constantly switch languages when they implement functionality that you do not have out of the box in C++? I don't think so.
But that was not the point, the claim by parent was that the constraints made the code faster which it doesn't, it actually makes it slower and that is what I replied to.
If you disable the constraints then all of the benefits of the "safe language" is lost so why you would disable the in a release build and then name C++ safer than C is way beyond me.
Of course not, they assert to make sure that the function is not called with a zero length. Which as you say is a situation that cannot and should not happen. Somehow they never tested it with a zero length string, that indeed is a major fuckup.
tags = strv_split(buf, "\n\r");
if (!tags) {
log_oom();
return;
}
As you can clearly see the assert(n > 0); would throw SIGABORT and thus kill the process. Remove the assert and strv_split() which obviously works on zero terminated strings (since it does not take a size parameter) will return NULL and the function returns. Since a zero byte string will be a single \0 character this is the reason why some people could not reproduce the problem since their asserts where never there.
eg. The compiler writer can optimize the compiler for std::vector rather than trying to optimize for every conceivable way a C programmer could mess around with pointers.
Actually it's the other way around, the great performance in C comes from the lack of restraints. When you in C does say a[-1]=0x666; then the compiler have no restrains what so ever so it can just overwrite that memory location and go on happily. In C++ however with std::vector there are constraints that it _must_ abide so the compiler have no choice but to impose two conditionals and one branch for every write reference to a[x];. If it didn't then it would no longer be "safe" and you would also no longer get your exception.
b) Yes. C++ makes it far easier to change data structures and optimize the code for different architectures than C does.
Now I don't fully follow you for which architectures you refer to where you have to use wcscmp() over strcmp(), but I have "ported" code between x86, x86_64, Power and Arm without changing a single line of code so C++ would not have helped me more there.
eg. Updating code to to use strncpy() instead of strcpy(). It's going to be a lot of work to adapt a large C program to do that. If you're using a string class which defines operator=() for string copy then you change a few lines of code, job done.
Or you have your own string functions (or use any of the ones from a shared library) which provides the same thing.
What else are you defending if not SysV? That is what got replaced and what made you so angry. So why are you so angry if what was replaced was not so beloved by you?
Slashdot Mirror
Well point #1 does matter because it does show to the uninformed public that Linus does not rant at Johannes Weiner for creating the patch but rants at Andrew Morton who approved of the patch and is the one that should know better than that.
Andres is one of the best there is which is also why he got that Linus-rant.
This is Linux and LKML, nothing is done in private. All conversations and development is done in public. And I have yet to see Linus rant against "new unknown guy" unless said person have really really fucked up beyond repair (I somehow recall a situation some years ago where an individual was trying to get in a patch in order to get "Linux Kernel developer" in his CV so he submitted bad patch after bad patch until Linus lost it), he only rants at people who both can take it and that should know better.
Andrew might actually appreciate the rant believe it or not. Given a rant from Linus means that you provide something of great value to him and that you have an opportunity to improve. In organisations where things like this gets swept under the rug you one day wake up realising that you have stalled in your performance and are no longer relevant. It would have been a completely different thing if Linus has given him a rant on a regular basis like how supposedly Bill Gates management style was.
What card is that? My RX 480 works flawless with 4.7.4 and mesa-git
you really thinks that he personally reviews and approves all those patches? This work is "outsourced" to the various subsystem maintainers, incidentally it's one such maintainer that Linux is directing the rant for approving the patch in question.
Exactly this. AFAIK he is equally harsh against his own errors.
ok that sucks. Too bad that the vendors that you have to deal with is so slow moving. One can only wonder why they have such complex scripts in the first place, most of the ones that I have seen have been trying to replicate functionality that is now supported natively by systemd so there I could just simply strip it away completely. Perhaps you are allowed to post these scripts somewhere so that others can see what they are trying to do if the vendors themselves are not interested in helping out.
I do feel your pain but I cannot really see this as the fault of systemd but more of these particular vendors. And it should be trivial for them so why they don't is something that they have to answer for themselves, not the first time that external vendors have not done things regardless of how trivial they are.
No I don't say that it's not relevant, I say that it's not a choice between a rock and a hard stone but between a hard place and a stinging nettle. Having your machine taken over completely for what ever sinister means is in my book far far worse than a local (non-remote) user can stall the init system. Is it bad? Yes, is it the end of the world? No.
You do know that you can run the old sysv init scripts with systemd?
ok so if you are not talking about Gnome and logind then please enlighten me because I have no clue what you are referring to.
So does C so I don't really get your logic here. In fact most if not all languages lets you choose. The choice might render more work in the end in some language vs another but that is besides the point.
Yes that is correct of course. For most other situations however the reference will be set dynamically outside the compilers reach, for example via external input, and when that happens it cannot optimize away the constraints. For the specific bad example from parent with a constant it should even trigger a compiler error if the C++ compiler where smart enough.
Desktop manager and Window manager? Are you somehow referring to Gnomes dependency of logind, that they (i.e Gnome) did because there was no other or better solution for that they wanted than logind?
I really thought that people understood that I meant except for the fricking CVE that this whole thread is about...
Because my string function does things differently than the standard string class in C++? Because working with strings is not all that I do? So why should I switch languages just because they happen to do one thing by default that otherwise have to write some small code once in order to have? Do you constantly switch languages when they implement functionality that you do not have out of the box in C++? I don't think so.
But that was not the point, the claim by parent was that the constraints made the code faster which it doesn't, it actually makes it slower and that is what I replied to.
If you disable the constraints then all of the benefits of the "safe language" is lost so why you would disable the in a release build and then name C++ safer than C is way beyond me.
consume exactly what? They provide alternatives to some of the system tools, how that can be seen as such a big problem is beyond me.
Of course not, they assert to make sure that the function is not called with a zero length. Which as you say is a situation that cannot and should not happen. Somehow they never tested it with a zero length string, that indeed is a major fuckup.
Actually no, this is how the code looked:
static void manager_invoke_notify_message(Manager *m, Unit *u, pid_t pid, char *buf, size_t n) {
_cleanup_strv_free_ char **tags = NULL;
assert(m);
assert(u);
assert(buf);
assert(n > 0);
tags = strv_split(buf, "\n\r");
if (!tags) {
log_oom();
return;
}
As you can clearly see the assert(n > 0); would throw SIGABORT and thus kill the process. Remove the assert and strv_split() which obviously works on zero terminated strings (since it does not take a size parameter) will return NULL and the function returns. Since a zero byte string will be a single \0 character this is the reason why some people could not reproduce the problem since their asserts where never there.
eg. The compiler writer can optimize the compiler for std::vector rather than trying to optimize for every conceivable way a C programmer could mess around with pointers.
Actually it's the other way around, the great performance in C comes from the lack of restraints. When you in C does say a[-1]=0x666; then the compiler have no restrains what so ever so it can just overwrite that memory location and go on happily. In C++ however with std::vector there are constraints that it _must_ abide so the compiler have no choice but to impose two conditionals and one branch for every write reference to a[x];. If it didn't then it would no longer be "safe" and you would also no longer get your exception.
b) Yes. C++ makes it far easier to change data structures and optimize the code for different architectures than C does.
Now I don't fully follow you for which architectures you refer to where you have to use wcscmp() over strcmp(), but I have "ported" code between x86, x86_64, Power and Arm without changing a single line of code so C++ would not have helped me more there.
eg. Updating code to to use strncpy() instead of strcpy(). It's going to be a lot of work to adapt a large C program to do that. If you're using a string class which defines operator=() for string copy then you change a few lines of code, job done.
Or you have your own string functions (or use any of the ones from a shared library) which provides the same thing.
I take it that you are a Windows programmer (by the reference to wcscmp) ?
Of course, which is why there is always some nice rant to be found on LKML from Linus about the GCC developers :)
What else are you defending if not SysV? That is what got replaced and what made you so angry. So why are you so angry if what was replaced was not so beloved by you?