#3799 new defect

confdefs.h declares an array with zero elements, that's invalid C

Reported by: Jens Schweikhardt Owned by:
Priority: normal Milestone:
Component: rtems Version:
Severity: normal Keywords: confdefs.h array
Cc: Blocked By:
Blocking:

Description

I'm looking at rtems/cpukit/include/rtems/confdefs.h

1189	#ifdef CONFIGURE_INIT
1190	  RTEMS_DEFINE_GLOBAL_SYMBOL(
1191	    _ISR_Stack_size,
1192	    CONFIGURE_INTERRUPT_STACK_SIZE
1193	  );
1194	
1195	  char _ISR_Stack_area_begin[
1196	    _CONFIGURE_MAXIMUM_PROCESSORS * CONFIGURE_INTERRUPT_STACK_SIZE
1197	  ] RTEMS_ALIGNED( CPU_INTERRUPT_STACK_ALIGNMENT )
1198	  RTEMS_SECTION( ".rtemsstack.interrupt.begin" );
1199	
1200	  const char _ISR_Stack_area_end[ 0 ]
1201	    RTEMS_SECTION( ".rtemsstack.interrupt.end" ) = { };
1202	#endif

Note line 1200: const char _ISR_Stack_area_end[ 0 ]
This crashes (yes, it goes boom) one of our Static Analyzer tools (Mathworks Polyspace if you must know).

According to the ISO C11 Standard,

6.7.6.2 Array declarators

Constraints

1 In addition to optional type qualifiers and the keyword static, the [ and ] may delimit
an expression or *. If they delimit an expression (which specifies the size of an array), the
expression shall have an integer type. If the expression is a constant expression, it shall
have a value greater than zero.

Could this either be fixed to declare a one element array, or, if you must use 0 for some reason, be a macro that I can override for Polyspace?

Change History (5)

comment:1 Changed on Oct 4, 2019 at 1:36:37 PM by Sebastian Huber

See:

https://lists.rtems.org/pipermail/devel/2019-October/055804.html

I would write a bug report for the Mathworks Polyspace as well.

comment:2 Changed on Oct 7, 2019 at 5:07:53 AM by Sebastian Huber

Please test this patch set and check if it fixes the Mathworks Polyspace issue.

comment:3 Changed on Oct 7, 2019 at 7:16:55 AM by Jens Schweikhardt

It's difficult for me to apply the patch set since we use the RTEMS 5.x as shipped by Cobham/Gaisler? Research for their RCC 1.3-rc6-gcc. This differs enough from current RTEMS to make this a bit involved. However, I've locally patched it simply by changing [0] to [1] and Polyspace R2013a no longer crashes. I fully trust your patch set to fix this as well, so go ahead and close this as fixed. Thanks a lot for your work, Sebastian!

comment:4 Changed on Oct 9, 2019 at 2:38:45 PM by Joel Sherrill

Do you have any instructions or guidance for using Polyspace on RTEMS that could be place in the documentation?

comment:5 Changed on Oct 22, 2019 at 9:52:09 AM by Jens Schweikhardt

In general, Polyspace needs to see the same code the compiler sees. This requires that Polyspace needs to be told the compiler's predefined macros. With gcc or clang that's easy. To do that, ask for the predefined macros with $(CC) -E -dM -x c /dev/null and turn that into -D options for Polyspace.

In addition, you might want to fix/work around various language extensions Polyspace does not understand. I use

	-D __extension__=
	-D __builtin_va_list=void*
	-D __builtin_offsetof(t,m)=0
	-D _Noreturn=
	-D __restrict=

but this might need to be tweaked for your particular compiler and Polyspace release.

Note: See TracTickets for help on using tickets.