Perl (5.10) seems to handle this this way, util.c:
for apidoc my_snprintf
The C library C functionality, if available and
standards-compliant (uses C, actually). However, if the
C is not available, will unfortunately use the unsafe
C which can overrun the buffer (there is an overrun c
Andy Lester wrote:
On Feb 5, 2008, at 1:17 PM, [EMAIL PROTECTED] wrote:
(He sent this to me directly by mistake)
snprintf is problematic on older Solaris systems, for one. At least
through 2.7 (2.8?) it's not included in any lib. So other apps needed to
test and bring in their own version.
Just a note: snprintf is problematic on older Solaris systems (x86 anyway),
for one. At least through 2.7 (2.8?) it's no included in any lib. So
other apps needed to test and bring in their own version.
a
Andy Bach
Systems Mangler
Internet: [EMAIL PROTECTED]
Voice: (608) 261-5738 Fax: 264-5932
On Tuesday 05 February 2008 11:36:00 Andy Lester wrote:
> Ignoring the length
> parameter leaves those platforms without snprintf() exactly where they
> are today.
... the PIT of VILE DESPAIR!
When the inevitable revolution comes, I'm going to put their maintainers up
against the wall and f
On Feb 5, 2008, at 1:17 PM, [EMAIL PROTECTED] wrote:
(He sent this to me directly by mistake)
snprintf is problematic on older Solaris systems, for one. At least
through 2.7 (2.8?) it's not included in any lib. So other apps
needed to
test and bring in their own version.
This is covered
On Feb 5, 2008 11:08 AM, Andy Lester <[EMAIL PROTECTED]> wrote:
> Constructions like this give me the willies:
>
>char * const buf = (char *)mem_sys_allocate(16);
>sprintf(buf, "%d", type);
>
i saw this code the other day, and thought, "gee, malloc's just gonna
grab 64 anyway. that's silly.
