#1673 missing declaration of _vscwprintf

WSL
open
None
Bug
none
Known_Feature
False
2016-01-21
2012-09-29
alexbolz
No

_vscwprintf is not declared in wchar.h. It is declared in stdio.h (line 569).

Discussion

  • Earnie Boyd

    Earnie Boyd - 2012-09-30
    • milestone: --> Feature_in_WSL_4.0
    • priority: 5 --> 7
    • assigned_to: nobody --> earnie
     
  • Earnie Boyd

    Earnie Boyd - 2012-09-30

    This will be included in the up and coming 4.0 release.

     
  • Earnie Boyd

    Earnie Boyd - 2012-11-10
    • labels: 104601 --> WSL (Windows System Libraries)
    • status: open --> closed-fixed
     
  • Earnie Boyd

    Earnie Boyd - 2013-01-18
    • category: --> Feature_in_WSL_4.0
    • milestone: Feature_in_WSL_4.0 --> WSL
     
  • Earnie Boyd

    Earnie Boyd - 2013-02-16
    • labels: WSL (Windows System Libraries) --> release notes
    • status: closed-fixed --> closed
    • type: --> Bug
    • resolution: --> fixed
    • patch_attached: --> False
     
  • Earnie Boyd

    Earnie Boyd - 2013-02-25
    • labels: release notes -->
     
  • Earnie Boyd

    Earnie Boyd - 2013-02-25

    Notes added to NEWS file.

     
  • Ryan Prichard

    Ryan Prichard - 2016-01-20

    I am hitting this bug with a brand new MinGW installation that I made using mingw-get.exe. _vscwprintf is declared in stdio.h but not wchar.h, so the order of includes matters.

    The relevant wchar.h header seems to be distributed in the mingwrt package? I have version 3.21 of that package, which is the latest version according to mingw-get.exe, but there's a newer 3.21.1 version I saw mentioned in this mailing list post, http://sourceforge.net/p/mingw/mailman/message/34288737/. That post points at a SourceForge directory, which has instructions at the bottom suggesting I use mingw-get.exe to install packages, but how? In any case, I downloaded the 3.21.1-dev package and looked at the wchar.h inside -- it has the same bug. Curiously, I also see 4.x versions of mingwrt dating back to 2013.

    My current theory is that the fix for this bug was made on a 4.x branch, which isn't the current branch for some reason. Something didn't pan out?

    I suppose this bug could be reopened and fixed on the 3.x branch. Or, I could open a new bug.

    I'm also still wondering how to install a package version that mingw-get doesn't know about, but that's an aside.

     
    • Keith Marshall

      Keith Marshall - 2016-01-20

      I am hitting this bug with a brand new MinGW installation that I made using mingw-get.exe. _vscwprintf is declared in stdio.h but not wchar.h, so the order of includes matters.

      This is a prime example of why duplication of content in two (or more) header files is such fundamentally bad software engineering, and why wrapping such duplicated content in repeat declaration guards, (except in the case of redefinitions which the compiler would itself reject, even if consistent), is also ill advised. This is not to say that it is fundamentally wrong to support declarations via a choice of headers, but where such choices are to be supported, the correctly engineered solution is to declare and/or define the respective entities in one location, and to selectively include the common source into all dependent headers; to do otherwise invites inconsistencies, such as we see here.

      Curiously, I also see 4.x versions of mingwrt dating back to 2013.

      An experiment which went horribly wrong ... a TARFUBAR which I felt obliged to remove from formal distribution.

      My current theory is that the fix for this bug was made on a 4.x branch,

      No; it may have been kludged around, but no properly engineered solution was ever implemented.

      I suppose this bug could be reopened and fixed on the 3.x branch. Or, I could open a new bug.

      FWIW, I'm already working on a correctly engineered refactoring of the <stdio.h> vs. <wchar.h> duplicate content, for the next release of 3.x; it will happen, but I guess we could reopen this bug in the meantime.

      I'm also still wondering how to install a package version that mingw-get doesn't know about, but that's an aside.

      You can simply unpack the newer tarball, over the top of what mingw-get installed, (but then, your installation manifests no longer reflect reality). Alternatively, you can manually update your own local copy of the XML catalogue files in $MINGW_ROOT/var/lib/mingw-get/data, (either directly, or via a clone of the mingw-dist git repository), so your copy of mingw-get does know. In any case, this omission of mingwrt-3.21.1 was an oversight; it is now fixed.

       
  • Keith Marshall

    Keith Marshall - 2016-01-20
    • status: closed --> open
    • assigned_to: Earnie Boyd --> Keith Marshall
    • Resolution: fixed --> none
    • Category: Feature_in_WSL_4.0 --> Known_Feature
     
  • Ryan Prichard

    Ryan Prichard - 2016-01-21

    Thanks for working on this.

    An experiment which went horribly wrong ... a TARFUBAR which I felt obliged to remove from formal distribution.

    FWIW, I noticed that Cygwin has a mingw-runtime package, and Cygwin's setup.exe can choose either 3.20-1 or 4.0-1. I think it defaults to 4.0-1; in any case, that's the version I currently have installed. That might be a reason to keep the 4.0 package around somewhere. It also looks like Cygwin's mingw-runtime package is orphaned: https://cygwin.com/cygwin-pkg-maint

     
    Last edit: Ryan Prichard 2016-01-21
    • Keith Marshall

      Keith Marshall - 2016-01-21

      FWIW, I noticed that Cygwin has a mingw-runtime package, and Cygwin's setup.exe can choose either 3.20-1 or 4.0-1. I think it defaults to 4.0-1...

      Cygwin is completely independent from MinGW.org; I've no idea what, if any, relationship their 4.0-1 package may have with our (now defunct) WSL-4. In any case, our 4.x code will remain in git, but 3.21.1 is our current release. Eventually, I will merge whatever may be salvageable from 4.x on to 3.x, and bump the version to 5.

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks