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.
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.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 thedlsym()
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 inpatch
format, and appropriate ChangeLog entries, in the patch files, but not inpatch
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 publicgit
repository, before you begin formulating your own patches to those files.Related
Issues:
#2274Last edit: Keith Marshall 2016-01-22
As an afterthought: the
"%n$..."
feature you are seeking to exploit is standard in POSIX.1-2008'sprintf()
, (as an extension to ISO-C). Our alternative (to Microsoft's)printf()
implementation, inlibmingwex.a
doesn't support that extension at present, but it may be prudent to explore the possibility of modifying thepformat.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.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 atpformat.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
.When I originally wrote our alternative
pformat.c
based implementation ofprintf()
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 revisepformat.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.As a first step, I've committed [5761c7] and [f5f10c], which initially import this into the
mingwrt
tree, then adapt itsmsvcrt.def.in
as a replacement for the present long outdated version. This should effectively makelibmsvcrt.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 providepexports
symbol listings for the respective platform versions ofmsvcrt.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 ofpformat.c
, (apparently working but not rigorously tested), which delivers the POSIX.1-2008"%n$"
and"*m$"
formatting capability directly within our implementation ofprintf()
and friends; define_XOPEN_SOURCE
, (or_POSIX_C_SOURCE
), at the start of your source files, to ensure you use it.Related
Commit: [5761c7]
Commit: [f5f10c]
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 ownprintf()
function family, (subject to_XOPEN_SOURCE
or_POSIX_C_SOURCE
feature tests).Please test.
Related
Commit: [0d2e72]
Commit: [5063cc]
The new features described above have now been incorporated into the recently published
mingwrt-3.22
release; (be sure to install themingwrt-3.22.1
update, to avoid the inadvertently introduced3.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].Related
Issues:
#2309Issues:
#2310