Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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" To: "Jeff Baker" , 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 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 #include 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/