From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15256 invoked by alias); 15 Sep 2007 18:12:36 -0000 Received: (qmail 15240 invoked by uid 22791); 15 Sep 2007 18:12:35 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (213.8.233.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 15 Sep 2007 18:12:30 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-210-74.inter.net.il [80.230.210.74]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id IWV02577 (AUTH halo1); Sat, 15 Sep 2007 21:12:10 +0300 (IDT) Date: Sat, 15 Sep 2007 18:12:00 -0000 Message-Id: From: Eli Zaretskii To: Daniel Jacobowitz CC: gdb-patches@sourceware.org In-reply-to: <20070915161220.GA21878@caradoc.them.org> (message from Daniel Jacobowitz on Sat, 15 Sep 2007 12:12:20 -0400) Subject: Re: [patch] printf "%p" gdb internal error fix Reply-to: Eli Zaretskii References: <20060910172037.GA3886@host0.dyn.jankratochvil.net> <200609101931.k8AJVF4m026090@elgar.sibelius.xs4all.nl> <20070904141926.GA27477@caradoc.them.org> <20070904205307.GA17062@caradoc.them.org> <20070915135229.GA15879@caradoc.them.org> <20070915161220.GA21878@caradoc.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-09/txt/msg00196.txt.bz2 > Date: Sat, 15 Sep 2007 12:12:20 -0400 > From: Daniel Jacobowitz > Cc: gdb-patches@sourceware.org > > > > May I suggest we reference a particular C or POSIX standard if we > > > are going to list exceptions? > > > > Fine with me, but I'm not aware of the C99 document that is freely > > accessible on the net. If you have a URL, by all means let's @uref > > it. > > I don't believe there is one, but this is a well-known and published > international standard. Can't we reference the printed version? We can, if we have the exact title and other details. > What I was trying to say was that our printf is an implementation of > the C89 printf function, not the C99 or Single Unix printf; that's why > it has all the missing features you noticed - in fact it has none of > the C99 additions. Well, we do have L and ll, so it's no longer true that we don't support any of C99. (Admittedly, they were implemented when they were GNU extensions, but today's readers of the manual do not need to know this piece of history.) > Can't we describe it as a mostly complete C89 printf instead of a > mostly incomplete C99 printf? I don't think it's right to ask our readers to be familiar with the history of the C standards. That is why I didn't even mention C99 (or any other standard).