Proposal: Refactoring platform-specific code in util.h/util.cpp #12697

issue eklitzke opened this issue on March 15, 2018
  1. eklitzke commented at 2:51 PM on March 15, 2018: contributor

    There is a fair amount of code in util.cpp that by its nature has to be done completely differently on Windows and Unix (and sometimes differently on Linux, BSD, etc). There's actually more of this kind of stuff that I want to add e.g. see some of my other outstanding PRs like #12618 and #12696.

    Most of the functions like this are written with a top-level #ifdef that dispatches based on Windows or non-Windows:

    int RaiseFileDescriptorLimit(int nMinFD) {
    #if defined(WIN32)
        return 2048;
    #else
        struct rlimit limitFD;
        if (getrlimit(RLIMIT_NOFILE, &limitFD) != -1) {
            if (limitFD.rlim_cur < (rlim_t)nMinFD) {
                limitFD.rlim_cur = nMinFD;
                if (limitFD.rlim_cur > limitFD.rlim_max)
                    limitFD.rlim_cur = limitFD.rlim_max;
                setrlimit(RLIMIT_NOFILE, &limitFD);
                getrlimit(RLIMIT_NOFILE, &limitFD);
            }
            return limitFD.rlim_cur;
        }
        return nMinFD; // getrlimit failed, assume it's fine
    #endif
    
    

    In a few cases this kind of logic will be interspersed in functions that are otherwise fairly platform independent, e.g. ArgsManager::ParseParameters has logic to convert Unix-style filenames to Windows style filenames:

    void ArgsManager::ParseParameters(int argc, const char* const argv[])
    {
        // ...
    #ifdef WIN32
            boost::to_lower(str);
            if (boost::algorithm::starts_with(str, "/"))
                str = "-" + str.substr(1);
    #endif
        // ...
    }
    

    There are also a few where we need to do different things if we're on Linux, macOS, etc.

    Proposal

    My proposal is to take all of the functions that are specific to Windows or Unix, and create a common set of methods in a new header file called util_platform.h. This would contain prototypes for methods like RenameOver(), FileCommit(), etc.

    Then we'd have two implementation files, util_windows.cpp and util_posix.cpp that implement these methods. The building/linking of util_windows.cpp or util_posix.cpp would be handled using AM_CONDITIONAL. My feeling is that the POSIX stuff is similar enough that we can avoid a util_mac.cpp, util_linux.cpp, etc. for now (and hopefully forever).

    When you add a new function prototype to util_platform.h you need to write implementations in both util_windows.cpp and util_posix.cpp. In some cases that will mean there are empty functions defined which is fine.

    I think if we do this correctly there should be ZERO statements that are checking for #ifdef WIN32 in the rest of the code. As an example, previously I showed some code from ArgsManager that was munging Unix filenames to Windows filenames. I think that should be handled in a function e.g. named MungeUnixFilename() and then on Windows it would implemented with the existing lowercase/replace slash logic, and on POSIX systems it would be a function that just returned the original string unchanged.

  2. ryanofsky commented at 3:15 PM on March 15, 2018: member

    Seems like a good idea. I think you could drop the util naming and just say platform, platform_windows, etc.

  3. meshcollider added the label Refactoring on Mar 15, 2018
  4. donaloconnor commented at 10:22 PM on March 15, 2018: contributor

    Very much agree. This is something I've also thought about.

  5. eklitzke commented at 7:30 AM on March 19, 2018: contributor

    This would also make it easier to get good code review on platform specific changes, as we could set up the appropriate policy in these files: https://blog.github.com/2017-07-06-introducing-code-owners/

  6. practicalswift commented at 7:59 AM on March 19, 2018: contributor

    Concept ACK

  7. HashUnlimited commented at 6:58 PM on March 27, 2018: contributor

    For the proposed scope fine, please keep in mind that AM_CONDITIONAL is not covering the environment but leaving out certain Kernels. That can cause issues when using anything originated in plain C like ctaes as they need -fPIC flags explicitly passed to the compiler

  8. eklitzke commented at 6:09 AM on March 28, 2018: contributor

    @HashUnlimited I don't think that's an issue because if AM_CONDITIONAL were used it would only be to select a version of the util code used by bitcoin. This can also be done without changing automake at all (for example, the current util.cpp code is cross-platform without special automake logic). If I misunderstood you please correct me.

  9. glaksmono commented at 6:10 AM on May 9, 2018: contributor

    Agree. Would like to take a stab on this @eklitzke

    Seems like a good idea. I think you could drop the util naming and just say platform, platform_windows, etc.

    and have these files in the src/util/ folder? @ryanofsky

    WIP PR #13209

  10. ryanofsky commented at 7:19 PM on May 11, 2018: member

    and have these files in the src/util/ folder? @ryanofsky

    I was just thinking src/platform_X instead of src/util/platform_X, but it seems ok to have more naming. Also, to put earlier comment in context, I think this idea seems perfectly fine, but also that you should probably get feedback from more developers before investing too much effort in an implementation.

  11. glaksmono commented at 2:55 PM on May 12, 2018: contributor

    Yes @ryanofsky - waiting for more feedback from more developers. I also put some discussion points on the PR https://github.com/bitcoin/bitcoin/pull/13209

  12. glaksmono commented at 11:59 AM on May 14, 2018: contributor

    Should we close this Issue per #13209 (comment) ?

  13. MarcoFalke commented at 12:46 AM on April 27, 2020: member

    The feature request didn't seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.

    Closing due to lack of interest. Pull requests with improvements are always welcome.

  14. MarcoFalke closed this on Apr 27, 2020

  15. DrahtBot locked this on Feb 15, 2022

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-13 18:15 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me