rtems_fatal() as inline in a header file

[Pham, Phong]

Hi Sebastian,

I am only interested in moving rtems_fatal() implementation to a fatal.c (thus removing the inline) and leave the indirection issue alone.  Are you comfortable with this (b4 I do the work and checkin)?  In this manner, the API remain the same.

With regard to the message "Notice: This e-mail and any files transmitted with it may contain Data Device Corporation's privileged ..."

I don't have control of disabling the message (or maybe I don't know how).  Looks like it is automatically appended to the email.  If you like, I can switch to my personal email account whenever dealing with RTEMS (as long as you guys are comfortable with yahoo.com email).

Phong.

-----Original Message-----
From: Sebastian Huber [mailto:sebastian.huber at embedded-brains.de]
Sent: Wednesday, May 17, 2017 10:16 PM
To: Pham, Phong; rtems-devel at rtems.org
Cc: Hillman, Robert
Subject: Re: rtems_fatal() as inline in a header file



On 18/05/17 01:08, Pham, Phong wrote:
>
> Hi Developers,
>
> Currently:
> ...\rtems\cpukit\sapi\include\rtems\fatal.h
> <file:///%5C%5Ccentos%5Crtems-dev%5Crtems_0508%5Crtems%5Ccpukit%5Csapi
> %5Cinclude%5Crtems%5Cfatal.h>
>
> is implemented as
>
> RTEMS_NO_RETURN RTEMS_INLINE_ROUTINE void rtems_fatal(
>
>   rtems_fatal_source fatal_source,
>
>   rtems_fatal_code   error_code
>
> )
>
> {
>
>   _Terminate( fatal_source, error_code );
>
> }
>
> I suggest to move the implementation to fatal.c and remove
> RTEMS_INLINE_ROUTINE.  I just don't see a benefit to implement it as
> inline.
>

The rtems_fatal() is an API function documented in the user manual. The
_Terminate() is an internal function.

> Besides, it has disadvantages.  That is besides code size, during
> debugging, it simplifies the number of rtems_fatal symbol occurrences
> to 1.  Don't have to figure out which one is which.
>

Yes, for debugging you have to know that _Terminate() is the right function to set the break point. This is not really great. Maybe we should remove this indirection.

> bsp_fatal() is another one.
>
> Phong.
>
>
>           Notice: This e-mail and any files transmitted with it may
>           contain Data Device Corporation's privileged and proprietary
>           information. It is intended solely for the use of the
>           individual or entity to whom it is addressed. If you are not
>           the named recipient of this transmission, any disclosure,
>           copying, distribution or reliance on the contents of this
>           message is prohibited. If you received this e-mail in error,
>           please destroy it and any attached files and notify me
>           immediately.
>

Do you take this message serious?

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Notice: This e-mail and any files transmitted with it may contain Data Device Corporation's privileged and proprietary information. It is intended solely for the use of the individual or entity to whom it is addressed. If you are not the named recipient of this transmission, any disclosure, copying, distribution or reliance on the contents of this message is prohibited. If you received this e-mail in error, please destroy it and any attached files and notify me immediately.