Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: x86 Stack Confusion

Reply
Thread Tools

Re: x86 Stack Confusion

 
 
Jordan Abel
Guest
Posts: n/a
 
      01-10-2006
On 2006-01-10, Keith Thompson <(E-Mail Removed)> wrote:
> "Dik T. Winter" <(E-Mail Removed)> writes:
>> In article <(E-Mail Removed)> Keith Thompson
>> <(E-Mail Removed)> writes:
>> > http://www.velocityreviews.com/forums/(E-Mail Removed) (Dag-Erling Smørgrav) writes:
>> > > "osmium" <(E-Mail Removed)> 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.]
 
Reply With Quote
 
 
 
 
Gordon Burditt
Guest
Posts: n/a
 
      01-10-2006
>> 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
 
Reply With Quote
 
 
 
 
Joe Wright
Guest
Posts: n/a
 
      01-10-2006
John Devereux wrote:
> "Mark B" <(E-Mail Removed)> writes:
>
>
>>"John Devereux" <(E-Mail Removed)> wrote in message
>>news:(E-Mail Removed)...
>>
>><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 ---
 
Reply With Quote
 
Old Wolf
Guest
Posts: n/a
 
      01-11-2006
John Devereux wrote:
> jacob navia <(E-Mail Removed)> 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.

 
Reply With Quote
 
John Devereux
Guest
Posts: n/a
 
      01-11-2006
Joe Wright <(E-Mail Removed)> writes:

> John Devereux wrote:
>> "Mark B" <(E-Mail Removed)> writes:
>>
>>> "John Devereux" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>>
>>><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
 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      01-11-2006
In article <(E-Mail Removed) .com>,
Old Wolf <(E-Mail Removed)> 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
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      01-11-2006
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
(E-Mail Removed)lid

 
Reply With Quote
 
Robert Gamble
Guest
Posts: n/a
 
      01-11-2006
John Devereux wrote:
> Joe Wright <(E-Mail Removed)> writes:
>
> > John Devereux wrote:
> >> "Mark B" <(E-Mail Removed)> writes:
> >>
> >>> "John Devereux" <(E-Mail Removed)> wrote in message
> >>> news:(E-Mail Removed)...
> >>>
> >>><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

 
Reply With Quote
 
Gordon Burditt
Guest
Posts: n/a
 
      01-11-2006
>>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
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      01-11-2006
In article <dq1k0o$869$(E-Mail Removed)>,
Walter Roberson <(E-Mail Removed)-cnrc.gc.ca> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
C/C++ compilers have one stack for local variables and return addresses and then another stack for array allocations on the stack. Casey Hawthorne C Programming 3 11-01-2009 08:23 PM
x64 vs x86.. surprising results in performance (x86 better)? markm75 Windows 64bit 7 01-09-2008 06:41 PM
Why is there an x86 emu if a processor is x86-64? =?Utf-8?B?RWxsaW90IEh1ZGdpbnM=?= Windows 64bit 4 07-23-2006 11:52 PM
x86 Mac Laptop and x86 iMac now available Daniel NZ Computing 11 01-17-2006 12:11 PM
Is there a way with Linux x86 to report a way the current stack trace for a thread? kevin.hall@motioneng.com C++ 4 10-20-2005 09:43 PM



Advertisments