On Wed, 2026-03-11 at 14:01 +0100, Tomás Ortín Fernández (quanrong) wrote: > Hi David, thanks for your review! > > > One legal prerequisite is that you need to either > > (a) add the Signed-off-by tag to certify that you can contribute > it, as > > per https://developercertificate.org/ (relatively easy), or > > (b) jump through the legal hoops described here: > > https://gcc.gnu.org/contribute.html#legal (rather harder). > > For the time being, I will just use the Signed-off-by tag, as the > assignment process probably takes a long time. I would like to > obtain > the documentation to assign copyright to the FSF for all my future > contributions to GCC, as I have the intention to contribute for the > long > term.
(nods) > > I have updated the patch following your suggestions, I'll send it as > a > separate email. Here I will reply to some of the review comments. I've put a review of the updated patch as a reply to that other email. > > > Out of interest, how long did the bootstrap and testing take you? > If > > that's a bottleneck, we may be able to set you up on a faster > machine > > on the compile farm. > > Around 7 hours or so, I'm not sure of the exact number of hours, both > times that I have done it, I left it overnight and didn't pay much > attention to the total time. Having access to a more powerful build > machine would be quite helpful. Yeah. We have a "compile farm" with plenty of powerful machines, which are useful for that. See https://portal.cfarm.net/ [...snip...] > > This patch is close to being ready, but, to repeat something I > > mentioned in an email to another candidate, right now we're in > feature > > freeze for GCC 16, trying to focus on stabilizing for the > release. We > > call this "stage 4" of the release cycle. Hence I plan to wait > before > > actually pushing the patch. Hopefully we'll transition to stage 1 > of > > the GCC 17 release cycle sometime next month (when we're open to > new > > features). > > That's not a problem, but I have a question related to it. Once the > patch is considered done, it becomes very easy to add support for > `mkostemp`, `mkstemps`, `mkostemps`, and `mkdtemp`. If the patch is > not > yet merged, what would be the correct way to go about it? I could > update the current patch to support those, but I would prefer to > consider it "done" (once it is) and add support for the related > functions in a different patch. I too would prefer it if you did followup work as a followup patch on top of the first patch, rather than squashing/merging. I think the first patch is close to being done, so I don't expect too much rebasing pain. > Is it better to just wait, or is there > some way to both consider this patch done and continue working based > on it? Local git branches are essentially free and make this fairly easy - inasmuch as anything in git can be considered "easy" :) > > > Thanks again for the patch; hope this is constructive > > It is, thank you for the review. Thanks again for the updated patch. Dave
