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

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

[Octave-bug-tracker] [bug #45411] cast fail at liboctave/util/oct-inttyp


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #45411] cast fail at liboctave/util/oct-inttypes.h on Sparc Solaris
Date: Sun, 26 Jul 2015 02:38:32 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15

Follow-up Comment #6, bug #45411 (project octave):

The signed vs. unsigned 8-bit type sounds about right.  Can't think of any
simple approach because there appears to be a lot going on with regard to the
definition.  In particular, these lines:


libgnu/stdint.in.h:   files, so that we can "#define int8_t signed char" below
without
libgnu/stdint.in.h:   signed char int8_t;" that will get messed up by our
macro.  Our
libgnu/stdint.in.h:#undef int8_t
libgnu/stdint.in.h:#undef uint8_t
libgnu/stdint.in.h:typedef signed char gl_int8_t;
libgnu/stdint.in.h:typedef unsigned char gl_uint8_t;
libgnu/stdint.in.h:#define int8_t gl_int8_t
libgnu/stdint.in.h:#define uint8_t gl_uint8_t
libgnu/stdint.in.h:#define int_least8_t int8_t
libgnu/stdint.in.h:#define uint_least8_t uint8_t


mess around with the definitions of int8_t and uint8_t.  Octave seems to be
assuming int8_t is signed, so if int8_t is undefined and some how redefined
with a "signed" qualifier it might be fine in terms of Octave's mathematical
treatment of related variable types.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?45411>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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