octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mex API changes for 64bit


From: David Bateman
Subject: Re: Mex API changes for 64bit
Date: Sun, 03 Jun 2007 00:00:58 +0200
User-agent: Thunderbird 1.5.0.7 (X11/20060921)

David Bateman wrote:
> Index: src/mxarray.h
> ===================================================================
> RCS file: /usr/local/cvsroot/octave/src/mxarray.h,v
> retrieving revision 1.6
> diff -u -r1.6 mxarray.h
> --- src/mxarray.h     8 Mar 2007 22:58:23 -0000       1.6
> +++ src/mxarray.h     2 Jun 2007 21:32:28 -0000
> @@ -81,6 +81,14 @@
>  /* typedef Uint16 mxChar; */
>  typedef char mxChar;
>  
> +/* 
> + * FIXME? Mathworks says these should be size_t on 64-bit system and when
> + * mex is used with the -largearraydims flag, but why do that? Its better
> + * to conform to the same indexing as the rest of Octave
> + */
> +typedef octave_idx_type mwSize;
> +typedef octave_idx_type mwIndex;
> +
>  #if ! defined (MXARRAY_TYPEDEFS_ONLY)
>  
>  class octave_value;
>   
Except this part of the change is a problem as outside of Octave
octave_idx_type is not defined. I see two solutions. The first is just
to include oct-types.h in mxarray.h, though that might not be acceptable
as it introduces an externally visible dependency on the octave code for
the mex files. The second is to move mxarray.h to mxarray.h.in and have
the typedefs

typedef  @OCTAVE_IDX_TYPE@ mwSize;
typedef @OCTAVE_IDX_TYPE@ mwIndex;

then add myarray.h.in to AC_CONFIG_FILES in configure.in. John if you
accept the patch for the mex API changes which of these solutions for
the issue of octave_idx_type do you prefer?

D.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]