Embedded Coder Portable Word Sizes Issue (Code was generated for compiler with different sized X)

I am working on a Simulink Coder project where we have a number of export function model references being built by a single top-level export function model, porting the resulting code over to an external application we are developing. We are then running the full codebase through Polyspace Access to verify MISRA compliance. When we get to the compilation step in Polyspace Access, it is failing on a single file; one of the MODEL_private.h files among the dozens generated for the code has a block of precompiler checks, and ALL of the #errors are being flagged, despite all of the defined constants in our GNU version's limits.h file matching the checks below:

/*
 * File: MODEL_private.h
 *
 * Code generated for Simulink model 'MODEL'.
 *
 * Model version                  : 3.307
 * Simulink Coder version         : 9.5 (R2021a) 14-Nov-2020
 *
 * Target selection: ert.tlc
 * Embedded hardware selection: ARM Compatible->ARM Cortex
 * Code generation objectives:
 *    1. MISRA C:2012 guidelines
 *    2. Execution efficiency
 *    3. Debugging
 * Validation result: Not run
 */

#ifndef RTW_HEADER_MODEL_private_h_
#define RTW_HEADER_MODEL_private_h_
#include "rtwtypes.h"
#ifndef PORTABLE_WORDSIZES
#ifndef UCHAR_MAX
#include <limits.h>
#endif

#if ( UCHAR_MAX != (0xFFU) ) || ( SCHAR_MAX != (0x7F) )
#error Code was generated for compiler with different sized uchar/char. \
Consider adjusting Test hardware word size settings on the \
Hardware Implementation pane to match your compiler word sizes as \
defined in limits.h of the compiler. Alternatively, you can \
select the Test hardware is the same as production hardware option and \
select the Enable portable word sizes option on the Code Generation > \
Verification pane for ERT based targets, which will disable the \
preprocessor word size checks.
#endif

#if ( USHRT_MAX != (0xFFFFU) ) || ( SHRT_MAX != (0x7FFF) )
#error Code was generated for compiler with different sized ushort/short. \
Consider adjusting Test hardware word size settings on the \
Hardware Implementation pane to match your compiler word sizes as \
defined in limits.h of the compiler. Alternatively, you can \
select the Test hardware is the same as production hardware option and \
select the Enable portable word sizes option on the Code Generation > \
Verification pane for ERT based targets, which will disable the \
preprocessor word size checks.
#endif

#if ( UINT_MAX != (0xFFFFFFFFU) ) || ( INT_MAX != (0x7FFFFFFF) )
#error Code was generated for compiler with different sized uint/int. \
Consider adjusting Test hardware word size settings on the \
Hardware Implementation pane to match your compiler word sizes as \
defined in limits.h of the compiler. Alternatively, you can \
select the Test hardware is the same as production hardware option and \
select the Enable portable word sizes option on the Code Generation > \
Verification pane for ERT based targets, which will disable the \
preprocessor word size checks.
#endif

#if ( ULONG_MAX != (0xFFFFFFFFU) ) || ( LONG_MAX != (0x7FFFFFFF) )
#error Code was generated for compiler with different sized ulong/long. \
Consider adjusting Test hardware word size settings on the \
Hardware Implementation pane to match your compiler word sizes as \
defined in limits.h of the compiler. Alternatively, you can \
select the Test hardware is the same as production hardware option and \
select the Enable portable word sizes option on the Code Generation > \
Verification pane for ERT based targets, which will disable the \
preprocessor word size checks.
#endif
#endif     

We have the same configuration being used as a configuration reference for all of the models in our project, and the configuration has Portable Word Sizes enabled. Does anyone know why this block of checks is being generated for only a single file? Why would these checks fail if my limits.h file values match the 3defines in this block?

Answer 1

[samil]

I had the same problem when I copied code generated on Windows 64 to Linux 64. On 64-bit Windows, the long type is typically 32 bits, which causes the LONG_MAX to be 0x7FFFFFFF. On 64-bit Linux systems, the long type is typically 64 bits, i.e. LONG_MAX is 0x7FFFFFFFFFFFFFFF. When you use code generated with the Windows 64 setting and use that on a Linux 64 OS, the check in <model name>_private.h will fail. The solution is to use the Linux 64 setting for Simulink Configuration Parameters - Hardware Implementation - Device type which removes the LONG_MAX check from header file.

[Dana Schwanke]

Unfortunately, this is not the case for us. We are doing embedded code development and the code base is not being copied across platforms or projects. We are using a custom Device type based on the embedded chip the code is being designed for.