«

In article <98791897-ac7d-4e5a-a528->,
Nick Keighley <> 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.

On 2011-11-21, Joe keane <> 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.

In article <>,
Kaz Kylheku <> 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...

(Joe keane) writes:

> In article <>,
> Kaz Kylheku <> 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