Hi Alex, I replied to this on Monday, 2/1. I'm copy-pasting the same reply below, and this time I've put your email address on the To: line explicitly.
I looked into this, and I can repro. I think this is a bug, and I don't think any of the recent Windows fixes addresses it. Although "make sure you don't include stdint.h" is a viable workaround, it's not best for us to put artificial constraints on our users. Modern versions of Visual Studio do ship a stdint.h header, which negates the need for the winstdint.h compatibility shim. I think a stdint.h is available in at least Visual Studio 2010 and later. One potential fix would be to remove winstdint.h, transition completely to use of stdint.h, and declare that our supported build tool chain is Visual Studio 2010 and later. I'm reluctant to do that on the 3.4 maintenance line though on grounds of backwards-compatibility. Another approach could be conditional compilation to include either stdint.h or winstdint.h based on choice. I see a flag named HAVE_STDINT_H mentioned in winconfig.h, so it seems like someone was thinking of this. However, the flag is unused from what I can tell, so it wouldn't actually help for a project to define it before compiling. We'd need to make code changes to support it. On a side note, there are numerous other compilation warnings on Windows, unrelated to stdint.h. Alex, do you think you are experiencing a bug from the stdint.h warnings? I'm trying to decide if we should file a single JIRA for a mass cleanup of warnings, or if the stdint.h warnings you reported are somehow more critical than the rest and need tracking in their own separate issue. --Chris Nauroth On 2/5/16, 3:53 PM, "Alex Clemmer" <clemmer.alexan...@gmail.com> wrote: >Hey folks. Not sure if someone responded and I just didn't see it >because I'm not on the dev@ list, or if there just isn't that much >interest in these questions. Can someone please at least confirm that >I've not screwed up sending this message somehow? > >On Thu, Jan 28, 2016 at 3:24 PM, Alex Clemmer ><clemmer.alexan...@gmail.com> wrote: >> I should note also that I have looked closely at the issue tracker >> (e.g., https://issues.apache.org/jira/browse/ZOOKEEPER-1953) and >> various related changesets (e.g., >> http://svn.apache.org/viewvc?view=revision&revision=1148116) but being >> young and raised mostly on git I could not find a discussion of why >> this file is the way that it is. So it could well be that I am simply >> missing simple guidance like "make sure not to include `stdint.h` in >> any project consuming the ZK C client library." >> >> On Thu, Jan 28, 2016 at 3:18 PM, Alex Clemmer >> <clemmer.alexan...@gmail.com> wrote: >>> Hey folks. >>> >>> We (the Apache Mesos project) are building against the ZK C client on >>> Windows, with VS 2015 (and MSVC v.1900). When we attempt a vanilla >>> build, including both `zookeeper.h` and `stdint.h` causes the compiler >>> to complain that we're re-typedef'ing a few types (such as >>> `int_fast8_t` with different underlying types) in the file, >>> `winstdint.h`. >>> >>> I have scoured the Internet to see if I'm missing a -D flag somewhere, >>> but it does not appear that this is the case. >>> >>> The comments in this file state that it's meant to provide a >>> C9X-compliant version of `stdint.h` for Windows, but for later >>> versions of MSVC some of the definitions seem to be redundant or >>> different. (For example, on VS 2013 `int_fast16_t` is redefined with a >>> different underlying type.) >>> >>> My question for you all is: am I missing something obvious, or should >>> I submit a bug and a patch to resolve this issue for you? >>> >>> >>> -- >>> Alex >>> >>> Theory is the first term in the Taylor series of practice. -- Thomas M >>> Cover (1992) >> >> >> >> -- >> Alex >> >> Theory is the first term in the Taylor series of practice. -- Thomas M >> Cover (1992) > > > >-- >Alex > >Theory is the first term in the Taylor series of practice. -- Thomas M >Cover (1992) >
