factor config_fopen out of wrapper.h

[goatshriek]

Stumpless uses a scheme involving #definenames and macro functions to separate its portability measures from the application logic itself. This was originally done via a single header, include/private/config/wrapper.h, but as the library grew this single header became bloated. Now features are instead contained in their own dedicated wrapper headers. Older features and functions need to be moved to their own as well to address the original problem.

Your task here is to factor the function used to open files into it's own header. This is a good task for those with some C knowledge looking to learn about how to implement portability in a C application. As this is a refactoring task you can rely on the existing unit and integration tests as a safety net as you make changes and explore.

Check out the Contributing Guidelines and the development guide for the basics on working with stumpless and submitting changes.

General Approach

There are a few details left out of the following approach, for you to fill in as you encounter them. If you find you need help, please ask here or on the project gitter and someone can help you get past the stumbling block.

97698be5b62c3fd1dddfd953db15a5c7265b896c is an implementation of a very similar task: you can use this commit as a template for this task.

First, read through the portability documentation to understand how portability is approached in the library.

Next, have a look at include/private/config/wrapper/wstring.h. This header does the same wrapping for wide string support functions in the library. This is a great file to copy as a starting point and modify to suit your needs. The new header should be include/private/config/wrapper/fopen.h.

Finally, have a look at tools/check_headers/stumpless_private.yml. This file is used by a custom tool for header inclusion checks across the library's source code. You'll need to add an entry for config_fopen to this file, pointing to your newly created header.

Once you have moved things to your new header and updated the header checking tool manifests, you can use the header check tool to tell you what files need to have their #include statements updated. You can find examples of how to run the tool in the testing workflow that does it, .github/workflows/analysis.yml, or you can use the one-liner included below. You will need Ruby to run the tool.

tools/check_headers/check_headers.rb "include/**/*.h*" "include/**/**.h*" "src/**/*.c" "test/**/*.cpp" "docs/examples/**/*.c"

Good luck!

[Sakshi-75]

Hi @goatshriek , can I work on this?

[goatshriek]

I discourage contributors from working multiple "good first issue"s that are focused on the same problem, and this issue is a direct successor to the one you just resolved. Since you've already been through this exercise I don't think you would gain as much from it as someone who hasn't worked through one of these yet.

There are a number of other issues with detailed guides, have a look through those to see if they interest you.

[iltenahmet]

Hi @goatshriek, I'm new to open source, can I work on this?

[goatshriek]

Absolutely! I've assigned it to you so that others know you are working on it.