Hi Devs,
I found out that .Net apparently doesn't use "snprintf" but has a similar function named "sprintf_s". (A couple of recent patches change "sprintfs" to "snprintfs" leading to compile errors in .Net). I'm thinking of just putting the following in s_main.c and s_file.c:
#ifdef MSW #define snprinf sprintf_s #endif
My question: will this break cygwin or some other non-microsoft compiler for Windows?
thanks Miller
Miller Puckette wrote:
Hi Devs,
I found out that .Net apparently doesn't use "snprintf" but has a similar function named "sprintf_s". (A couple of recent patches change "sprintfs" to "snprintfs" leading to compile errors in .Net). I'm thinking of just putting the following in s_main.c and s_file.c:
#ifdef MSW #define snprinf sprintf_s #endif
My question: will this break cygwin or some other non-microsoft compiler for Windows?
Probably. I did it like this in tcpclient.c, which compiles OK in pd-extended: #ifdef _MSC_VER #define snprintf sprintf_s #endif
_MSC_VER is only defined for the microsoft compiler.
Martin
Martin Peach wrote:
Probably. I did it like this in tcpclient.c, which compiles OK in pd-extended: #ifdef _MSC_VER #define snprintf sprintf_s #endif
_MSC_VER is only defined for the microsoft compiler.
Yeah, that sounds like a better check than the custom MSW define.
If you wanted to take it a step further, it would be pretty trivial to add a check for snprintf to the configure script. That way, when building Pd for .Net or whatever (which I assume uses some other build system), the appropriate HAVE_SNPRINTF define will not be present.
So, the source that needs this would look like this ... preferably in some common non-installed header file so stuff like this can be put in a common place and not replicated in lots of source files ...
#include "config.h"
#ifndef HAVE_SNPRINTF /* Assume very silly non-standard windows version */ #define snprintf sprintf_s #endif
Patch against current CVS HEAD for the configure script part would be ...
Index: configure.in =================================================================== RCS file: /cvsroot/pure-data/pd/src/configure.in,v retrieving revision 1.26 diff -u -r1.26 configure.in --- configure.in 28 Dec 2007 03:43:02 -0000 1.26 +++ configure.in 16 Jan 2008 17:51:30 -0000 @@ -1,6 +1,8 @@ dnl Process this file with autoconf to produce a configure script. AC_INIT(d_arithmetic.c)
+AC_CONFIG_HEADER(config.h) + AC_SUBST(alsa, yes) AC_SUBST(jack, no) AC_SUBST(portaudio, no) @@ -69,7 +71,7 @@ AC_PROG_GCC_TRADITIONAL AC_TYPE_SIGNAL AC_FUNC_VPRINTF -AC_CHECK_FUNCS(gettimeofday select socket strerror) +AC_CHECK_FUNCS(gettimeofday select socket strerror snprintf) AC_FUNC_ALLOCA
dnl Checks for libraries.
Also, be sure to run "autoheader" so that config.h.in gets updated to include the new HAVE_SNPRINTF define.
-- Russell Bryant
Quoting Russell Bryant russell@russellbryant.net:
Yeah, that sounds like a better check than the custom MSW define.
If you wanted to take it a step further, it would be pretty trivial to add a check for snprintf to the configure script. That way, when building Pd for .Net or whatever (which I assume uses some other build system), the appropriate HAVE_SNPRINTF define will not be present.
the only problem with that i see is, that when building with .NET you usually do not do configure (once you have installed all the (gnu)tools to be able to run configure, you probably will want to use gcc instead of the .NET compiler)
one solution (which i use and which i don't really like) to this is to have a non-generated configMSW.h.
btw, is there a way to specify at compile-time which file to include? something like:
#define CONFIG_H_FILE "config.h"
#ifdef CONFIG_H_FILE # include CONFIG_H_FILE #endif
(this won't work, but is there something similar?)
fgmasd.r IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
zmoelnig@iem.at wrote:
btw, is there a way to specify at compile-time which file to include? something like:
#define CONFIG_H_FILE "config.h"
#ifdef CONFIG_H_FILE # include CONFIG_H_FILE #endif
(this won't work, but is there something similar?)
The only thing I can think of is just something like this, assuming ahead of time you know the defined set of headers you might potentially include.
#if defined(INCLUDE_CONFIG_H) #include "config.h" #elif defined(INCLUDE_CONFIGMSW_H) #include "configMSW.h" #endif
In the case of using a configure script, you can certainly dynamically generate content for a generated header file.
MY_HEADER=something.h
AH_TOP( #include "${MY_HEADER}" )
-- Russell Bryant
On Jan 16, 2008, at 1:26 PM, zmoelnig@iem.at wrote:
Quoting Russell Bryant russell@russellbryant.net:
Yeah, that sounds like a better check than the custom MSW define.
If you wanted to take it a step further, it would be pretty trivial to add a check for snprintf to the configure script. That way, when building Pd for .Net or whatever (which I assume uses some other build system), the appropriate HAVE_SNPRINTF define will not be present.
the only problem with that i see is, that when building with .NET you usually do not do configure (once you have installed all the (gnu)tools to be able to run configure, you probably will want to use gcc instead of the .NET compiler)
Who's using the MS compilers? We would save ourselves a lot of effort and make the code cleaner if we used gcc/autoconf on all platforms. According to Thomas Grill, gcc's code is comparable in terms of optimization to MSVC.
.hc
one solution (which i use and which i don't really like) to this is to have a non-generated configMSW.h.
btw, is there a way to specify at compile-time which file to include? something like:
#define CONFIG_H_FILE "config.h"
#ifdef CONFIG_H_FILE # include CONFIG_H_FILE #endif
(this won't work, but is there something similar?)
fgmasd.r IOhannes
This message was sent using IMP, the Internet Messaging Program.
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
Am 16.01.2008 um 23:00 schrieb Hans-Christoph Steiner:
Who's using the MS compilers? We would save ourselves a lot of effort and make the code cleaner if we used gcc/autoconf on all platforms. According to Thomas Grill, gcc's code is comparable in terms of optimization to MSVC.
To be fair that was an old version of MSVC compared to the latest version of gcc. To my experience it's much easier to set up and debug a project using MSVC than with gcc on Windows, so i personally would not want to do without MSVC. It's not that hard to write code in a way that it works with all current and common compilers.
gr~~~
Well, I am, for one... but I think it would be foolish to drop support for the 'official' windows compiler.
OTOH, I like the idea of just supplying a spoofed config.h - comes in at just the level of irony that's fitting in the situation.
cheers Miller
On Wed, Jan 16, 2008 at 05:00:11PM -0500, Hans-Christoph Steiner wrote:
On Jan 16, 2008, at 1:26 PM, zmoelnig@iem.at wrote:
Quoting Russell Bryant russell@russellbryant.net:
Yeah, that sounds like a better check than the custom MSW define.
If you wanted to take it a step further, it would be pretty trivial to add a check for snprintf to the configure script. That way, when building Pd for .Net or whatever (which I assume uses some other build system), the appropriate HAVE_SNPRINTF define will not be present.
the only problem with that i see is, that when building with .NET you usually do not do configure (once you have installed all the (gnu)tools to be able to run configure, you probably will want to use gcc instead of the .NET compiler)
Who's using the MS compilers? We would save ourselves a lot of effort and make the code cleaner if we used gcc/autoconf on all platforms. According to Thomas Grill, gcc's code is comparable in terms of optimization to MSVC.
.hc
one solution (which i use and which i don't really like) to this is to have a non-generated configMSW.h.
btw, is there a way to specify at compile-time which file to include? something like:
#define CONFIG_H_FILE "config.h"
#ifdef CONFIG_H_FILE # include CONFIG_H_FILE #endif
(this won't work, but is there something similar?)
fgmasd.r IOhannes
This message was sent using IMP, the Internet Messaging Program.
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
http://at.or.at/hans/
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Miller Puckette wrote:
OTOH, I like the idea of just supplying a spoofed config.h - comes in at just the level of irony that's fitting in the situation.
That makes the most sense to me. I guess all of the source files could include "config.h", and config.h could be ...
#ifdef _MSC_VER #include "config_windows.h" #else #include "config_autoconf.h" #endif
and then change config.h.in to be config_autoconf.h.in, and change AC_CONFIG_HEADERS() in configure.in to point to config_autoconf.h.in, as well.
That way, you can have a hand made config_windows.h that include the logic for working with a non-GNU build environment, and we can still handle things automagically for other platforms.
-- Russell Bryant
Sounds right. I'll put that on the 0.42 dolist :)
M
On Wed, Jan 16, 2008 at 05:33:26PM -0600, Russell Bryant wrote:
Miller Puckette wrote:
OTOH, I like the idea of just supplying a spoofed config.h - comes in at just the level of irony that's fitting in the situation.
That makes the most sense to me. I guess all of the source files could include "config.h", and config.h could be ...
#ifdef _MSC_VER #include "config_windows.h" #else #include "config_autoconf.h" #endif
and then change config.h.in to be config_autoconf.h.in, and change AC_CONFIG_HEADERS() in configure.in to point to config_autoconf.h.in, as well.
That way, you can have a hand made config_windows.h that include the logic for working with a non-GNU build environment, and we can still handle things automagically for other platforms.
-- Russell Bryant
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hi Miller,
Miller Puckette a écrit :
Hi Devs,
I found out that .Net apparently doesn't use "snprintf" but has a similar function named "sprintf_s". (A couple of recent patches change "sprintfs" to "snprintfs" leading to compile errors in .Net). I'm thinking of just putting the following in s_main.c and s_file.c:
#ifdef MSW #define snprinf sprintf_s #endif
My question: will this break cygwin or some other non-microsoft compiler for Windows?
thanks Miller
this doesn't break compilation on cygwin shell (with -mno-cygwin flag)
Hmm, so perhaps I really should be using MSW and not _MSC_VER in the code. As it is now, cygwin will encounter unaliased snprinf() calls, which might not compile if sprintf_s is provided there instead.
M
On Fri, Jan 18, 2008 at 06:02:42PM +0100, Patrice Colet wrote:
Hi Miller,
Miller Puckette a ?crit :
Hi Devs,
I found out that .Net apparently doesn't use "snprintf" but has a similar function named "sprintf_s". (A couple of recent patches change "sprintfs" to "snprintfs" leading to compile errors in .Net). I'm thinking of just putting the following in s_main.c and s_file.c:
#ifdef MSW #define snprinf sprintf_s #endif
My question: will this break cygwin or some other non-microsoft compiler for Windows?
thanks Miller
this doesn't break compilation on cygwin shell (with -mno-cygwin flag)
Miller Puckette wrote:
To: Patrice Colet pat@mamalala.org CC: pd-dev@iem.at Subject: Re: [PD-dev] snprintf vs. sprintf_s? Date: Fri, 18 Jan 2008 09:51:04 -0800
Hmm, so perhaps I really should be using MSW and not _MSC_VER in the code. As it is now, cygwin will encounter unaliased snprinf() calls, which might not compile if sprintf_s is provided there instead.
Cygwin gcc compiles snprintf() without errors here. I think sprintf_s is unique to Microsoft.
Martin
M
On Fri, Jan 18, 2008 at 06:02:42PM +0100, Patrice Colet wrote:
Hi Miller,
Miller Puckette a ?crit :
Hi Devs,
I found out that .Net apparently doesn't use "snprintf" but has a
similar
function named "sprintf_s". (A couple of recent patches change
"sprintfs"
to "snprintfs" leading to compile errors in .Net). I'm thinking of
just
putting the following in s_main.c and s_file.c:
#ifdef MSW #define snprinf sprintf_s #endif
My question: will this break cygwin or some other non-microsoft
compiler
for Windows?
thanks Miller
this doesn't break compilation on cygwin shell (with -mno-cygwin flag)
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Jan 18, 2008, at 1:44 PM, Martin Peach wrote:
Miller Puckette wrote:
To: Patrice Colet pat@mamalala.org CC: pd-dev@iem.at Subject: Re: [PD-dev] snprintf vs. sprintf_s? Date: Fri, 18 Jan 2008 09:51:04 -0800
Hmm, so perhaps I really should be using MSW and not _MSC_VER in the code. As it is now, cygwin will encounter unaliased snprinf() calls, which might not compile if sprintf_s is provided there instead.
Cygwin gcc compiles snprintf() without errors here. I think sprintf_s is unique to Microsoft.
Yeah, cygwin is a complete POSIX layer for Windows, so it provides snprintf(). And the MinGW runtime has provided a sane snprintf(). _MSC_VER is the best bet for sprintf_s, keep the MS weirdness in MS land.
.hc
Martin
M
On Fri, Jan 18, 2008 at 06:02:42PM +0100, Patrice Colet wrote:
Hi Miller,
Miller Puckette a ?crit :
Hi Devs,
I found out that .Net apparently doesn't use "snprintf" but has a
similar
function named "sprintf_s". (A couple of recent patches change
"sprintfs"
to "snprintfs" leading to compile errors in .Net). I'm thinking of
just
putting the following in s_main.c and s_file.c:
#ifdef MSW #define snprinf sprintf_s #endif
My question: will this break cygwin or some other non-microsoft
compiler
for Windows?
thanks Miller
this doesn't break compilation on cygwin shell (with -mno-cygwin flag)
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
-
Hans-Christoph Steiner -
Martin Peach -
Miller Puckette -
Patrice Colet -
Russell Bryant -
Thomas Grill -
zmoelnig＠iem.at