This is the mail archive of the
mailing list for the Cygwin project.
Re: [Cygwin-ports-general] Ncview
- From: Michael Enright <mike at kmcardiff dot com>
- To: cygwin at cygwin dot com
- Date: Thu, 1 Oct 2015 15:11:10 -0700
- Subject: Re: [Cygwin-ports-general] Ncview
- Authentication-results: sourceware.org; auth=none
- References: <CAKmU=T_XtcOf1MOa_31oTfNYzUZ6QZD1xU9eTG-ERkvsua+gZQ at mail dot gmail dot com> <56095DBC dot 6090308 at gmail dot com> <1443720905 dot 8588 dot 17 dot camel at cygwin dot com>
On Thu, Oct 1, 2015 at 10:35 AM, Yaakov Selkowitz <firstname.lastname@example.org> wrote:
> Confirmed. Often 64-bit-only issues come down to one or more of the
> * implicit function declarations. Per the C standard, argument types
> are assumed to match whatever is given (which may be wrong if e.g. 0 is
> used instead of 0L or (PointerType)0 or NULL etc.) and the return type
> is assumed to be int (which will truncate the actual return value when
> it is actually a long/pointer).
> * vararg types. Because these types aren't declared, the compiler can't
> automatically cast values to the correct type, so literal values and
> symbolic constants must be explicitly cast if they are not meant to be
> an int and are not obviously a long/pointer.
Good list. I would also add attempting to store pointer differences in
an "int" instead of ptrdiff_t and the issue you can see from
which is that the integer types other than long long on 64-bit Windows
are 32-bits while on 64-bit Linux 'long' and 'long long' are both
64-bit. This issue means that 'long' is a good-enough hack for
ptrdiff_t on 64-bit Linux but not 64-bit Windows. Does Cygwin differ
from Windows itself on this issue? Most 32-bit-designed code is
probably more sensitive to the pointer-difference aspect of this.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple