Message-ID: <46B0C457.4A512ECF@dessent.net>
Date: Wed, 01 Aug 2007 10:35:19 -0700
From: Brian Dessent <brian AT dessent DOT net>
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: printf
References: <C6EEDB0EB45A56439F73B1D23E39694A3DED30 AT USORL02P702 DOT ww007 DOT siemens DOT net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

"Frederich, Eric P21322" wrote:

> The author says...
> "Note that if you want a portable version of printf() in your code, you
> are _much_ better off using something that natively parses the format
> string. This ensures that you get the same parsing behavior on all
> platforms"

I don't know what exactly this is trying to say, but my interpretation
of it is "you need to write your own %-format parsing code if you need
to be sure of how it's going to behave" which IMO is quite a silly thing
to say.  It's a tautology, "you can't really be sure of X unless you do
it yourself."  But if you're just using simple and standard format
specifiers (like %s and %d) it would be needlessly ridiculous to
implement your own.

> If in cygwin, I have a c file like so...
> 
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main(int argc, char* argv[]){
>     printf("Which printf am I using?\n");
> }
> 
> ... and I compile it under cygwin with "gcc -mno-cygwin test.c"...
> Would I be using one that "natively parses the format string"?
> ... now if I compile without the -mno-cygwin option, what happens?

By my interpretation, neither, since "natively parses the format string"
means you wrote the code that does the parsing, whereas here you are
just calling the C library's printf to do it.

Note that you are using two different C libraries above, Cygwin and
MinGW (MSVCRT).

> I was looking around in some gcc source code for printf and found
> vprintf.c which calls vfprintf.c with stdout, which calls _doprnt.
> All of these were in a directory called "libiberty".  Furthermore, the
> _doprnt winds up calling fprintf.
> 
> Does GCC have it's own implementation of printf and is it different than
> glibc's implementation?

There are at least three things wrong in the above paragraphs.

1. gcc does not implement a C library, so there is no implementation of
any printf in gcc.  The C library is separate from gcc, gcc is just the
compiler.
2. libiberty is only a portabilty library.  It does not implement any
actual printf code (it just calls the C library's fprintf as you
discovered.)
3. glibc is only used on linux.  On Cygwin and MinGW you are not using
glibc.

> I am also looking into this because I wanted to create my own
> specialized version of printf which prints to two files with just one
> function call.  I would be doing some different things on each file.  I
> was looking for a good vfprintf to start with.

It depends on what these "different things" actually means.  You can do
a lot with the varargs version of printf, e.g.:

int my_special_snowflake_printf (FILE *f1, FILE *f2, char *fmt, ...)
{
  va_list ap;
  va_start (ap, fmt);

  fputs ("header for f1 output: ", f1);
  vfprintf (f1, fmt, ap);
  fputs ("header for f2 output: ", f2);
  vfprintf (f2, fmt, ap);
  va_end (ap);
}

I'd say it would be pretty silly do reimplement all of the actual printf
guts just to do file multiplexing, but whatever.  If you want to see the
underlying implementation of printf that Cygwin uses, look in newlib. 
If you want to see the underlying implementation of printf that MinGW
uses, you need the source code to MSVCRT which I believe is only
available if you buy MS Visual Studio.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/