Subj : Re: Any help on why?
To   : borland.public.cpp.borlandcpp
From : Bob Gonder
Date : Sun Jul 11 2004 07:37 pm

Wayne A. King wrote:

>On Thu, 08 Jul 2004 18:58:29 -0700, Bob Gonder wrote:
>
>Now that I have demonstrated that some compilers *do* actually parse
>the format string being passed to the printf function

Umm, yes, they do seem to do that, but they don't *act* on that
information (other than to complain).

> it's time to consider
>the possible effects of mismatches. The compiler writers are under *no*
>obligation to pass on code to be compiled which it has detected violates
>some syntactical rule.

I would beg to differ on that.  The rule is
	printf( const char*, ... )
There's no syntax rules there that _any_ type argument can break.

> They may handle it in *any* way they deem most
>appropriate. Some possible scenarios, given a mismatch between format
>specifiers and arguments being passed:
>
>(1) Pass on both the format string and the variable arguments exactly as
>written in the source. This *may* be the most attractive option, as it entails
>the least amount of programming for the compiler writers.

And has the positive aspect of being conforming.

> It has the down side of resulting in potentially confusing and unpredictable consequences
>when the program is run. 

That is the programmer's responsability.
I understand that it is currently non-PC to insist on anyone accepting
responsability for anything, but....

>(2) Silently alter the format string before passing it on to the RTL function,

How is it going to alter a const string and still be conforming?
And, if the format is "hidden" to the compiler, then what?

>(3) Silently cast the mismatched variable argument so that it matches the type
>specifier in the format string. e.g. - If %f is encountered with a correspond-
>ing integer variable, supply an implicit typecast for the variable: 
>(float) intvar 
>This approach would be limited by any language constraints on casting
>between different types.

Again,
If the format is "hidden" to the compiler, then what?
And, if it doesn't "convert" variables for hidden formats, how can it
for visible formats, and remain conforming?


>e.g. - Given this:
>
>int myint = 44;
>float myflt = 1.5;
>printf("%f\t%d\n", myint, myflt); // vars don't match type specifiers
>
>issue warnings and then dynamically change to this:
>
>printf("%f\t%d\n", (float)myint, (int)myflt); // now they do
>
>This would give much more predictable and easily interpreted results 
>when run, albeit the order of appearance of the output fields may seem
>switched from what the programmer expected or intended.

I would still dispute the legality of that.
Consider that in this code
file1.c
	char format[]="%f%f%Lx";
file2.c
	extern	char format[];
	printf( format, float1,float2,double1);
	printf("%f%f%Lx",float1,float2,double1);

The compiler can not see "format".
It must assume it is correct.
If it "changes" the second printf, creating differing output, then how
can you say it's conforming?

>Summary:
>
>While *most* (even all) compilers currently available *may* adopt 
>approach (1) above, there is *no* guarantee that they do or that
>future compilers or future versions of current compilers will use the
>same method.

There's also no guarantee that the sun will continue to shine...
Considering those "other" methods are non-conforming, I'd hope the
"guarantee" is solid.

> All bets are off when you have source code which
>transgresses the specified syntax or grammar of the language or
>compiler-specific language extensions.

Correct.  But again, there is nothing wrong with either syntax nor
grammar in these examples.

> Proceed with (great) caution
>when making assumptions about compiler behavior in such cases,
>and don't generalize from empirical results obtained in specific
>circumstances.

Sizes of variables,
Placement of variables on the stack (packing)
Supported conversions
All of these are compiler/target dependant.
Any of them may change when you change compiler or target.
You use the combinations that work for your compiler/target.
It is a hack.
It is allowed. (by C if not by managment)

.