Skip to main content
edited body
Source Link
ideasman42
  • 913
  • 8
  • 18

Currently I'm working on a C/C++ code-base which is fairly portable, it can compile on most Unix like systems as well as MS-Windows (MSVC), using various popular compilers.

Previously I've found testing on different OS's and architectures can help find obscure bugs or bad assumptions.

I worry with the dominance of x86/amd64 our code-base may unknowingly become less portable.

Besides testing on a big-endian system (to find obvious errors with big/little endian), are there some architectures which have characteristics making them better for stress-testing software portability.?

Examples of possible differences.

  • different endian.
  • different behavior when threading.
  • behavior of stack memory.
  • size of primitive types (char, short, int, long, float... etc).
  • alignment/padding of structs (which might hide errors).
  • difference in optimizations made by the compiler.

Are there some architectures which have more significant differences to x86/amd64, making them better candidates for exposing code portability issues? (and have C/C++ compilers and libraries - libc, libstdc++).

Asking because its a sizable time-investment to setup a new system, even if its emulated.


in case its not clear what I mean by processor-architectures, eg (x86, amd64, ia64, mips, risc, arm, m68k, ppc, itanium)


Note, I'm not proposing this as a primary way to discover bugs, we run multiple static analysis tools and tests, but in the past we have found errors in code because of differences in less common platforms (SGI, SPARC, Solaris, BSD's etc. However some of these systems are fading out of use)

Currently I'm working on a C/C++ code-base which is fairly portable, it can compile on most Unix like systems as well as MS-Windows (MSVC), using various popular compilers.

Previously I've found testing on different OS's and architectures can help find obscure bugs or bad assumptions.

I worry with the dominance of x86/amd64 our code-base may unknowingly become less portable.

Besides testing on a big-endian system (to find obvious errors with big/little endian), are there some architectures which have characteristics making them better for stress-testing software portability.

Examples of possible differences.

  • different endian.
  • different behavior when threading.
  • behavior of stack memory.
  • size of primitive types (char, short, int, long, float... etc).
  • alignment/padding of structs (which might hide errors).
  • difference in optimizations made by the compiler.

Are there some architectures which have more significant differences to x86/amd64, making them better candidates for exposing code portability issues? (and have C/C++ compilers and libraries - libc, libstdc++).

Asking because its a sizable time-investment to setup a new system, even if its emulated.


in case its not clear what I mean by processor-architectures, eg (x86, amd64, ia64, mips, risc, arm, m68k, ppc, itanium)


Note, I'm not proposing this as a primary way to discover bugs, we run multiple static analysis tools and tests, but in the past we have found errors in code because of differences in less common platforms (SGI, SPARC, Solaris, BSD's etc. However some of these systems are fading out of use)

Currently I'm working on a C/C++ code-base which is fairly portable, it can compile on most Unix like systems as well as MS-Windows (MSVC), using various popular compilers.

Previously I've found testing on different OS's and architectures can help find obscure bugs or bad assumptions.

I worry with the dominance of x86/amd64 our code-base may unknowingly become less portable.

Besides testing on a big-endian system (to find obvious errors with big/little endian), are there some architectures which have characteristics making them better for stress-testing software portability?

Examples of possible differences.

  • different endian.
  • different behavior when threading.
  • behavior of stack memory.
  • size of primitive types (char, short, int, long, float... etc).
  • alignment/padding of structs (which might hide errors).
  • difference in optimizations made by the compiler.

Are there some architectures which have more significant differences to x86/amd64, making them better candidates for exposing code portability issues? (and have C/C++ compilers and libraries - libc, libstdc++).

Asking because its a sizable time-investment to setup a new system, even if its emulated.


in case its not clear what I mean by processor-architectures, eg (x86, amd64, ia64, mips, risc, arm, m68k, ppc, itanium)


Note, I'm not proposing this as a primary way to discover bugs, we run multiple static analysis tools and tests, but in the past we have found errors in code because of differences in less common platforms (SGI, SPARC, Solaris, BSD's etc. However some of these systems are fading out of use)

Tweeted twitter.com/#!/StackProgrammer/status/496007016146804736
added 41 characters in body
Source Link
ideasman42
  • 913
  • 8
  • 18

Currently I'm working on a C/C++ code-base which is fairly portable, it can compile on most Unix like systems as well as MS-Windows (MSVC), using various popular compilers.

Previously I've found testing on different OS's and architectures can help find obscure bugs or bad assumptions.

I worry with the dominance of x86/amd64 our code-base may unknowingly become less portable.

Besides testing on a big-endian system (to find obvious errors with big/little endian), are there some architectures which have characteristics making them better for stress-testing software portability.

Examples of possible differences.

  • different endian.
  • different behavior when threading.
  • behavior of stack memory.
  • size of primitive types (char, short, int, long, float... etc).
  • alignment/padding of structs (which might hide errors).
  • difference in optimizations made by the compiler.

Are there some architectures which have more significant differences to x86/amd64, making them better candidates for exposing code portability issues? (and have C/C++ compilers and libraries - libc, libstdc++).

Asking because its a sizable time-investment to setup a new system, even if its emulated.


in case its not clear what I mean by processor-architectures, eg (x86, amd64, ia64, mips, risc, arm, m68k, ppc, itanium)


Note, I'm not proposing this as a primary way to discover bugs, we run multiple static analysis tools and tests, but in the past we have found errors in code because of differences in less common platforms (SGI, SPARC, Solaris, BSD's etc. However some of these systems are fading out of use)

Currently I'm working on a C/C++ code-base which is fairly portable, it can compile on most Unix like systems as well as MS-Windows (MSVC), using various popular compilers.

Previously I've found testing on different OS's and architectures can help find obscure bugs or bad assumptions.

I worry with the dominance of x86/amd64 our code-base may unknowingly become less portable.

Besides testing on a big-endian system (to find obvious errors with big/little endian), are there some architectures which have characteristics making them better for stress-testing software portability.

Examples of possible differences.

  • different endian.
  • different behavior when threading.
  • behavior of stack memory.
  • size of primitive types (char, short, int, long, float... etc).
  • alignment/padding of structs (which might hide errors).
  • difference in optimizations made by the compiler.

Are there some architectures which have more significant differences to x86/amd64, making them better candidates for exposing code portability issues? (and have C/C++ compilers and libraries - libc, libstdc++).

Asking because its a sizable time-investment to setup a new system, even if its emulated.


in case its not clear what I mean by processor-architectures, eg (x86, amd64, ia64, mips, risc, arm, m68k, ppc, itanium)


Note, I'm not proposing this as a primary way to discover bugs, we run multiple static analysis tools and tests, but in the past we have found errors in code because of differences in less common platforms (SGI, SPARC, Solaris, BSD's etc)

Currently I'm working on a C/C++ code-base which is fairly portable, it can compile on most Unix like systems as well as MS-Windows (MSVC), using various popular compilers.

Previously I've found testing on different OS's and architectures can help find obscure bugs or bad assumptions.

I worry with the dominance of x86/amd64 our code-base may unknowingly become less portable.

Besides testing on a big-endian system (to find obvious errors with big/little endian), are there some architectures which have characteristics making them better for stress-testing software portability.

Examples of possible differences.

  • different endian.
  • different behavior when threading.
  • behavior of stack memory.
  • size of primitive types (char, short, int, long, float... etc).
  • alignment/padding of structs (which might hide errors).
  • difference in optimizations made by the compiler.

Are there some architectures which have more significant differences to x86/amd64, making them better candidates for exposing code portability issues? (and have C/C++ compilers and libraries - libc, libstdc++).

Asking because its a sizable time-investment to setup a new system, even if its emulated.


in case its not clear what I mean by processor-architectures, eg (x86, amd64, ia64, mips, risc, arm, m68k, ppc, itanium)


Note, I'm not proposing this as a primary way to discover bugs, we run multiple static analysis tools and tests, but in the past we have found errors in code because of differences in less common platforms (SGI, SPARC, Solaris, BSD's etc. However some of these systems are fading out of use)

added 8 characters in body
Source Link
ideasman42
  • 913
  • 8
  • 18

Currently I'm working on a C/C++ code-base which is fairly portable, it can compile on most Unix like systems as well as MS-Windows (MSVC), using various popular compilers.

Previously I've found testing on different OS's and architectures can help find obscure bugs or bad assumptions.

I worry with the dominance of x86/amd64 our code-base may unknowingly become less portable.

Besides testing on a big-endian system (to find obvious errors with big/little endian), are there some architectures which have characteristics making them better for stress-testing software portability.

Examples of possible differences.

  • different endian.
  • different behavior when threading.
  • behavior of stack memory.
  • size of primitive types (char, short, int, long, float... etc).
  • alignment/padding of structs (which might hide errors).
  • difference in optimizations made by the compiler.

Are there some architectures which have more significant differences to x86/amd64, making them better candidates for exposing code portability issues? (and have C/C++ compilers and libraries - libc, libstdc++).

Asking because its a sizable time-investment to setup a new system, even if its emulated.


in case its not clear what I mean by processor-architectures, eg (x86, amd64, ia64, mips, risc, arm, m68k, ppc, itanium)


Note, I'm not proposing this as a primary way to discover bugs, we run multiple static analysis tools and tests, but in the past we have found errors in code because of differences in less common platforms (SGI, SPARC, Solaris, BSD's etc)

Currently I'm working on a C/C++ code-base which is fairly portable, it can compile on most Unix like systems as well as MS-Windows (MSVC), using various popular compilers.

Previously I've found testing on different OS's and architectures can help find obscure bugs or bad assumptions.

I worry with the dominance of x86/amd64 our code-base may unknowingly become less portable.

Besides testing on a big-endian system (to find obvious errors with big/little endian), are there some architectures which have characteristics making them better for stress-testing software portability.

Examples of possible differences.

  • different endian.
  • different behavior when threading.
  • behavior of stack memory.
  • size of primitive types (char, short, int, long, float... etc).
  • alignment/padding of structs (which might hide errors).
  • difference in optimizations made by the compiler.

Are there some architectures which have more significant differences to x86/amd64, making them better candidates for exposing code portability issues? (and have C/C++ compilers and libraries - libc, libstdc++).

Asking because its a sizable time-investment to setup a new system, even if its emulated.


in case its not clear what I mean by processor-architectures, eg (x86, amd64, ia64, mips, risc, arm, m68k, ppc, itanium)

Currently I'm working on a C/C++ code-base which is fairly portable, it can compile on most Unix like systems as well as MS-Windows (MSVC), using various popular compilers.

Previously I've found testing on different OS's and architectures can help find obscure bugs or bad assumptions.

I worry with the dominance of x86/amd64 our code-base may unknowingly become less portable.

Besides testing on a big-endian system (to find obvious errors with big/little endian), are there some architectures which have characteristics making them better for stress-testing software portability.

Examples of possible differences.

  • different endian.
  • different behavior when threading.
  • behavior of stack memory.
  • size of primitive types (char, short, int, long, float... etc).
  • alignment/padding of structs (which might hide errors).
  • difference in optimizations made by the compiler.

Are there some architectures which have more significant differences to x86/amd64, making them better candidates for exposing code portability issues? (and have C/C++ compilers and libraries - libc, libstdc++).

Asking because its a sizable time-investment to setup a new system, even if its emulated.


in case its not clear what I mean by processor-architectures, eg (x86, amd64, ia64, mips, risc, arm, m68k, ppc, itanium)


Note, I'm not proposing this as a primary way to discover bugs, we run multiple static analysis tools and tests, but in the past we have found errors in code because of differences in less common platforms (SGI, SPARC, Solaris, BSD's etc)

added 8 characters in body
Source Link
ideasman42
  • 913
  • 8
  • 18
Loading
edited body
Source Link
ideasman42
  • 913
  • 8
  • 18
Loading
Source Link
ideasman42
  • 913
  • 8
  • 18
Loading