From:	"Juan Manuel Guerrero" <ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De>
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:	<C2036E8307E AT HRZ1 DOT hrz DOT tu-darmstadt DOT de> from "Juan Manuel Guerrero" at Sep 19, 2002 01:26:29 PM
X-mailer:	Pegasus Mail for Windows (v2.54DE)
Message-ID:	<C274BBF5DC6@HRZ1.hrz.tu-darmstadt.de>
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

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

- Raw text -