Hi Przemek,
Is it okay for you if I change all the snprintf()
calls to hb_snprintf() and you do the rest of the tweaking?
BTW, maybe you've missed it, but I've sent an e-mail
on strange #if behaviour. It's the same with MSVC:
---
#define DEF_A
#define DEF_B
#if defined( DEF_A ) && ! defined( DEF_B )
#error DEF_A AND NOT DEF_B
#endif
---
Brgds,
Viktor
On 2008.10.27., at 18:58, Przemyslaw Czerpak wrote:
On Mon, 27 Oct 2008, Szak�ts Viktor wrote:
Hi Viktor,
As far as I got to know, different snprintf()
implementations mapped to this symbol are behaving
slightly differently, so there is an important
point in trying to make those behave along the
standard (like MSVC _snprintf() not appending
a '\0' char).
Feel free to modify as you want, and if this is
the case we can just leave snprintf() as a name
is our code, and remap when/as needed.
For sure this line in hbsetup.h:
#define snprintf hb_snprintf
will have to be removed because it will break compilation in some
C compilers when C header files containing snpritf() declaration are
used with hbapi.h because our hb_snprintf does not have to use
_exactly_
the same attributes as snprintf(). We can try to add it to hbapi.h
after
hb_snprintf() declaration but it also isn't fully clean solution
though
it should help as temporary workaround. Instead we should locate all
places where snprintf() is used and replace them with hb_snprintf().
Someone who use compiler which does not support snprintf() can make it
and easy validate final results by simple compilation without above
#define.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
