#2280 Adding functions missing from msvcrt.dll

[balthisar]

Good day. My project requires the use of Windows' _vscprintf_p_l and _vsprintf_p in order to support positional parameters in the printf family. We currently have a workaround involving building our own import library for functions defined in msvcrt.dll that are not present in libmsvcrt.a as distributed by MinGW.

Our team is happy to research the how-to and submit a patch, but looking at a similar issue (https://sourceforge.net/p/mingw/bugs/2274/) as well as my unfamiliarity with the total scope of MinGW's goals, I'm uncertain as to whether this would or would not be a welcome change.

For the example the referenced dicussion indicates only compatability for Windows 95 (possibly pre-Windows 95). I've established that _vscprintf_p_l (https://msdn.microsoft.com/en-us/library/ms175786(v=vs.80).aspx) and _vsprintf_p (https://msdn.microsoft.com/en-us/library/c8c2ax31(v=vs.80).aspx) are in Windows standard library at least as far back as 2005, and both are currently present in the msvcrt.dll on the Windows systems I've examined.

My understanding (which may be wrong) is that msvcrt.dll API is static since MSVC 4.2, thus these Windows functions date back to the oldest platforms that MinGW supports.

Targetting these two functions (rather than the preferred _vscprintf_p) was done specifically to use msvcrt.dll rather than one of the newer RTLs.

Are these references and the presence of the functions in msvcrt.dll enough to satisfy MinGW's cleanroom requirements?

Our project would prefer to support MinGW "natively" without our current, custom import library, and we're willing to do the work if it's welcome. On the other hand if the proposal is a complete non-starter then it would be nice to know this now before we start diving into MinGW's internals.

Thanks.

[Keith Marshall]

Patches are always welcome, when they are based on freely accessible documentation, such as the MSDN references for _vcprintf_p(); (however, the two you cite, for _vscprintf_p_l() and _vsprintf_p(), yield HTTP-404 "Page not found" exceptions for me). FWIW, the principal issue with [#2274] was that the poster was unable to produce an adequate patch, based on adequate reference documentation sources; had such a patch been forthcoming, it would have been favourably considered.

My understanding (which may be wrong) is that msvcrt.dll API is static since MSVC 4.2, thus these Windows functions date back to the oldest platforms that MinGW supports.

No, you are wrong here; MSVCRT.DLL is a system level component library, which has evolved with each new version of windows; although _vcprintf_p() and friends may have first appeared in Visual Studio's MSVCR80.DLL, these weren't backported into MSVCRT.DLL until its Vista incarnation ... see the attached msvcrt-xref.pdf, (a work in progress), for reference.

At some point, I'd like to fold the attached msvcrt.def.in file, from which that PDF document is generated, into mingwrt, as the primary source for its libmsvcrt.a and libmsvcrN.a import libraries, (so the symbols listed therin will be included in those import libraries), but that needs care to avoid compromising the dlsym() fallback hooks for certain of those functions, which are implemented in libmingwex.a.

So, if you would like to submit a patch, and you base it entirely on suitable reference documentation, we would certainly consider it favourably; (it should include the appropriate msvcrt.def.in symbol references, function prototypes in appropriate header files, with appropriate windows version specific exposure guards, all in patch format, and appropriate ChangeLog entries, in the patch files, but not in patch format). However, you should be advised that I have some substantial <stdio.h> and <wchar.h> changes in my working sandbox, so you may wish to wait until I get them pushed to the public git repository, before you begin formulating your own patches to those files.

[Keith Marshall]

As an afterthought: the "%n$..." feature you are seeking to exploit is standard in POSIX.1-2008's printf(), (as an extension to ISO-C). Our alternative (to Microsoft's) printf() implementation, in libmingwex.a doesn't support that extension at present, but it may be prudent to explore the possibility of modifying the pformat.c core module of that implementation to do so. That would surely offer a significantly more backwardly compatible, and significantly more portable alternative to nasty Microsoft specific (i.e. non-standard beyond the confines of windows) APIs to support this feature.

[balthisar]

Thank you for the considerable explanation. Yes, the standard POSIX printf is exactly what we're chasing, and it would be nice to simply use printf. I'll try to take a look at pformat.c for possibilities this week, and then our project would only need ugly workarounds for MSVC builds.

If we patch pformat.c, though, aside from versioning exposure guards would you want to see this tied to an existing or new define? That is, this would change the printf behavior and possibly cause regressions for code that might coincidentally already have sequences such as, e.g., %2$s.

[Keith Marshall]

When I originally wrote our alternative pformat.c based implementation of printf() and friends, my reference source was POSIX.1-2004, in which "%n$" and "*m$" argument indexing was designated as an XSI (extended systems interface) optional feature; at the time, we decided that we would not support such optional extensions. However, I do note that POSIX.1-2008 has moved this feature, (along with the use of the ' digit grouping flag), from XSI to the base specification. Thus, it would seem prudent to revise pformat.c to support these now standard POSIX.1 features.

FWIW, I've reviewed pformat.c myself, and I think I can see a strategem for implementing at least the "%n$" and "*m$" aspects fairly easily. I'm not concerned that this would introduce any backward compatibility issues: the existing implementation would simply have choked on the $ symbol within any conversion spec, and would have immediately backtracked to the introductory % symbol, to emit the entire spec as literal text, so any existing application attempting to use this feature would have behaved strangely anyway; furthermore, POSIX itself declares that improper use of the feature leads to undefined behaviour.

[Keith Marshall]

As a first step, I've committed [5761c7] and [f5f10c], which initially import this into the mingwrt tree, then adapt its msvcrt.def.in as a replacement for the present long outdated version. This should effectively make libmsvcrt.a export symbol-complete, at least to the level of Win7 release compatibility. (If you know of any further symbols, which should be included for compatibility with later windows versions, please provide pexports symbol listings for the respective platform versions of msvcrt.dll).

As follow-up, I plan to update <stdio.h> to include prototypes for Microsoft's _printf_p() and _printf_p_l() variants, (and perhaps also their _printf_s() and _printf_s_l() counterparts ... all of which seem kind of pointless, to me). I also have an updated, but not yet committed, version of pformat.c, (apparently working but not rigorously tested), which delivers the POSIX.1-2008 "%n$" and "*m$" formatting capability directly within our implementation of printf() and friends; define _XOPEN_SOURCE, (or _POSIX_C_SOURCE), at the start of your source files, to ensure you use it.

[Keith Marshall]

I've now committed [0d2e72], adding Microsoft's _printf_p() and _printf_p_l() family of function prototypes to <stdio.h>, (subject to activation of the __MSVCR80_DLL or _WIN32_WINNT_VISTA feature tests), and [5063cc], which adds support for positional argument addressing in our own printf() function family, (subject to _XOPEN_SOURCE or _POSIX_C_SOURCE feature tests).

Please test.

[Keith Marshall]

The new features described above have now been incorporated into the recently published mingwrt-3.22 release; (be sure to install the mingwrt-3.22.1 update, to avoid the inadvertently introduced 3.22 specific regression, identified as issue [#2309]).

This release now provides support for all POSIX.1-2008 printf() features, with the exception of the formerly XSI thousands digit grouping facility, which is to be addressed under ticket [#2310].