octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #58795] ode15i and ode15s fail if sunindextype


From: Hg200
Subject: [Octave-bug-tracker] [bug #58795] ode15i and ode15s fail if sunindextype and octave_idx_type are incompatible
Date: Tue, 28 Jul 2020 09:33:09 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Follow-up Comment #19, bug #58795 (project octave):

I'm not yet sure about the exact root cause. As long as Octave's ode15 uses
the IDA-headers to create the data structures that are exchanged with the IDA
library, i would not expect casting problems, provided that sunindextype is
int64_t and octave_idx_type is int32_t. I.e. if a structure is packed, or
padded and how it is casted should not depend on the type of an index?

Another observation: Since I can't debug under windows, I made a build on my
64-bit Linux, with octave_idx_type set to int32_t, based on the ENABLE_64
switch, which in turn is set in configure.ac based on the configuration option
--disable-64. My expectation would have been to see the problem if the root
cause is a mismatch between octave_idx_type and sunindextype. But the ode
tests run smoothly. One could argue that i have Sundials 4.1.0 on Linux versus
5.3.0 on Windows MXE Octave, so it is not a proof. But it is a "try and
error".

However, if the root cause is a compatibility mismatch between the octave /
sundial indices: The sunindextype can be either int32_t or int64_t (default),
but it can't be unsigned. Fortunately, octave_idx_type is signed, although I
know there have been discussions about switching to unsigned (see bug #54405).
So up to know, the signedness is equal but the size can differ.

As you said, everything has changed since 5.2.0: Version number, __oct15__.cc
implementation, etc. So i am bit stuck what i could do next.

Regarding the patch: Yes, it feels "better" to have the same CMAKE switches
for other OS than Windows too. I will create an update.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58795>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

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