linux-assembly.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bharanidharan S <S.Bharanidharan@ftel.co.uk>
To: Stephen Ray <steve@mrmighty.net>
Cc: ruxyz@yahoo.com, 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:39:23 +0000	[thread overview]
Message-ID: <423031EB.C9F46349@ftel.co.uk> (raw)
In-Reply-To: 42302A87.7020803@mrmighty.net


Stephen Ray wrote:
> 
> 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.

it seems to be a feature in C.
 [ from another mailing list:
  
https://lists.openafs.org/pipermail/openafs-devel/2003-July/009525.html 
 ]

The text from the ISO 1999 standard in 6.5.2.2 is:

6 If the expression that denotes the called function has a type that
does
  not include a prototype, the integer promotions are performed on each
  argument, and arguments that have type float are promoted to
  double. These are called the default argument promotions. [...]

7 If the expression that denotes the called function has a type that
does
  include a prototype, the arguments are implicitly converted, as if by
  assignment, to the types of the corresponding parameters, taking the
  type of each parameter to be the unqualified version of its declared
  type. The ellipsis notation in a function prototype declarator causes
  argument type conversion to stop after the last declared parameter.
The
  default argument promotions are performed on trailing arguments.


also check glibc's manual (may be out of date ??):
http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_28.html#SEC478


> 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/


  reply	other threads:[~2005-03-10 11:39 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 [this message]
2005-03-10 11:44   ` Bharanidharan S
  -- 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=423031EB.C9F46349@ftel.co.uk \
    --to=s.bharanidharan@ftel.co.uk \
    --cc=kernelnewbies@nl.linux.org \
    --cc=linux-assembly@vger.kernel.org \
    --cc=ruxyz@yahoo.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).