«

On 2006-01-10, Keith Thompson <kst-> wrote:
> "Dik T. Winter" <> writes:
>> In article <> Keith Thompson
>> <kst-> writes:
>> > (Dag-Erling Smørgrav) writes:
>> > > "osmium" <> writes:
>> > >> When a knowledgeable person says "C calling convention", *this* is
>> > >> what he means. There is nothing analogous to printf() with it's
>> > >> indeterminate number of parameters in, Pascal, for example.
>> > >
>> > > Yes, there is. Write() and WriteLn() both take a variable number of
>> > > arguments. There is however no way for the programmer to define a
>> > > procedure which takes a variable number of arguments.
>> >
>> > Yes, but as I recall the Write and WriteLn procedures, unlike C's
>> > printf(), are "magical".
>>
>> Yes, they are. In the same way as variadic functions are magical.
>
> No, not quite. In C, variadic functions are a feature of the
> language, and users are free to write their own. Because of this, the
> compiler has to handle them in the general case (though it can
> optimize particular instances). Pascal's Write and Writeln, on the
> other hand, are unique in the language. They're effectively special
> operators handled by the compiler rather than true functions.

Of course, printf existed before varargs.h ever did, so i suppose it
once was "magical", even if it isn't anymore. [the original
implementation was written specifically for a system with a stack that
grows down and which all arguments are passed on.]

>> What we lost in the exchange (TANSTAAFL) was the ability to
>> substitute user-defined replacements for the Standard library
>> functions: if you've got a more accurate inverse cosine, you
>> can't call it acos(). The place this becomes most irksome is
>> with malloc() and friends, where debugging could be enormously
>> improved if only we could insert our own instrumented versions.
>> Alas, the Standard forbids it on pain of undefined behavior.
>
>If I have the source code, can't I just implement mymalloc() and
>then #define malloc mymalloc
>
>I suppose I can't do it if I don't have the source...

Source code to *WHAT*?

If you are recompiling the entire C library, you can alter the
existing malloc() without trying to substitute a new one.

Oh, yes, #define tricks can still be tricky due to problems with
(a) just where do you put that #define so all code (EXCEPT the
original malloc()) sees it, and (b) not all source, especially
assembly-language source, necessarily uses the preprocessor.

If you have the source code TO YOUR OWN APPLICATION, but not the C
library, you can do the #define trick, *BUT* calls by the C library
to the C library will use the original malloc(). This can cause
trouble if something is allocated by the original malloc() and freed
by your free() or vice versa. Presumably there's some difference
between them (space for the tracking and statistics and error
checking?) or you wouldn't bother doing this. Also, you have to
make sure all parts of your application see the #define.

Gordon L. Burditt

John Devereux wrote:
> "Mark B" <> writes:
>
>
>>"John Devereux" <> wrote in message
>>news:...
>>
>><snip>
>>
>>>Actually gcc for example will typically silently replace
>>>
>>> printf("Hello\n");
>>>
>>>with
>>>
>>> puts("Hello\n");
>>
>>Doubtful... those 2 lines are not equivalent.
>
>
> So I see! I should have been either more accurate, or more vague.
>
> gcc replaces calls to printf() with calls to puts()... when it thinks
> it can.
>
> I was trying to show by example that C compilers can indeed use
> "compiler magic", in this case to call an entirely different function
> from what was expected.
>
> Perhaps this behaviour is not compatible with standard C, in which
> case, I'm sorry for mentioning it!
>
You missed the point perhaps. The printf() example is not equivalent
because puts() supplies its own '\n'.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

John Devereux wrote:
> jacob navia <> writes:
>
> No, if I actually *use* the return value of printf, then it does call
> printf:
>
> #include <stdio.h>
>
> int main(void)
> {
> volatile int a = printf("Hello, World!\n");
> }

This 'volatile' does nothing -- the printf call has already occurred
by the time that it comes to assigning a value to 'a' !

Anyway, I think the compiler could still optimise the code
to be the same as:
int a = 14;
puts("Hello, World!");
on systems where printf can't fail.

Joe Wright <> writes:

> John Devereux wrote:
>> "Mark B" <> writes:
>>
>>> "John Devereux" <> wrote in message
>>> news:...
>>>
>>><snip>
>>>
>>>>Actually gcc for example will typically silently replace
>>>>
>>>> printf("Hello\n");
>>>>
>>>>with
>>>>
>>>> puts("Hello\n");
>>>
>>>Doubtful... those 2 lines are not equivalent.
>> So I see! I should have been either more accurate, or more vague.
>> gcc replaces calls to printf() with calls to puts()... when it
>> thinks
>> it can.
>> I was trying to show by example that C compilers can indeed use
>> "compiler magic", in this case to call an entirely different function
>> from what was expected.
>> Perhaps this behaviour is not compatible with standard C, in which
>> case, I'm sorry for mentioning it!
>>
> You missed the point perhaps. The printf() example is not equivalent
> because puts() supplies its own '\n'.

No, thanks, I understood that (after Robert Gamble supplied a
clue). Though I think you were the only person to say this explicitly!

I had to look up puts() - previously I had only ever seen it in debug
dumps, when trying to find out why printf() was missing from the
object file!

Anyway, who in their right mind could possibly have expected puts() to
do that? Stupid function...mutter...

--

John Devereux

In article < .com>,
Old Wolf <> wrote:

>Anyway, I think the compiler could still optimise the code
>to be the same as:
> int a = 14;
> puts("Hello, World!");
>on systems where printf can't fail.

I'm having difficulty thinking of a system on which
printf() can't fail. Suppose the user had fclose()'d stdout
earlier? Suppose stdout is not connected to a serial console?
Suppose it is connected to a serial console that has had flow
control asserted on it for so long that the system buffers have
filled up?

--
All is vanity. -- Ecclesiastes

Chuck F. wrote:
> Eric Sosman wrote:
>
>>
> ... snip ...
>
>>
>> What we lost in the exchange (TANSTAAFL) was the ability to substitute
>> user-defined replacements for the Standard library functions: if
>> you've got a more accurate inverse cosine, you can't call it acos().
>> The place this becomes most irksome is with malloc() and friends,
>> where debugging could be enormously improved if only we could insert
>> our own instrumented versions. Alas, the Standard forbids it on pain
>> of undefined behavior.
>
>
> Actually you often can do just that (substitution). However it isn't
> portable.

To put it another way, the Standard forbids it on pain
of undefined behavior.

--
Eric Sosman
lid

John Devereux wrote:
> Joe Wright <> writes:
>
> > John Devereux wrote:
> >> "Mark B" <> writes:
> >>
> >>> "John Devereux" <> wrote in message
> >>> news:...
> >>>
> >>><snip>
> >>>
> >>>>Actually gcc for example will typically silently replace
> >>>>
> >>>> printf("Hello\n");
> >>>>
> >>>>with
> >>>>
> >>>> puts("Hello\n");
> >>>
> >>>Doubtful... those 2 lines are not equivalent.
> >> So I see! I should have been either more accurate, or more vague.
> >> gcc replaces calls to printf() with calls to puts()... when it
> >> thinks
> >> it can.
> >> I was trying to show by example that C compilers can indeed use
> >> "compiler magic", in this case to call an entirely different function
> >> from what was expected.
> >> Perhaps this behaviour is not compatible with standard C, in which
> >> case, I'm sorry for mentioning it!
> >>
> > You missed the point perhaps. The printf() example is not equivalent
> > because puts() supplies its own '\n'.
>
> No, thanks, I understood that (after Robert Gamble supplied a
> clue). Though I think you were the only person to say this explicitly!
>
> I had to look up puts() - previously I had only ever seen it in debug
> dumps, when trying to find out why printf() was missing from the
> object file!
>
> Anyway, who in their right mind could possibly have expected puts() to
> do that? Stupid function...mutter...

It gets worse: fputs does the same thing as puts on the provided stream
except that it does *not* print the newline, go figure.

Robert Gamble

>>Anyway, I think the compiler could still optimise the code
>>to be the same as:
>> int a = 14;
>> puts("Hello, World!");
>>on systems where printf can't fail.
>
>I'm having difficulty thinking of a system on which
>printf() can't fail. Suppose the user had fclose()'d stdout
>earlier?

Well, it's remotely possible that this could be a no-op.

>Suppose stdout is not connected to a serial console?

How about if it's connected to a 3-line x 16 character LCD display
on the front of the microwave oven, and it can't be connected to
anything else (no Bluetooth remote control).

You do have to stretch fairly far to come up with a situation where
it absolutely can't fail.

>Suppose it is connected to a serial console that has had flow
>control asserted on it for so long that the system buffers have
>filled up?

Then printf() should wait. The system should always let you have
enough time to order and receive more paper for a hard-copy printer
(unless you decide to interrupt it first). Or to call someone to
repair the printer (and, if necessary, to breed and educate a printer
repairman if there isn't one).

Gordon L. Burditt

In article <dq1k0o$869$>,
Walter Roberson <> wrote:

>I'm having difficulty thinking of a system on which
>printf() can't fail.

Unlikely, certainly.

>Suppose the user had fclose()'d stdout earlier?

That is not required to return an error. It's undefined behaviour.

>Suppose stdout is not connected to a serial console?
>Suppose it is connected to a serial console that has had flow
>control asserted on it for so long that the system buffers have
>filled up?

If the operating system does not provide auitable error indications,
printf might never return errors.

-- Richard