Customizing printf

[jacob navia]

Recently I was wondering how to extend lcc-win's printf to support 128
bit integers, and searching the net I found this:

http://www.gnu.org/s/hello/manual/libc/Customizing-Printf.html

Apparently gcc has an interface for customizing printf that looks quite
interesting.

I would like to know if anybody here has experience with using this, I
am considering implementing it in lcc-win.

Thanks

 

[Joel C. Salomon]

http://www.gnu.org/s/hello/manual/libc/Customizing-Printf.html

Apparently gcc has an interface for customizing printf that looks quite
interesting.

I would like to know if anybody here has experience with using this, I
am considering implementing it in lcc-win.

I've never used GCC's (actually, the GNU C Library's) extendible printf,
but I have used Plan 9's libfmt, which has a similar idea. A Unix port
is available at <http://swtch.com/plan9port/unix/>. It's a nice
extension, on occasion.

By the way, if you generally use Microsoft's C library in lcc-win, you
might warn your users that MS printf extensions they're used to using
are no longer there.

--Joel

 

[Ben Pfaff]

Recently I was wondering how to extend lcc-win's printf to support 128
bit integers, and searching the net I found this:

http://www.gnu.org/s/hello/manual/libc/Customizing-Printf.html

Apparently gcc has an interface for customizing printf that looks quite
interesting.

One reason that I have never used glibc's extensible printf is
that GCC can't be configured to type-check the arguments for
extensions, so you get warnings for correct use of extensions.

 

[jacob navia]

Le 15/11/11 19:10, Ben Pfaff a écrit :

One reason that I have never used glibc's extensible printf is
that GCC can't be configured to type-check the arguments for
extensions, so you get warnings for correct use of extensions.

This will not happen in lcc-win. Check functions can be provided that
will be loaded by the compiler at startup or can be linked into the
compiler.

 

[Ben Pfaff]

Le 15/11/11 19:10, Ben Pfaff a écrit :

This will not happen in lcc-win. Check functions can be provided that
will be loaded by the compiler at startup or can be linked into the
compiler.

I'm glad to hear that you are planning to avoid that problem. I
wish that GCC would also arrange a solution.

 

[Joel C. Salomon]

I'm glad to hear that you are planning to avoid that problem. I
wish that GCC would also arrange a solution.

See the examples given for libfmt at
<http://swtch.com/plan9port/unix/man/fmtinstall3.html>. The example
includes #pragmas suitable for Ken Thompson's C compilers (as
distributed with Plan 9 or with Google Go):

#pragma varargck type "X" Complex

Hard to get much simpler than that...

JST

 

[-.-]

jacob navia was trying to save the world with his stuff:

Recently I was wondering how to extend lcc-win's printf to support ...
...am considering implementing it in lcc-win.

You self-celebrating fucko. There only exist your things to you:
that silly lcc-win and your funny containers.
Stop making this newsgroup your personal advertisements page.

 

[Kenny McCormack]

jacob navia was trying to save the world with his stuff:


You self-celebrating fucko. There only exist your things to you:
that silly lcc-win and your funny containers.
Stop making this newsgroup your personal advertisements page.

Looks like somebody didn't get enough mommy-love.

--
But the Bush apologists hope that you won't remember all that. And they
also have a theory, which I've been hearing more and more - namely,
that President Obama, though not yet in office or even elected, caused the
2008 slump. You see, people were worried in advance about his future
policies, and that's what caused the economy to tank. Seriously.

(Paul Krugman - Addicted to Bush)

 

[Seebs]

jacob navia was trying to save the world with his stuff:

There only exist your things to you:
that silly lcc-win and your funny containers.
Stop making this newsgroup your personal advertisements page.

I have Mr. Navia plonked because of his habit of random and unjustified
flames, so I thank you for calling that post to my attention, since it has
some cool ideas in a field I have previously thought about. I even got
as far as a test implementation of a printf which let you pass formatting
functions as arguments, although I never got around to a "register new
characters" feature.

-s

 

[Phil Carmody]

I have Mr. Navia plonked because of his habit of random and unjustified
flames, so I thank you for calling that post to my attention, since it has
some cool ideas in a field I have previously thought about. I even got
as far as a test implementation of a printf which let you pass formatting
functions as arguments, although I never got around to a "register new
characters" feature.

We should swap code - I implemented the "register new characters" feature...
(OK, there was one 'extension' character, and you registered new modifiers
to that.)

Phil

 

[Joe keane]

But overall, the variadic-function-with-format-string thing seems to
lose its appeal when it's pushed past basic printf, and even there i'm
not so sure it's your friend.

Better to use fputc, fputs, fputfoo, fputbar...

You're much more likely to get compile or link errors rather than just
screwy behavior [e.g. what if some library says printf("%z", z) means
one thing and another library says it means a different thing?].

Or look at C++, mostly just works... I'm not recommending operator
overloading, you just need logical names for things [C++ makes up
different names for things; you just don't know what they are].

 

[Ben Pfaff]

But overall, the variadic-function-with-format-string thing seems to
lose its appeal when it's pushed past basic printf, and even there i'm
not so sure it's your friend.

Better to use fputc, fputs, fputfoo, fputbar...

The place where printf-like format strings shine versus a series
of discrete function calls is when internationalization comes
into the picture. It's relatively straightforward to allow
translators to supply alternative format strings to be used at
runtime, but there is no comparable way to allow them to supply a
different series of discrete function calls.

 

[Lauri Alanko]

The place where printf-like format strings shine versus a series
of discrete function calls is when internationalization comes
into the picture. It's relatively straightforward to allow
translators to supply alternative format strings to be used at
runtime, but there is no comparable way to allow them to supply a
different series of discrete function calls.

Printf doesn't "shine" in internationalization. Having
language-specific format strings is a woefully inadequate hack that is
often used in lieu of proper multilingual support. It's better than
nothing, sure, but hardly something to brag about. Here's a
description of some of the issues that come up:

http://search.cpan.org/dist/Locale-...lization_Horror_Story:_It_Could_Happen_To_You

There _are_ better, systematic and linguistically sound approaches to
internationalizing a program's messages, and in fact that is what I'm
currently working on. It will take a while, though, until the
technology is in a shape that is useful to the casual C programmer.


Lauri

 

[Ben Pfaff]

Printf doesn't "shine" in internationalization. Having
language-specific format strings is a woefully inadequate hack that is
often used in lieu of proper multilingual support. It's better than
nothing, sure, but hardly something to brag about. Here's a
description of some of the issues that come up:

http://search.cpan.org/dist/Locale-...lization_Horror_Story:_It_Could_Happen_To_You

Whoever wrote that page did not read the GNU gettext manual,
which explains the same problems and shows the solutions to them.

 

[Ben Pfaff]

I believe gettext only supports one number per string, so it cannot
handle the "%d files in %d directories" example. You'd have to rewrite
it as "I scanned %d directories." + "I found %d files." or something
similar.

That's true. In practice I have rarely found that to be a
significant limitation.

 

[Dag-Erling Smørgrav]

Whoever wrote that page did not read the GNU gettext manual,
which explains the same problems and shows the solutions to them.

I believe gettext only supports one number per string, so it cannot
handle the "%d files in %d directories" example. You'd have to rewrite
it as "I scanned %d directories." + "I found %d files." or something
similar.

DES

 

[Nick Keighley]

But overall, the variadic-function-with-format-string thing seems to
lose its appeal when it's pushed past basic printf, and even there i'm
not so sure it's your friend.

you obviously haven't string C++ iostreams...

Better to use fputc, fputs, fputfoo, fputbar...

how many parameters do fputint() and fputdouble() have?

You're much more likely to get compile or link errors rather than just
screwy behavior [e.g. what if some library says printf("%z", z) means
one thing and another library says it means a different thing?].

Or look at C++, mostly just works...

try printing a four digit hexadecimal number. Or a double with 3
significant digits. You can do thse things but they're awkward,

I'm not recommending operator
overloading, you just need logical names for things [C++ makes up
different names for things; you just don't know what they are].

 

[Joe keane]

That makes it worse!

At least if the format string is compile-time constant, the compiler
-could- help you out. It's not obligated to do this check, and C offers
no guarantee if you screw up the types in a variadic function, but it's
fairly easy to implement.

If the format string is read from a file, then God help you...

[core dump]

 

[Ben Pfaff]

That makes it worse!

At least if the format string is compile-time constant, the compiler
-could- help you out. It's not obligated to do this check, and C offers
no guarantee if you screw up the types in a variadic function, but it's
fairly easy to implement.

If the format string is read from a file, then God help you...

The tools that allow you to do this actually verify that the
format string read from the file is compatible with the one that
was specified at compile time.

 

[Ian Collins]

That makes it worse!

Makes what worse?

Context is good.