On Wed, Feb 23, 2011 at 6:26 PM, Brent Fulgham <bfulg...@gmail.com> wrote: > Thanks for making these fixes -- they look great! > > I have one small suggestion regarding your update to "composite.c"; > while MSVC does not provide an "snprintf" symbol, it does provide > "_snprintf".
The documentation states that it is deprecated and that it does not behave as snprintf: "The _snprintf function formats and stores count or fewer characters in buffer, and appends a terminating null character if the formatted string length is strictly less than count characters." (from http://msdn.microsoft.com/en-us/library/2ts7cx93%28v=vs.80%29.aspx ) snprintf, instead, guarantees the output sting to always be nul-terminated. The code can be safely and easily rewritten to avoid snprintf altogether, so I modified it this way. If the previous snprintf-based logic is to be preserved, on WIN32 we should define the snprintf function to _snprintf and then nul-terminate the string. > > To be consistent with other ports, I would propose the following change: > > bfulgham@bfulgham3 ~/requirements_sources/cairo/git/pixman/test > $ git diff composite.c > diff --git a/test/composite.c b/test/composite.c > index e14f954..b4bde09 100644 > --- a/test/composite.c > +++ b/test/composite.c > @@ -36,6 +36,10 @@ typedef struct format_t format_t; > typedef struct image_t image_t; > typedef struct operator_t operator_t; > > +#ifdef _WIN32 > +#define snprintf _snprintf > +#endif > + > struct color_t > { > double r, g, b, a; > > This builds and runs properly for me. Yes, we're not hitting problems. If we don't actually care about the buffer overrun, we can just use sprintf. Andrea _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman
