From owner-freebsd-bugs  Sun Sep 12 15:10:51 1999
Delivered-To: freebsd-bugs@freebsd.org
Received: from mathserv.mps.ohio-state.edu (mathserv.mps.ohio-state.edu [128.146.111.31])
	by hub.freebsd.org (Postfix) with ESMTP id B8DA614E05
	for <freebsd-bugs@freebsd.org>; Sun, 12 Sep 1999 15:10:49 -0700 (PDT)
	(envelope-from ilya@math.ohio-state.edu)
Received: from monk.mps.ohio-state.edu (monk.mps.ohio-state.edu [128.146.111.52])
	by mathserv.mps.ohio-state.edu (8.9.3/8.9.3) with ESMTP id SAA28190;
	Sun, 12 Sep 1999 18:10:47 -0400 (EDT)
Received: (from ilya@localhost)
	by monk.mps.ohio-state.edu (8.9.3/8.9.3) id SAA16630;
	Sun, 12 Sep 1999 18:10:33 -0400 (EDT)
From: Ilya Zakharevich <ilya@math.ohio-state.edu>
Message-Id: <199909122210.SAA16630@monk.mps.ohio-state.edu>
Subject: Re: [ID 19990727.005] sprintf considered insecure?
To: gsar@ActiveState.com (Gurusamy Sarathy)
Date: Sun, 12 Sep 1999 18:10:33 -0400 (EDT)
Cc: muir@idiom.com (David Muir Sharnoff), perl5-porters@perl.org,
	freebsd-bugs@freebsd.org
In-Reply-To: <199909122032.NAA27081@activestate.com> from "Gurusamy Sarathy" at Sep 12, 1999 01:32:17 PM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Gurusamy Sarathy writes:
> I don't know if this is still true on real systems (and freebsd),
> but it is unfortunate that such brokenness should affect Perl code.
> The attached patch will help most common scenarios.

> ==== //depot/perl/perl.c#166 (text) ====
> Index: perl/perl.c
> --- perl/perl.c.~1~	Sun Sep 12 13:09:05 1999
> +++ perl/perl.c	Sun Sep 12 13:09:05 1999
> @@ -409,6 +409,11 @@
>      Safefree(PL_screamnext);
>      PL_screamnext  = 0;
>  
> +    /* float buffer */
> +    Safefree(PL_efloatbuf);
> +    PL_efloatbuf = Nullch;
> +    PL_efloatsize = 0;
> +

Can you reconfigure your diff-extractor to give diff the options -p?

> +To cope with broken systems that allow the standard locales to be
> +overridden by malicious users, the return value may be tainted
> +if any of the floating point formats are used and the conversion
> +yields something that doesn't look like a normal C-locale floating
> +point number.  This happens regardless of whether C<use locale> is
> +in effect or not.

Why this in 'no locale' situation?  Do you do the same for the
NOK===>POK conversions?

Ilya


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message