3 ms·

Life would be much simpler for many us if people would stop complaining on internet forms and starting contributing to open-source or standardization efforts.

by uecker 2y ago

o11c 2y ago
Is "don't go out and actively break programs you used to promise would work" such a great ask?
- uecker 2y ago
  About what are you talking exactly? What was actively broken?
  - o11c 2y ago
    `__builtin_dynamic_object_size` has been buggy since it was first implemented, breaking programs that relied on the previously-documented behavior of `malloc_usable_size`. Instead of fixing the bug, the developers decided to remove the documentation and replace it with something else, breaking backwards compatibility. Now, it's not that we can't ever break backwards compatibility - but it needs to be done with great deliberation and a transition period, and an alternative needs to be provided. I gave an example of an alternative.
    - uecker 2y ago
      This seems not entirely accurate. "malloc_usable_size" was only recommended for use for statistics before the change in man page: "Although the excess bytes can be overwritten by the application without ill effects, this is not good programming practice:" and "The main use of this function is for debugging and introspection". The new version makes it clearer. You can find the change here: https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=015464751006a964ff401f1eb5945ca28c4448a7 https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/... Also no code is "actively broken" by a documentation change. If it happened to work before it still works today. Also I do not see how __builtin_dynamic_object_size is broken. It works as intended and can be used with conforming code just fine. It is simply not compatible with some questionable use of "malloc_usable_size".
      - o11c 2y ago
        It's not the documentation change that's the problem. It's the fact that they changed implementation-defined behavior to undefined behavior in the first place (then changed the documentation to follow). Or equivalently, they changed "recommended" to "required". In particular, the "without ill effects" is no longer true. It's possible to #ifdef to detect broken libc/compiler combinations, but I'm not confident that avoiding explicit use of __builtin_dynamic_object_size will prevent optimizations from taking advantage of false assumptions based on __attribute__((malloc)).
matheusmoreira 2y ago
Over many years I've made several attempts to contribute to GNU projects and I don't think I've ever succeeded. At some point I started to wonder if I just suck at all this. I don't seem to encounter any problems when I interact with any other project though so that can't be it. And I don't mean simple reports either, I mean I've sent patches which ranged from bug fixes to minor and major features. Most recent example: sent a patch that added a separate path variable to bash specifically for sourcing bash scripts, thereby creating a simple library/module system. At some point people called my idea "schizophrenic" and I just left. I was developing some GCC patches to add builtins that emit Linux system call code. This is just something I'm personally interested in. Lost the work when my hard drive crashed and I'm unsure whether to restart that little project. The people on the mailing list didn't seem to agree with it very much when I tried to justify it. Honestly the idea that I might spend all this time and effort figuring out and hacking on the absolutely gigantic GCC codebase, only to end up with zero results to show for it, makes complaining on internet forums a very attractive alternative. Who knows, maybe someone who's already involved will read the comments and be convinced. Someone like you.
- uecker 2y ago
  Fair enough. It is just that got involved for similar reasons. I wanted certain things to work and nobody listened to me or fixed the bugs I filed. Now I know first hand what tremendous amount of work it is to change anything, I am not so excited about comments such as "the standards committee should simply". It is never that simple for a variety of reasons. It would also be very important to file bugs to compilers and this is a simple way to contribute, even if this can be frustrating because often nothing happens for a long time.
  - matheusmoreira 2y ago
    I see what you mean. Yeah it's extremely difficult. I guess I learned that the hard way. Thought everything would proceed smoothly if I just showed up with the code already working. All they had to do is review it and apply it if they found no issues, right? Not so. I've also filed a few bugs and feature requests on the LLVM issue tracker and GNU mailing lists. LLVM has like a trillion open issues, it's like shouting into the void. GNU almost always tells me the existing stuff should be enough and that I don't really need whatever it is I'm asking for. For example, I requested a way to make the linker add extra PT_NULL segments to the ELF output file so that I could find and patch those segments later. LLVM has yet to respond to the issue I created, and GNU says the arcane linker scripting is enough even though the example they gave me didn't work. Only person who responded favorably to me was the maintainer of the mold linker, he added a couple lines of code and suddenly I could easily patch ELF segments. As a result, I fully integrated the mold linker into my makefile and switched to it. My point is this: > I am not so excited about comments such as "the standards committee should simply" I can relate with that feeling. It's just that we're also not so excited by comments along the lines of "pull requests welcome". That's a direct challenge to rise up and directly participate. When we do, it often happens that we are not even given the time of day. To say it's frustrating would be an understatement. I'm not going to enumerate every negative experience I've had, better to leave it all in the past. However, I've concluded that many times effort does not equal reward, and that it might just be easier to ask the insiders to change things instead and leave things be if they don't seem convinced. Change is difficult enough for the insiders to make, for an outsider it's orders of magnitude more difficult.

Life would be much simpler for many us if people would stop complaining on internet forms and starting contributing to open-source or standardization efforts.

by uecker 2y ago

Life would be much simpler for many us if people would stop complaining on internet forms and starting contributing to open-source or standardization efforts.

o11c 2y ago

Is "don't go out and actively break programs you used to promise would work" such a great ask?

uecker 2y ago
About what are you talking exactly? What was actively broken?
- o11c 2y ago
  `__builtin_dynamic_object_size` has been buggy since it was first implemented, breaking programs that relied on the previously-documented behavior of `malloc_usable_size`. Instead of fixing the bug, the developers decided to remove the documentation and replace it with something else, breaking backwards compatibility. Now, it's not that we can't ever break backwards compatibility - but it needs to be done with great deliberation and a transition period, and an alternative needs to be provided. I gave an example of an alternative.
  - uecker 2y ago
    This seems not entirely accurate. "malloc_usable_size" was only recommended for use for statistics before the change in man page: "Although the excess bytes can be overwritten by the application without ill effects, this is not good programming practice:" and "The main use of this function is for debugging and introspection". The new version makes it clearer. You can find the change here: https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=015464751006a964ff401f1eb5945ca28c4448a7 https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/... Also no code is "actively broken" by a documentation change. If it happened to work before it still works today. Also I do not see how __builtin_dynamic_object_size is broken. It works as intended and can be used with conforming code just fine. It is simply not compatible with some questionable use of "malloc_usable_size".
    - o11c 2y ago
      It's not the documentation change that's the problem. It's the fact that they changed implementation-defined behavior to undefined behavior in the first place (then changed the documentation to follow). Or equivalently, they changed "recommended" to "required". In particular, the "without ill effects" is no longer true. It's possible to #ifdef to detect broken libc/compiler combinations, but I'm not confident that avoiding explicit use of __builtin_dynamic_object_size will prevent optimizations from taking advantage of false assumptions based on __attribute__((malloc)).

matheusmoreira 2y ago

Over many years I've made several attempts to contribute to GNU projects and I don't think I've ever succeeded. At some point I started to wonder if I just suck at all this. I don't seem to encounter any problems when I interact with any other project though so that can't be it. And I don't mean simple reports either, I mean I've sent patches which ranged from bug fixes to minor and major features. Most recent example: sent a patch that added a separate path variable to bash specifically for sourcing bash scripts, thereby creating a simple library/module system. At some point people called my idea "schizophrenic" and I just left. I was developing some GCC patches to add builtins that emit Linux system call code. This is just something I'm personally interested in. Lost the work when my hard drive crashed and I'm unsure whether to restart that little project. The people on the mailing list didn't seem to agree with it very much when I tried to justify it. Honestly the idea that I might spend all this time and effort figuring out and hacking on the absolutely gigantic GCC codebase, only to end up with zero results to show for it, makes complaining on internet forums a very attractive alternative. Who knows, maybe someone who's already involved will read the comments and be convinced. Someone like you.

uecker 2y ago
Fair enough. It is just that got involved for similar reasons. I wanted certain things to work and nobody listened to me or fixed the bugs I filed. Now I know first hand what tremendous amount of work it is to change anything, I am not so excited about comments such as "the standards committee should simply". It is never that simple for a variety of reasons. It would also be very important to file bugs to compilers and this is a simple way to contribute, even if this can be frustrating because often nothing happens for a long time.
- matheusmoreira 2y ago
  I see what you mean. Yeah it's extremely difficult. I guess I learned that the hard way. Thought everything would proceed smoothly if I just showed up with the code already working. All they had to do is review it and apply it if they found no issues, right? Not so. I've also filed a few bugs and feature requests on the LLVM issue tracker and GNU mailing lists. LLVM has like a trillion open issues, it's like shouting into the void. GNU almost always tells me the existing stuff should be enough and that I don't really need whatever it is I'm asking for. For example, I requested a way to make the linker add extra PT_NULL segments to the ELF output file so that I could find and patch those segments later. LLVM has yet to respond to the issue I created, and GNU says the arcane linker scripting is enough even though the example they gave me didn't work. Only person who responded favorably to me was the maintainer of the mold linker, he added a couple lines of code and suddenly I could easily patch ELF segments. As a result, I fully integrated the mold linker into my makefile and switched to it. My point is this: > I am not so excited about comments such as "the standards committee should simply" I can relate with that feeling. It's just that we're also not so excited by comments along the lines of "pull requests welcome". That's a direct challenge to rise up and directly participate. When we do, it often happens that we are not even given the time of day. To say it's frustrating would be an understatement. I'm not going to enumerate every negative experience I've had, better to leave it all in the past. However, I've concluded that many times effort does not equal reward, and that it might just be easier to ask the insiders to change things instead and leave things be if they don't seem convinced. Change is difficult enough for the insiders to make, for an outsider it's orders of magnitude more difficult.