Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Message-ID:	<005b01c308fa$5b8cdbb0$78d96f83@pomello>
From:	"Max Bowsher" <maxb AT ukf DOT net>
To:	"Jeff Baker" <jbaker AT qnx DOT com>, <cygwin AT cygwin DOT com>
References:	<003d01c308ed$07e6e670$78d96f83 AT pomello> <000501c308f4$2c001070$c2020c0a AT jbaker1200>
Subject:	Re: CompactFlash Disk Geometry
Date:	Tue, 22 Apr 2003 19:09:46 +0100
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-MimeOLE:	Produced By Microsoft MimeOLE V6.00.2800.1106

Jeff Baker wrote:
> I wouldn't expect to see it print a full 64 bit integer, but I was
wondering
> why it's pushing the rest of the data out of place.
>
> VC:  15680 1 1 512
> Cygwin: 15680 0 1 1
>
> If it was merely a problem with printing the 64 bit argument then
shouldn't
> that be the only one that's mangled in the output?  In this data '15680'
is
> coming from the LARGE_INTEGER but I don't know where the zero is coming
> from, or why the last element goes from 512 to 1, or where the 512
vanishes
> to.

That zero is the HighPart of your LARGE_INTEGER.
It seems gcc uses a different ABI for varargs.

Trivial test program to confirm:

#include <stdio.h>
#include <windows.h>

int main(int argc, char* argv[])
{
  LARGE_INTEGER l;
  int i = 1;
  int j = 2;
  int k = 3;

  l.QuadPart = (5LL << 32) + 4;

  printf("%d %d %d %d\n", l, i, j, k);

  return 0;
}

Output:
4 5 1 2



Max.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -