Bug 74239 - int datatype in kst plugins and data sources is not 64-bit clean
Summary: int datatype in kst plugins and data sources is not 64-bit clean
Status: RESOLVED LATER
Alias: None
Product: kst
Classification: Applications
Component: plugins (show other bugs)
Version: 1.x
Platform: Compiled Sources Linux
: NOR major
Target Milestone: ---
Assignee: kst
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-02-05 15:41 UTC by George Staikos
Modified: 2006-03-21 00:31 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description George Staikos 2004-02-05 15:41:23 UTC 
We need to use 64-bit clean data types in Kst, in particular plugins and data 
sources.  We also need to use "long" explicitly to specify the length of 
vectors or amount of data read.  PIO uses long, and data streams can extremely 
large.
Comment 1 Netterfield 2004-02-05 17:28:49 UTC 
Subject: Re: [Kst]  New: int datatype in kst plugins and data sources is not 64-bit clean

Is there an architecture independent standard for how many bits each type is?

There wasn't 10 years ago (early DEC alpha days)....

cbn

On Thursday 05 February 2004 09:41 am, George Staikos wrote:
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
>
> http://bugs.kde.org/show_bug.cgi?id=74239
>            Summary: int datatype in kst plugins and data sources is not 64-
>                     bit clean
>            Product: kst
>            Version: unspecified
>           Platform: Compiled Sources
>         OS/Version: Linux
>             Status: NEW
>           Severity: major
>           Priority: NOR
>          Component: general
>         AssignedTo: kst@kde.org
>         ReportedBy: staikos@kde.org
>
>
> We need to use 64-bit clean data types in Kst, in particular plugins and
> data sources.  We also need to use "long" explicitly to specify the length
> of vectors or amount of data read.  PIO uses long, and data streams can
> extremely large.
> _______________________________________________
> Kst mailing list
> Kst@kde.org
> https://mail.kde.org/mailman/listinfo/kst
Comment 2 George Staikos 2004-02-06 05:41:19 UTC 
Subject: Re: [Kst]  New: int datatype in kst plugins and data sources is not 64-bit clean

Yes the plan is to use something similar to this approach...

On Thursday 05 February 2004 12:06, Ted Kisner wrote:
> I would recommend against ever explicitly using "long", as it can be either
> 32 or 64 bits depending on the platform.  What I've always done is use
> AC_CHECK_SIZEOF at build time to go through all standard C types and then
> define types that have a constant bit-width.
>
> Maybe there is an easier way to do this, but this is the best I've found...
>
> for example:
>
> configure.in
> --------------
> ...
> AC_CHECK_SIZEOF(int8,0)
> AC_CHECK_SIZEOF(int16,0)
> AC_CHECK_SIZEOF(int32,0)
> AC_CHECK_SIZEOF(int64,0)
> AC_CHECK_SIZEOF(uint8,0)
> AC_CHECK_SIZEOF(uint16,0)
> AC_CHECK_SIZEOF(uint32,0)
> AC_CHECK_SIZEOF(uint64,0)
> AC_CHECK_SIZEOF(float32,0)
> AC_CHECK_SIZEOF(float64,0)
> AC_CHECK_SIZEOF(char,0)
> AC_CHECK_SIZEOF(signed char,0)
> AC_CHECK_SIZEOF(unsigned char,0)
> AC_CHECK_SIZEOF(short int,0)
> AC_CHECK_SIZEOF(unsigned short int,0)
> AC_CHECK_SIZEOF(int,0)
> AC_CHECK_SIZEOF(unsigned int,0)
> AC_CHECK_SIZEOF(long int,0)
> AC_CHECK_SIZEOF(unsigned long int,0)
> AC_CHECK_SIZEOF(long long int,0)
> AC_CHECK_SIZEOF(unsigned long long int,0)
> AC_CHECK_SIZEOF(float,0)
> AC_CHECK_SIZEOF(double,0)
> ...
>
> Then, in some global header file
> ----------------------------------------------------
>
> /* set up some portable types of constant bit-width */
>
> #if SIZEOF_INT8 != 1
> #  undef int8
> #  if SIZEOF_SIGNED_CHAR == 1
> #    define int8 signed char
> #  elif SIZEOF_SHORT_INT == 1
> #    define int8 short int
> #  elif SIZEOF_INT == 1
> #    define int8 int
> #  elif SIZEOF_LONG_INT == 1
> #    define int8 long int
> #  elif SIZEOF_LONG_LONG_INT == 1
> #    define int8 long long int
> #  endif
> #endif
>
> #if SIZEOF_UINT8 != 1
> #  undef uint8
> #  if SIZEOF_UNSIGNED_CHAR == 1
> #    define uint8 unsigned char
> #  elif SIZEOF_UNSIGNED_SHORT_INT == 1
> #    define uint8 unsigned short int
> #  elif SIZEOF_UNSIGNED_INT == 1
> #    define uint8 unsigned int
> #  elif SIZEOF_UNSIGNED_LONG_INT == 1
> #    define uint8 unsigned long int
> #  elif SIZEOF_UNSIGNED_LONG_LONG_INT == 1
> #    define uint8 unsigned long long int
> #  endif
> #endif
>
> #if SIZEOF_INT16 != 2
> #  undef int16
> #  if SIZEOF_SIGNED_CHAR == 2
> #    define int16 signed char
> #  elif SIZEOF_SHORT_INT == 2
> #    define int16 short int
> #  elif SIZEOF_INT == 2
> #    define int16 int
> #  elif SIZEOF_LONG_INT == 2
> #    define int16 long int
> #  elif SIZEOF_LONG_LONG_INT == 2
> #    define int16 long long int
> #  endif
> #endif
>
> #if SIZEOF_UINT16 != 2
> #  undef uint16
> #  if SIZEOF_UNSIGNED_CHAR == 2
> #    define uint16 unsigned char
> #  elif SIZEOF_UNSIGNED_SHORT_INT == 2
> #    define uint16 unsigned short int
> #  elif SIZEOF_UNSIGNED_INT == 2
> #    define uint16 unsigned int
> #  elif SIZEOF_UNSIGNED_LONG_INT == 2
> #    define uint16 unsigned long int
> #  elif SIZEOF_UNSIGNED_LONG_LONG_INT == 2
> #    define uint16 unsigned long long int
> #  endif
> #endif
>
> #if SIZEOF_INT32 != 4
> #  undef int32
> #  if SIZEOF_SIGNED_CHAR == 4
> #    define int32 signed char
> #  elif SIZEOF_SHORT_INT == 4
> #    define int32 short int
> #  elif SIZEOF_INT == 4
> #    define int32 int
> #  elif SIZEOF_LONG_INT == 4
> #    define int32 long int
> #  elif SIZEOF_LONG_LONG_INT == 4
> #    define int32 long long int
> #  endif
> #endif
>
> #if SIZEOF_UINT32 != 4
> #  undef uint32
> #  if SIZEOF_UNSIGNED_CHAR == 4
> #    define uint32 unsigned char
> #  elif SIZEOF_UNSIGNED_SHORT_INT == 4
> #    define uint32 unsigned short int
> #  elif SIZEOF_UNSIGNED_INT == 4
> #    define uint32 unsigned int
> #  elif SIZEOF_UNSIGNED_LONG_INT == 4
> #    define uint32 unsigned long int
> #  elif SIZEOF_UNSIGNED_LONG_LONG_INT == 4
> #    define uint32 unsigned long long int
> #  endif
> #endif
>
> #if SIZEOF_INT64 != 8
> #  undef int64
> #  if SIZEOF_SIGNED_CHAR == 8
> #    define int64 signed char
> #  elif SIZEOF_SHORT_INT == 8
> #    define int64 short int
> #  elif SIZEOF_INT == 8
> #    define int64 int
> #  elif SIZEOF_LONG_INT == 8
> #    define int64 long int
> #  elif SIZEOF_LONG_LONG_INT == 8
> #    define int64 long long int
> #  endif
> #endif
>
> #if SIZEOF_UINT64 != 8
> #  undef uint64
> #  if SIZEOF_UNSIGNED_CHAR == 8
> #    define uint64 unsigned char
> #  elif SIZEOF_UNSIGNED_SHORT_INT == 8
> #    define uint64 unsigned short int
> #  elif SIZEOF_UNSIGNED_INT == 8
> #    define uint64 unsigned int
> #  elif SIZEOF_UNSIGNED_LONG_INT == 8
> #    define uint64 unsigned long int
> #  elif SIZEOF_UNSIGNED_LONG_LONG_INT == 8
> #    define uint64 unsigned long long int
> #  endif
> #endif
>
> #if SIZEOF_FLOAT32 != 4
> #  undef float32
> #  if SIZEOF_FLOAT == 4
> #    define float32 float
> #  elif SIZEOF_DOUBLE == 4
> #    define float32 double
> #  elif SIZEOF_LONG_DOUBLE == 4
> #    define float32 long double
> #  endif
> #endif
>
> #if SIZEOF_FLOAT64 != 8
> #  undef float64
> #  if SIZEOF_FLOAT == 8
> #    define float64 float
> #  elif SIZEOF_DOUBLE == 8
> #    define float64 double
> #  elif SIZEOF_LONG_DOUBLE == 8
> #    define float64 long double
> #  endif
> #endif
>
> Now you can use these types (float64, int32, etc) with confidence, knowing
> that they have the correct bitsize.
Comment 3 Mark Hymers 2004-08-29 11:09:36 UTC 
I agree that you need to do this for float32 and float64 but for integers can you not just use the C99 standard types included in <stdint.h>?  i.e. uint8_t, int8_t, uint16_t, int16_t, uint32_t, int32_t?

Would you accept a patch to implement this?
Comment 4 George Staikos 2004-09-06 01:59:21 UTC 
On Sunday 29 August 2004 05:09, Mark Hymers wrote:
> ------- I agree that you need to do this for float32 and float64 but for
> integers can you not just use the C99 standard types included in
> <stdint.h>?  i.e. uint8_t, int8_t, uint16_t, int16_t, uint32_t, int32_t?
>
> Would you accept a patch to implement this?

   It will have to take into account that some [perhaps many] Kst users do not 
have C99 compliant compilers yet.
Comment 5 Mark Hymers 2004-10-30 23:54:11 UTC 
Sorry I haven't had time to look at this recently.  Does this need to be fixed before the 1.0.0 release?  If so, I can try and get to it next week but can't promise anything.
Comment 6 George Staikos 2004-10-31 16:51:47 UTC 
On Saturday 30 October 2004 17:54, Mark Hymers wrote:
> ------- Sorry I haven't had time to look at this recently.  Does this need
> to be fixed before the 1.0.0 release?  If so, I can try and get to it next
> week but can't promise anything.

  I have 64bit hardware too, and yes it should be fixed.  The problem is 
making sure we don't break all the plugins out there.  (oooops..... almost 
too late already!)  I think I will discuss with the users in Paris next week 
to see what they think.  We might need to have a --enable-64bit-kst configure 
flag for now.
Comment 7 Netterfield 2005-12-11 07:21:18 UTC 
Plugins compiled on 64 bit work fine on 64 bit; this bug may (or may not) effect plugins compiled under 32 bit and run under 64 bit.  

This will not be fixed for the current plugin system, but needs to be remembered in designing the upgrade.  Lowering priority.
Comment 8 George Staikos 2006-03-21 00:31:20 UTC 
This will be addressed, if a problem at all, by the new plugin system.