From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 421 invoked by alias); 1 Oct 2007 06:45:54 -0000 Received: (qmail 375 invoked by uid 48); 1 Oct 2007 06:45:41 -0000 Date: Mon, 01 Oct 2007 06:45:00 -0000 Message-ID: <20071001064541.374.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c/15685] printf("%s\n") optimized to puts also when parameter might be null In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "mathias dot hasselmann at gmx dot de" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-10/txt/msg00015.txt.bz2 ------- Comment #4 from mathias dot hasselmann at gmx dot de 2007-10-01 06:45 ------- (In reply to comment #1) > Not a bug as printf can segfault if it is supplied a NULL pointer for the > string formatter. > If glibc does something different than that, glibc is does not have a bug > either as it is undefined really > so converting the call to a puts is a vaild transformation. > Even if its a valid transformation, there is the question if this is a reasonable transformation. Obviously that optimization was introduced because quite alot of people do not know about the puts function and use printf to output static lines of text. On the other hand there are people who rely on glibc's handling of the undefined NULL pointer situation. Question is: Which group is bigger. The missuse printf as puts group or the rely on glibc's relaxed NULL handling group. My guess would be that people who do not even know puts care even less about the fact that ANSI and ISO didn't care about NULL handling in format strings. If that would true, this optimization would be valid, but unreasonable as it breaks the expections of your clients. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15685