[RFC] vim-patch:7.4.490

[fwalch]

Problem:    Cannot specify the buffer to use for "do" and "dp", making them
        useless for three-way diff.
Solution:   Use the count as the buffer number. (James McCoy)

https://code.google.com/p/vim/source/detail?r=v7-4-490

Original patch (proto, version.c changes removed for brevity):

diff --git a/src/nvim/diff.c b/src/nvim/diff.c
--- a/src/nvim/diff.c
+++ b/src/nvim/diff.c
@@ -2107,12 +2107,20 @@ diff_infold(wp, lnum)
  * "dp" and "do" commands.
  */
     void
-nv_diffgetput(put)
+nv_diffgetput(put, count)
     int        put;
+    long   count;
 {
     exarg_T    ea;
+    char_u buf[30];

-    ea.arg = (char_u *)"";
+    if (count == 0)
+   ea.arg = (char_u *)"";
+    else
+    {
+   vim_snprintf((char *)buf, 30, "%ld", count);
+   ea.arg = buf;
+    }
     if (put)
    ea.cmdidx = CMD_diffput;
     else
diff --git a/src/nvim/normal.c b/src/nvim/normal.c
--- a/src/nvim/normal.c
+++ b/src/nvim/normal.c
@@ -9284,7 +9284,7 @@ nv_put(cap)
    if (cap->oap->op_type == OP_DELETE && cap->cmdchar == 'p')
    {
        clearop(cap->oap);
-       nv_diffgetput(TRUE);
+       nv_diffgetput(TRUE, cap->opcount);
    }
    else
 #endif
@@ -9407,7 +9407,7 @@ nv_open(cap)
     if (cap->oap->op_type == OP_DELETE && cap->cmdchar == 'o')
     {
    clearop(cap->oap);
-   nv_diffgetput(FALSE);
+   nv_diffgetput(FALSE, cap->opcount);
     }
     else
 #endif

[fwalch]

If there is no @param at all, we get a Doxygen warning that docu is missing for this parameter, which is IMO more useful than an empty parameter description.

[justinmk]

👍 Empty param descriptions, or descriptions that meaninglessly restate the parameter name (e.g. @param put The thing to put) are useless noise and should be avoided.

[justinmk]

I believe this should use portable format specifier PRId64 instead of %ld. See 28bac30 for example. cc @elmart Is PRId64 correct for size_t?

[fwalch]

Should it be %zd (http://stackoverflow.com/questions/2524611/how-to-print-size-t-variable-portably)?

man 3 printf:

z      A  following integer conversion corresponds to a size_t or ssize_t argument, or a following n conversion corresponds to a pointer to a size_t
        argument.

[justinmk]

Hoping MSVC has added that since 2010. @jasonwilliams200OK @aktau @equalsraf Any idea about that?

[equalsraf]

I won't be able to test this with a real compiler before next week - but based on this it seems it is not supported in VS2013. The closest I found was %Id.

[justinmk]

Thanks for that link.

This link claims %z is C99. Since size_t is unsigned perhaps we should use %zu.

This MSDN page says (click "expand all" and search for C99):

The printf and scanf families of functions now support the new C99 format string improvements.

Perhaps someone with VS 2015 CTP can check the inttypes.h (or equivalent) header.

[aktau]

This link claims %z is C99. Since size_t is unsigned perhaps we should use %zu.

I always use %zu for size_t, fwiw.

[ghost]

I extracted inttypes.h from VS2015 latest preview and here it is: https://gist.github.com/jasonwilliams200OK/45d0b5f4fd2b087e0b3a

And here is the one that shipped with VS2013 Update 4: https://gist.github.com/jasonwilliams200OK/2a0ce733923fbcf86c64 (don't know why they say complex.h in comment in 2013 version?)

Besides the following, all C99 and C11 standard headers are included in CRT (VS2015):

C11 - <stdalign.h>
C11 - <stdatomic.h>
C11 - <stdnoreturn.h>
C99 - <tgmath.h>
C11 - <threads.h>

The only C11 header that is included is <uchar.h>, which means STL (person) was not kidding in this blog's comment:

My coworker Pat Brenner is actually adding <uchar.h> to the CRT right now, and I've given him to add to the STL. Unless a meteor strikes, this will get into VS14 RTM.

(it was later, they changed the name to VS2015 ... and yes meteor did not strike!)

So now we even know what date uchar.h got included in their CRT! :)

BTW, that list in blog I linked above is now superseded by this one.

PS Matter of time before we would be @'ing VC guys directly on GH..

[ghost]

To answer your earlier question @justinmk, I tested with this code (taken from SO link by @fwalch):

// test.c

#include <stdio.h>
#include <BaseTsd.h>

int main()
{
    size_t x = 1;
    SSIZE_T y = 2;
    printf("%zu\n", x);  // prints as unsigned decimal
    printf("%zx\n", x);  // prints as hex
    printf("%zd\n", y);  // prints as signed decimal
    return 0;
}

on both VS2013 and VS2015.

VS2015 generated binary outputs:

1
1
2

while the one generated by VS2013 says:

zu
zx
zd

Note: ssize_t is a POSIX extension and SSIZE_T is similar thing in Windows Data Types, hence I added <BaseTsd.h> reference

Let me know if there is anything else you want me to confirm.

[justinmk]

@jasonwilliams200OK that is good news, thanks for the followup!

[fwalch]

Changed to %zu, thanks @jasonwilliams200OK!