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 X-envelope-info: Message-Id: <5.2.1.1.2.20030422102837.02cfc1c8@pop.sonic.net> X-Sender: rschulz AT pop DOT sonic DOT net Date: Tue, 22 Apr 2003 10:32:12 -0700 To: cygwin AT cygwin DOT com From: Randall R Schulz Subject: Re: CompactFlash Disk Geometry In-Reply-To: <000501c308f4$2c001070$c2020c0a@jbaker1200> References: <003d01c308ed$07e6e670$78d96f83 AT pomello> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Jeff, It's not "pushing [anything] out of place," it's doing what you told it to do. (What more can we ask of a simple compiler, after all?) Since printf and similar functions have no fixed prototype, the compiler can do nothing but put on the call stack exactly what you give as an argument. If there was a prototype, then it could apply standard conversions, of course, but the nature of printf and other varargs-type functions preclude such assistance. Randall Schulz At 10:25 2003-04-22, 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. -- 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/