[Win32] Define I_STDCKDINT and $Config{i_stdckdint} when appropriate.

[sisyphus]

This PR replaces #23777 (which I botched and closed).

In conjunction with (the already merged) #23703, it will define $Config{i_stdckdint} and I_STDCKDINT on Windows builds of perl whenever stdckdint.h is locatable and functional.

---

• This set of changes does not require a perldelta entry.

[sisyphus]

I actually don't have anything against backticks in void context.
The C file was just a modified copy'n'paste of the following entry in perl's Configure script:

#include <stdio.h>
#include <stdckdint.h>
int func(long *resultptr, long a, long b)
{
    return (ckd_add(resultptr, a, b) ||
	    ckd_sub(resultptr, a, b) ||
	    ckd_mul(resultptr, a, b)) ? 1 : 0;
}
int main(int argc, char **argv)
{
    long result;
    return func(&result, 42L, 53L);
}

Note the absence of static and the presence of (int argc, char **argv).
I cite that as a (justifying) precedent.

Actually,I usually do "int main(void)" and thought of making that change but didn't get around to it, having deemed it be of no importance.
At the back of my mind was the notion that "int main(void)" might even be frowned upon.

Anyway, I'll make the suggested changes. Such pedantry is a little annoying, but not a big issue for me.

The main issue, for me, is having to then squash the commits - which is where I came undone in my first effort with this PR.
In order to squash those commits, my intention will be to run:

$ git rebase origin/blead
$ git reset origin/blead
$ git commit -a -m'[Win32] Define I_STDCKDINT and $Config{i_stdckdint} when appropriate'
$ git push -f

Someone please let me know if that's not right. (I'll wait for a couple of days before running it.)

That mantra is something I think I've run before on a couple of occasions with good results - but I'm yet to properly comprehend what's going on here.
And in hindsight, I think the problem that I experienced with my first attempt could have been due to a completely separate mistake, that I have since come to realize.

I also wonder whether I will need to re-run git add win32/configure/have_stdckdint.c or will git still be aware that it has already been added, following the "rebase" and "reset" ? (Maybe the emitted list of "unstaged commits" would answer that question ... if I can remember to peruse it ;-)

[mauke]

Such pedantry is a little annoying, but not a big issue for me.

Honestly, if you think the C comments are just nitpicking, I'm fine with leaving things as they are, especially considering the "justifying precedent": Keeping new code consistent with existing code can also be very useful. I should have said so in the first place and I apologize.

But you already put in the effort, so here's what I do for squashing:

1. git rebase origin/blead

   This rebases your branch and moves it on top of whatever origin/blead is at the moment.

2. git rebase -i origin/blead

   That -i is crucial. It makes git open the list of commits since origin/blead as a "rebase script" in a text editor. You can do all kinds of things in there (like changing the order of commits or deleting some of them), but don't panic and remember two things: There is an overview of the available commands included as a comment within the file, and if you exit your editor without saving, you get a "no-op rebase": Nothing changes.

   In your case, the "script" may look like this:

   pick 6a53dbccf9 [Win32] Define I_STDCKDINT and $Config{i_stdckdint} when appropriate.
   pick 1e9f2b0b18 Update win32/config_sh.PL
   pick acc0cf6ea3 Update win32/configure/have_stdckdint.c
   pick bc572e89d8 Update win32/configure/have_stdckdint.c
   pick 91981bc115 Update win32/configure/have_stdckdint.c
   

   It is in chronological order and we want to keep the first commit, so don't touch line 1.

   For every following line, change the first word (pick) to f (which stands for "fixup"). This tells git to merge all changes from this commit into the preceding commit, but throw away the commit message and only keep the preceding commit message.

   The result should look like this:

   pick 6a53dbccf9 [Win32] Define I_STDCKDINT and $Config{i_stdckdint} when appropriate.
   f 1e9f2b0b18 Update win32/config_sh.PL
   f acc0cf6ea3 Update win32/configure/have_stdckdint.c
   f bc572e89d8 Update win32/configure/have_stdckdint.c
   f 91981bc115 Update win32/configure/have_stdckdint.c
   

   (You can also use s ("squash") instead. The difference is that s won't throw away commit messages; instead it will open a text editor with both commit messages inside and let you manually combine them. f automates this step if you intend on only keeping one of the messages anyway.)

   When you're done, save and exit your editor (and watch git "rewrite history"¹).

3. git push --force-with-lease

   This is like git push --force, but it first checks that the repository/branch you're pushing to still looks like what you think it does, i.e. that no one else has added commits to the remote branch in the meantime, which would be overwritten and lost by push -f. This is probably redundant when pushing to your own repo that no one else is working on, but I still do it.

That's it. You shouldn't need to reset anything or re-enter a commit message.

---

¹ Actually create new history and move branch labels around. The old commits are still there (at least for a week or two) and can be viewed with git reflog and even permanently saved by attaching a branch label to them.

[sisyphus]

Thanks for the help @mauke.
This approach had been suggested to me previously but, despite its obvious simplicity, I was deterred by the reliance on a text editor, having never used one.
It turns out that my Cygwin installation (which I use for git) already has vim installed, so I persevered with that and it looks to me that it has produced the desired result.
That being so, it also means I'll be able to reliably squash commits in the future - which will be quite a relief to me, and probably a few others, too ;-)