Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #13385 > unrolled thread

Customizing printf

Back to article view | Back to comp.lang.c

Contents

  Customizing printf jacob navia <jacob@spamsink.net> - 2011-11-15 14:36 +0100
    Re: Customizing printf "Joel C. Salomon" <joelcsalomon@gmail.com> - 2011-11-15 13:07 -0500
    Re: Customizing printf Ben Pfaff <blp@cs.stanford.edu> - 2011-11-15 10:10 -0800
      Re: Customizing printf jacob navia <jacob@spamsink.net> - 2011-11-15 21:36 +0100
        Re: Customizing printf blp@cs.stanford.edu (Ben Pfaff) - 2011-11-15 12:51 -0800
          Re: Customizing printf "Joel C. Salomon" <joelcsalomon@gmail.com> - 2011-11-15 18:03 -0500
      Re: Customizing printf jgk@panix.com (Joe keane) - 2011-11-20 15:14 +0000
        Re: Customizing printf blp@cs.stanford.edu (Ben Pfaff) - 2011-11-20 10:43 -0800
          Re: Customizing printf Lauri Alanko <la@iki.fi> - 2011-11-20 19:01 +0000
            Re: Customizing printf blp@cs.stanford.edu (Ben Pfaff) - 2011-11-20 11:05 -0800
              Re: Customizing printf Dag-Erling Smørgrav <des@des.no> - 2011-11-20 20:38 +0100
                Re: Customizing printf blp@cs.stanford.edu (Ben Pfaff) - 2011-11-20 11:37 -0800
          Re: Customizing printf jgk@panix.com (Joe keane) - 2011-11-21 22:23 +0000
            Re: Customizing printf Ian Collins <ian-news@hotmail.com> - 2011-11-22 11:26 +1300
            Re: Customizing printf blp@cs.stanford.edu (Ben Pfaff) - 2011-11-21 14:23 -0800
            Re: Customizing printf Kaz Kylheku <kaz@kylheku.com> - 2011-11-21 23:06 +0000
              Re: Customizing printf jgk@panix.com (Joe keane) - 2011-11-23 00:09 +0000
                Re: Customizing printf blp@cs.stanford.edu (Ben Pfaff) - 2011-11-22 16:16 -0800
        Re: Customizing printf Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-21 05:29 -0800
          Re: Customizing printf jgk@panix.com (Joe keane) - 2011-11-21 22:50 +0000
    Re: Customizing printf Lowell Gilbert <lgusenet@be-well.ilk.org> - 2011-11-15 13:13 -0500
    Re: Customizing printf "-.-" <none@none.none> - 2011-11-16 14:06 +0100
      Re: Customizing printf gazelle@shell.xmission.com (Kenny McCormack) - 2011-11-16 13:40 +0000
      Re: Customizing printf Seebs <usenet-nospam@seebs.net> - 2011-11-16 20:18 +0000
        Re: Customizing printf Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-17 07:54 +0200

Page 1 of 2  [1] 2  Next page →

#13385 — Customizing printf

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

[toc] | [next] | [standalone]

#13397

On 11/15/2011 08:36 AM, jacob navia wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#13398

jacob navia <jacob@spamsink.net> writes:

> 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.
-- 
Ben Pfaff 
http://benpfaff.org

[toc] | [prev] | [next] | [standalone]

#13414

Le 15/11/11 19:10, Ben Pfaff a écrit :
> jacob navia<jacob@spamsink.net>  writes:
>
>> 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.

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.

[toc] | [prev] | [next] | [standalone]

#13421

jacob navia <jacob@spamsink.net> writes:

> Le 15/11/11 19:10, Ben Pfaff a écrit :
>> jacob navia<jacob@spamsink.net>  writes:
>>
>>> 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.
>
> 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.
-- 
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[toc] | [prev] | [next] | [standalone]

#13440

On 11/15/2011 03:51 PM, Ben Pfaff wrote:
> jacob navia <jacob@spamsink.net> writes:
>> 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.
> 
> 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

[toc] | [prev] | [next] | [standalone]

#13644

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].

[toc] | [prev] | [next] | [standalone]

#13647

jgk@panix.com (Joe keane) writes:

> 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.
-- 
"Welcome to the wonderful world of undefined behavior, where the demons
 are nasal and the DeathStation users are nervous." --Daniel Fox

[toc] | [prev] | [next] | [standalone]

#13648

In article <87ipmehbxl.fsf@blp.benpfaff.org>,
Ben Pfaff <blp@cs.stanford.edu> wrote:
> 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-Maketext/lib/Locale/Maketext/TPJ13.pod#A_Localization_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

[toc] | [prev] | [next] | [standalone]

#13649

Lauri Alanko <la@iki.fi> writes:

> In article <87ipmehbxl.fsf@blp.benpfaff.org>,
> Ben Pfaff <blp@cs.stanford.edu> wrote:
>> 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-Maketext/lib/Locale/Maketext/TPJ13.pod#A_Localization_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.
-- 
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[toc] | [prev] | [next] | [standalone]

#13654

blp@cs.stanford.edu (Ben Pfaff) writes:
> Lauri Alanko <la@iki.fi> writes:
> > http://search.cpan.org/dist/Locale-Maketext/lib/Locale/Maketext/TPJ13.pod
> 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
-- 
Dag-Erling Smørgrav - des@des.no

[toc] | [prev] | [next] | [standalone]

#13655

Dag-Erling Smørgrav <des@des.no> writes:

> blp@cs.stanford.edu (Ben Pfaff) writes:
>> Lauri Alanko <la@iki.fi> writes:
>> > http://search.cpan.org/dist/Locale-Maketext/lib/Locale/Maketext/TPJ13.pod
>> 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.

That's true.  In practice I have rarely found that to be a
significant limitation.
-- 
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[toc] | [prev] | [next] | [standalone]

#13746

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]

[toc] | [prev] | [next] | [standalone]

#13747

On 11/22/11 11:23 AM, Joe keane wrote:
> That makes it worse!

Makes what worse?

Context is good.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#13748

jgk@panix.com (Joe keane) writes:

> 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.
-- 
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[toc] | [prev] | [next] | [standalone]

#13753

On 2011-11-21, Joe keane <jgk@panix.com> wrote:
> 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

Indeed. A C format string is a form of code, so if you have translators writing
format strings, they are coding.

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

Suppose you had a translations file with records containing the original format
strings, and translated ones. A checker, invoked at build time, could validate
that every record in the file contains only equivalent format strings (that
differ only in their template text, not in the conversion specifiers).

Furthermore, the checker would generate, from this file, a C header file which
contains #define for nominal format strings (untranslated entries in English or
whatever your development team's common language is).

These #defines are used for writing the printf statements; they supply
real string-literal format strings. Except these go to a printf wrapper which
substitutes the translated text. The printf wrapper is endowed with the special
GCC annotation so that the printf argument checking is applied to it at compile
time.

The translated text is pulled from some data structure which is also generated
by the checker, in addition to that header file.

> [core dump]

That's the good case. The bad case is someone turns it into an exploitable
security hole.

[toc] | [prev] | [next] | [standalone]

#13808

In article <20111121145051.881@kylheku.com>,
Kaz Kylheku  <kaz@kylheku.com> wrote:
>Suppose you had a translations file with records

For simple things:

    printf("s %3d %9.6f\n", j, sum);

printf works great, and i have no problem with it.

Concise, easy to learn, easy to understand.

If you add user-defined operators (what next, while loops?), and your
format strings are other than compile-time constants, i just think
you'll be dishappy with the result.

I18N is more than switching format strings.  There are libraries to do
it, and you'll probably save yourself headaches if you make use of them.

Anyway it would take no time to write something that takes

    "die $1 unter die $2 gebroken ist"

and is type-safe.  This handles the "$1 de $2" versus "$2 no $1"
problem.  But really it's too simplistic.

Besides what you've done is make a mini scripting language, i think not
a good one.  Again there are libraries to do that; why invent a new one?

I write a lot of things in Perl, and shell; if someone says 'why don't
you write that in C?', i'd say 'why the hell would i do *that*?'.
You're trying to use a hammer where you want a bandsaw...

[toc] | [prev] | [next] | [standalone]

#13809

jgk@panix.com (Joe keane) writes:

> In article <20111121145051.881@kylheku.com>,
> Kaz Kylheku  <kaz@kylheku.com> wrote:
>>Suppose you had a translations file with records
>
> For simple things:
>
>     printf("s %3d %9.6f\n", j, sum);
>
> printf works great, and i have no problem with it.
>
> Concise, easy to learn, easy to understand.
>
> If you add user-defined operators (what next, while loops?), and your
> format strings are other than compile-time constants, i just think
> you'll be dishappy with the result.
>
> I18N is more than switching format strings.  There are libraries to do
> it, and you'll probably save yourself headaches if you make use of them.

Absolutely.  Some of them, in fact, such as GNU gettext, work the
way that Kaz describes.
-- 
"Your correction is 100% correct and 0% helpful. Well done!"
--Richard Heathfield

[toc] | [prev] | [next] | [standalone]

#13704

On Nov 20, 3:14 pm, j...@panix.com (Joe keane) wrote:

> 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].

[toc] | [prev] | [next] | [standalone]

#13750

In article <98791897-ac7d-4e5a-a528-7c2d543e1ed8@x7g2000yqb.googlegroups.com>,
Nick Keighley  <nick_keighley_nospam@hotmail.com> wrote:
>how many parameters do fputint() and fputdouble() have?

    int fputint(FILE *fp, int val, int wid, int opt);
    int fputdouble(FILE *fp, double val, int wid, int dp, int opt);

[C++]

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

When i first saw this wacky crap, i thought 'is this a joke?' and then
'is this someone's idea of good design?'.

But note that all the problems come from assuming that the input/output
functions have two arguments, which is just wrong.  For example, i
rarely see a 'double' printed with a bare "%f"; the format is as
important as the value.

And if you write 'fputint' and someone says 'that's decimal!  i need
octal!' you say, well here you go:

    int fputdecint(...);
    int fputoctint(...);
    int fputhexint(...);

Or just use the 'opt' thingy i gave above.

The problem is that all the functions are called "<<"; so you have the
type to split on, but that's really not sufficient.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web