Re: [Mingw-w64-public] strerror_s problem

2012-11-04 Thread Ozkan Sezer
On 11/5/12, Kai Tietz wrote: > Hi, > > interesting to see you all guessing ;) Well, the issue is fixed on > trunk due new feature there. See mingw-w64-crt's sub-folder secapi. > (revision around rev 5346). > > It has nothing to do with header-set (at least not directly). > > Regards, > Kai I sc

Re: [Mingw-w64-public] strerror_s problem

2012-11-04 Thread Kai Tietz
Hi, interesting to see you all guessing ;) Well, the issue is fixed on trunk due new feature there. See mingw-w64-crt's sub-folder secapi. (revision around rev 5346). It has nothing to do with header-set (at least not directly). Regards, Kai ---

Re: [Mingw-w64-public] strerror_s problem

2012-11-02 Thread Ruben Van Boxem
2012/11/2 Ozkan Sezer > On Fri, Nov 2, 2012 at 11:54 AM, JonY wrote: > > On 11/2/2012 16:55, Ozkan Sezer wrote: > >> On Thu, Nov 1, 2012 at 4:54 PM, Earnie Boyd > >> wrote: > >>> Is it properly wrapped in the extern C { } when __cplusplus is > >>> defined? Is __cplusplus defined correctly? > >

Re: [Mingw-w64-public] strerror_s problem

2012-11-02 Thread Earnie Boyd
On Fri, Nov 2, 2012 at 8:51 AM, Ozkan Sezer wrote: > On 11/2/12, Earnie Boyd wrote: >> On Fri, Nov 2, 2012 at 4:55 AM, Ozkan Sezer wrote: >>> On Thu, Nov 1, 2012 at 4:54 PM, Earnie Boyd wrote: Browsing the SVN data, try including strings.h instead of string.h. See http://mingw-w64.sv

Re: [Mingw-w64-public] strerror_s problem

2012-11-02 Thread Ozkan Sezer
On 11/2/12, Earnie Boyd wrote: > On Fri, Nov 2, 2012 at 4:55 AM, Ozkan Sezer wrote: >> On Thu, Nov 1, 2012 at 4:54 PM, Earnie Boyd wrote: >>> Browsing the SVN data, try including strings.h instead of string.h. >>> See >>> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-header

Re: [Mingw-w64-public] strerror_s problem

2012-11-02 Thread Earnie Boyd
On Fri, Nov 2, 2012 at 4:55 AM, Ozkan Sezer wrote: > On Thu, Nov 1, 2012 at 4:54 PM, Earnie Boyd wrote: >> Browsing the SVN data, try including strings.h instead of string.h. >> See >> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-headers/crt/string.h?revision=1520&view=mar

Re: [Mingw-w64-public] strerror_s problem

2012-11-02 Thread JonY
On 11/2/2012 18:08, Ozkan Sezer wrote: > On Fri, Nov 2, 2012 at 11:54 AM, JonY wrote: >> On 11/2/2012 16:55, Ozkan Sezer wrote: >>> On Thu, Nov 1, 2012 at 4:54 PM, Earnie Boyd >>> wrote: Is it properly wrapped in the extern C { } when __cplusplus is defined? Is __cplusplus defined corr

Re: [Mingw-w64-public] strerror_s problem

2012-11-02 Thread Ozkan Sezer
On Fri, Nov 2, 2012 at 11:54 AM, JonY wrote: > On 11/2/2012 16:55, Ozkan Sezer wrote: >> On Thu, Nov 1, 2012 at 4:54 PM, Earnie Boyd >> wrote: >>> Is it properly wrapped in the extern C { } when __cplusplus is >>> defined? Is __cplusplus defined correctly? >>> >> >> Yes, sec_api/string_s.h does

Re: [Mingw-w64-public] strerror_s problem

2012-11-02 Thread JonY
On 11/2/2012 16:55, Ozkan Sezer wrote: > On Thu, Nov 1, 2012 at 4:54 PM, Earnie Boyd > wrote: >> Is it properly wrapped in the extern C { } when __cplusplus is >> defined? Is __cplusplus defined correctly? >> > > Yes, sec_api/string_s.h does that. > Tested in g++ 4.8.0 with trunk headers, seem

Re: [Mingw-w64-public] strerror_s problem

2012-11-02 Thread Ozkan Sezer
On Thu, Nov 1, 2012 at 4:54 PM, Earnie Boyd wrote: > Is it properly wrapped in the extern C { } when __cplusplus is > defined? Is __cplusplus defined correctly? > Yes, sec_api/string_s.h does that. On Thu, Nov 1, 2012 at 7:06 PM, Earnie Boyd wrote: > On Thu, Nov 1, 2012 at 11:27 AM, Ruben Van

Re: [Mingw-w64-public] strerror_s problem

2012-11-01 Thread Earnie Boyd
On Thu, Nov 1, 2012 at 11:27 AM, Ruben Van Boxem wrote: > I get a compile-time error. Browsing the SVN data, try including strings.h instead of string.h. See http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-headers/crt/string.h?revision=1520&view=markup&sortby=rev&pathrev=509

Re: [Mingw-w64-public] strerror_s problem

2012-11-01 Thread Ruben Van Boxem
2012/11/1 Earnie Boyd > On Thu, Nov 1, 2012 at 11:02 AM, Ruben Van Boxem wrote: > > > > The first I don't know, the second is obviously yes; the compiler takes > care > > of that. > > Compilers are programs that can contain bugs. > > > I don't think declarations are influences by extern "C" thoug

Re: [Mingw-w64-public] strerror_s problem

2012-11-01 Thread Václav Šmilauer
> when compiled as C++, gives the error of no strerror_s declared, but > when compiled as C, works fine. You could compare preprocessed source with both compilers: echo "#include" | gcc -E - echo "#include" | g++ -E - Cheers, Vaclav

Re: [Mingw-w64-public] strerror_s problem

2012-11-01 Thread Earnie Boyd
On Thu, Nov 1, 2012 at 11:02 AM, Ruben Van Boxem wrote: > > The first I don't know, the second is obviously yes; the compiler takes care > of that. Compilers are programs that can contain bugs. > I don't think declarations are influences by extern "C" though. Yes it matters. The name mangling i

Re: [Mingw-w64-public] strerror_s problem

2012-11-01 Thread Ruben Van Boxem
2012/11/1 Earnie Boyd > On Thu, Nov 1, 2012 at 10:38 AM, Ruben Van Boxem > wrote: > > Dear list, > > > > Using MinGW-w64 v2.0.7 and my 4.7.2 toolchain, I get a build failure in > LLVM > > related to strerror_s. > > It performs a CMake check to see if the function is declared, and finds > it > >

Re: [Mingw-w64-public] strerror_s problem

2012-11-01 Thread Earnie Boyd
On Thu, Nov 1, 2012 at 10:38 AM, Ruben Van Boxem wrote: > Dear list, > > Using MinGW-w64 v2.0.7 and my 4.7.2 toolchain, I get a build failure in LLVM > related to strerror_s. > It performs a CMake check to see if the function is declared, and finds it > (I configured the headers with --enable-secu

[Mingw-w64-public] strerror_s problem

2012-11-01 Thread Ruben Van Boxem
Dear list, Using MinGW-w64 v2.0.7 and my 4.7.2 toolchain, I get a build failure in LLVM related to strerror_s. It performs a CMake check to see if the function is declared, and finds it (I configured the headers with --enable-secure-api as always) so it defines the config.h guard macro. When the