From: "Juan Manuel Guerrero" Organization: Darmstadt University of Technology To: djgpp-workers AT delorie DOT com Date: Thu, 19 Sep 2002 20:31:31 +0100 Subject: Re: conversion specifiers and _doprnt CC: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii), sandmann AT clio DOT rice DOT edu (Charles Sandmann) In-reply-to: <10209191633.AA17484@clio.rice.edu> References: from "Juan Manuel Guerrero" at Sep 19, 2002 01:26:29 PM X-mailer: Pegasus Mail for Windows (v2.54DE) Message-ID: X-MailScanner: Found to be clean Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Thu, 19 Sep 2002, Charles Sandmann wrote: > > > Personally, I'd leave O alone. I don't like removing existing > > > functionality without a very good reason. > > It should be noticed that the O specifier is not documented at all in libc docs, > > so that average users should never have used this specifier. Because of this fact and > > that the option is not defined by the standard at all, I suggested to remove it. > > All this it not an inconveniece to me. I will activate the O specifier again. > > I believe we should either document it or leave it as #if 0'ed - so leave it > like it is until the documentation is updated. It would be excellent if we > could add a note to the documentation that these codes cause GCC warnings > but are present for (xxx) compatibility. These codes were not documented > in BCC 3.0 (I checked last week), so it would be nice to know where they > came from (more recent BCC? MSC?) I have not found the O specifier and the other ones neither in my MSC v5.1 nor Borland compiler. But I have found them in FreeBSD. The doprnt.c file seems to be a modification of an old FreeBSD source. This source file, called vfprintf.c IIRC introduced those non standard conforming specifiers. All this only for your information. I am not lobbying for removing them, but I would like to know how to proced so this issue can be finished one for all. If we keep all this non standard specifiers, then they must be documented as non standard and explained that their use will produce warnings as suggested by Charles Sandmann. Regards, Guerrero, Juan Manuel