From: Bharanidharan S <S.Bharanidharan@ftel.co.uk>
To: Stephen Ray <steve@mrmighty.net>
Cc: Linux Kernel Newbie <kernelnewbies@nl.linux.org>,
Assembly Linux <linux-assembly@vger.kernel.org>
Subject: Re: OFF-TOPIC : Confusion about basic C program behaviour
Date: Thu, 10 Mar 2005 11:44:10 +0000 [thread overview]
Message-ID: <4230330A.469D5747@ftel.co.uk> (raw)
In-Reply-To: 42302A87.7020803@mrmighty.net
use this option to prove your hypothesis:
-fshort-double
this would make sizeof(double) = sizeof(float)
by this, stack problems should go away.
but this is not a suffested compiler options because of portability
issues.
Stephen Ray wrote:
>
> Just a thought, but not a particularly educated one. Compiling with
> -Wall gives me:
>
> test.c:4: warning: return type defaults to `int'
> test.c: In function `main':
> test.c:15: warning: int format, double arg (arg 3)
> test.c:16: warning: int format, double arg (arg 2)
> test.c:18: warning: int format, double arg (arg 2)
> test.c:18: warning: int format, double arg (arg 3)
> test.c:20: warning: control reaches end of non-void function
>
> Looks like maybe the floats are automatically promoted to doubles before
> they are passed to printf. I don't know if that's standard behaviour,
> but it seems reasonable. So then in the first case, two 64-bit values
> are put on the stack, and two 64-bit values are taken off the stack.
>
> In the second case, two 64-bit values are put on the stack, one 64-bit
> value is taken off the stack and presented correctly, and one 64-bit
> value has only the first 32 bits read, and misinterpreted as a signed int.
>
> In the third case, two 64-bit values are put on the stack, and the first
> 32 bits are interpreted as the first signed int, and the second next 64
> are interpreted as a double. So case 3 is different from case 2 in that
> the double value in case 3 is made up of two halves of two different
> doubles, while in case 2 the double is made from an actual double.
>
> Or something like that.
>
> --
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive: http://mail.nl.linux.org/kernelnewbies/
> FAQ: http://kernelnewbies.org/faq/
next prev parent reply other threads:[~2005-03-10 11:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-10 10:00 OFF-TOPIC : Confusion about basic C program behaviour Learner
2005-03-10 11:07 ` Stephen Ray
2005-03-10 11:39 ` Bharanidharan S
2005-03-10 11:44 ` Bharanidharan S [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-03-10 11:54 Learner
2005-03-10 16:23 ` Robert G. Plantz
2005-03-14 9:05 Learner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4230330A.469D5747@ftel.co.uk \
--to=s.bharanidharan@ftel.co.uk \
--cc=kernelnewbies@nl.linux.org \
--cc=linux-assembly@vger.kernel.org \
--cc=steve@mrmighty.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.