GCC 13 Status

[Sebastian Huber]

Hello,

the GCC 13 release candidates are available at the moment. Thanks to a 
last minute fix done by a GCC release manager all targets build for 
RTEMS (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566). TLS works 
now also on m68k (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106282).


The MicroBlaze support in GCC has a severe maintenance issue:

https://support.xilinx.com/s/question/0D54U6lA691SAC/microblaze-gcc-needs-proper-lra-support?language=en_US

A GCC 13 release branch version is available through the RTEMS 7 tools 
in the RSB.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Change build specification files from YAML to JSON?

[Chris Johns]

On 25/4/2023 5:35 pm, Sebastian Huber wrote:
> Tooling makes sense if you have a high change rate. 

That is not the use case I am discussing and it is not a factor.

> This is not the case for the RTEMS build specification items.

I am not saying it is.

> For which use case do we need tooling support?

We need tooling to lets us all understand this build system. YAML is easy to
learn however the data-structures, rules and the large number of file fragments
we have are complex and not apparent to anyone looking at it even if you have
invested time doing so. It reflects the fact that RTEMS is complicated to build.

I am advocate for what we have and will continue to be one so I am attempting to
address some things we could do better. History has shown the RTEMS core
developers are not great judges of the community's view of the project's
usability and accessibility.

The analogy is to consider the git command then the roles github and gitlab
provide with their user interfaces and tooling.

> For a new option or BSP, you just copy and past from existing files/BSPs.
> Changing a specific part of an existing file is just copy and paste some lines
> and edit them in most cases.

My experience tells me it is not as simple as this. There is an element of guess
work a change is right. The recent dependency cases highlighted this and the
need for checking of some form to be present in the rtems.git repo.

We need to step back and consider the role of the build system before we discuss
implementation details.

The first requirement by a large margin is ease of use for users and the
community to make contributions. Meeting this requirement can be done a number
of ways. For example a user focused format for the relationships rather than one
that aids machine integration. The original ground work Amar did for the move to
waf was to define the build in Python as documented by waf. It was simple and
transparent. Another example is a machine focused format however we need tooling
to help the users manage making changes and accessing what is happening without
needing to learn the details of how it is implemented.

For tooling my order of importance is:

1. Visualise the structures and dependencies in a human readable manner. An
indication of which file is doing what would be helpful.

2. A check of changes users make that raises errors, dependency problems, etc.
This can be a command you run if you are making changes and does not need to run
every build.

I see JSON and tooling as linked together. I also not expect complete tooling to
be present for the change to happen. All I am wanting is the need for tooling be
agreed on and it is located in rtems.git. The development can then happen and
evolve as the community sees a need.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Change build specification files from YAML to JSON?

[Chris Johns]

On 26/4/2023 4:01 am, Sebastian Huber wrote:
> On 25.04.23 13:02, Karel Gardas wrote:
>> On 4/25/23 12:32, Sebastian Huber wrote:
>>> On 25.04.23 12:10, Karel Gardas wrote:
 On 4/25/23 11:03, Sebastian Huber wrote:
>
>
> On 25.04.23 11:00, Karel Gardas wrote:
>> On 4/25/23 09:35, Sebastian Huber wrote:
>>> The change from YAML to JSON for the build specification files is just 
>>> an
>>> implementation detail of the new build system. For the users of the new
>>> build system nothing changes.
>>
>> Let me ask for clarification. Does this yaml -> json transition include
>> (or not) files in RTEMS spec directory, e.g. files here:
>>
>> https://git.rtems.org/rtems/tree/spec
>
> It would affect all YAML files in this directory and no other files.

 Oh. Let me ask, what is your future plan with the spec files? Considering
 you would like to move them to JSON, would you also like to provide some 
 DSL
 + compiler which would generates those? Or would you just like to keep JSON
 and have developers editing those?
>>>
>>> I would keep the JSON and have developer editing those.
>>>
>>> An alternative to changing the format could be to use the CSafeLoader of the
>>> system yaml module if it is available. It is not as fast as the JSON loader,
>>> but acceptable (0.65s to 0.2s on my machine for loading the items).
>>
>> Sorry for perhaps silly question, but why do you invest that much energy in
>> optimizing build speed -- by fraction of seconds here? I so far fail so to 
>> see
>> driving motivation force hence my question...
> 
> We have a fraction of a second if we use the CSafeLoader and no item cache.
> Currently we use the SafeLoader which results in about 5 seconds. I would like
> to use the build system for more stuff, so this could grow to 10, 15, or more
> seconds which then start to get annoying if you work frequently with it.

Then please outline what all you have in mind and what the long term plan is
then we can consider the overall direction.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Qemu and missing dynamic libraries

[Joel Sherrill]

On Mon, Apr 24, 2023 at 4:30 PM Chris Johns  wrote:

>
>
> On 25/4/2023 7:05 am, Joel Sherrill wrote:
> >
> >
> > On Mon, Apr 24, 2023 at 3:11 PM Karel Gardas 
> wrote:
> >
> > On 4/24/23 21:33, Joel Sherrill wrote:
> > >
> > >
> > > On Mon, Apr 24, 2023, 2:11 PM Karel Gardas 
> wrote:
> > >
> > >
> > > What have you done to this poor FBSD? ;-)
> >
> >
> > Nothing. :)
> >
> > I wonder when we started installing dynamic libraries with qemu.
> >
>
> Is there a static option to avoid shared libs?
>

Yes and adding it to the qemu configure line results in an error for glib.

+ ../qemu-5.2.0-rc1/configure --prefix=/home/joel/rtems-class/tools/6
--make=make --static --disable-werror --disable-tools --disable-pie
--disable-vnc --disable-sdl --disable-gtk --disable-opengl --disable-netmap
--disable-nettle

ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T.
   You probably need to set PKG_CONFIG_LIBDIR
   to point to the right pkg-config files for your
   build target

Maybe glib has an option for static also. No idea at this point.

Also we are using qemu 5 where qemu 8 was released last week.

And Alex is looking into qemu-xilinx breaking since it uses a branch
that references something that is no longer a valid URL in the xilinx
submodule setup.



--joel

>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Simplify _Objects_Is_api_valid()

[Joel Sherrill]

Commit it.

If mcdc-checker is happy with it, then I'm ok.

https://gtd-gmbh.gitlab.io/mcdc-checker/mcdc-checker/index.html is

On Tue, Apr 25, 2023 at 1:34 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> On 23.03.23 17:46, Joel Sherrill wrote:
> >
> >
> > On Thu, Mar 23, 2023 at 11:09 AM Sebastian Huber
> >  > > wrote:
> >
> > On 23.03.23 17:03, Joel Sherrill wrote:
> >  >
> >  > On Thu, Mar 23, 2023 at 10:40 AM Sebastian Huber
> >  >  > 
> >  >  > >> wrote:
> >  >
> >  > Close #4863.
> >  > ---
> >  >   cpukit/include/rtems/score/objectimpl.h | 4 +---
> >  >   1 file changed, 1 insertion(+), 3 deletions(-)
> >  >
> >  > diff --git a/cpukit/include/rtems/score/objectimpl.h
> >  > b/cpukit/include/rtems/score/objectimpl.h
> >  > index c58957ccb5..a1a87b5ccb 100644
> >  > --- a/cpukit/include/rtems/score/objectimpl.h
> >  > +++ b/cpukit/include/rtems/score/objectimpl.h
> >  > @@ -542,9 +542,7 @@ static inline bool _Objects_Is_api_valid(
> >  > uint32_t   the_api
> >  >   )
> >  >   {
> >  > -  if ( !the_api || the_api > OBJECTS_APIS_LAST )
> >  > -   return false;
> >  > -  return true;
> >  > +  return ( 1 <= the_api && the_api <= OBJECTS_APIS_LAST );
> >  >   }
> >  >
> >  >
> >  > I'd really prefer we avoid compound logical expressions since it
> >  > becomes something that needs MCDC analysis at higher levels
> >  > of verification/qualification.
> >
> > How does this simplify MC/DC analysis? The truth table doesn't
> > change if
> > I replace a short-circuit boolean expression with if + return.
> >
> >
> > gcov cannot directly do mcdc analysis but using simple expressions
> > avoids the introduction of those cases. So gcov reports can be equivalent
> > of an expensive MCDC analysis tool.
> >
> > I'm at the FSW this week and one of the NASA Johnson people shared
> > information on an open source tool and way to use gcov where you
> > are guaranteed to have gcov reports cover this. I'm going to experiment
> > with this when I get home. If it is as easy as it sounds, I'll write up
> > something
> > on the technique and we can discuss if we want to apply this to RTEMS.
> > I think we do since it would allow us to use gcov to ensure we do
> > MCDC level analysis as required by the highest level of all the safety
> > standards I know.
>
> Any news with respect to this topic?
>
> >
> >
> >  >
> >  > Please rewrite using simple logical expressions even if it means
> >  > two exit paths at the source leve. It's the same machine code.
> >
> > Yes.
>
> Do you really want to change
>
> static inline bool _Objects_Is_api_valid(
>uint32_t   the_api
> )
> {
>return ( 1 <= the_api && the_api <= OBJECTS_APIS_LAST );
> }
>
> in
>
> static inline bool _Objects_Is_api_valid(
>uint32_t   the_api
> )
> {
>if ( the_api < 1 ) {
>  return false;
>}
>
>if ( the_api > OBJECTS_APIS_LAST ) {
>  return false;
>}
>
>return true;
> }
>
> ?
>
> I am not really sure why we should do this.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Change build specification files from YAML to JSON?

[Sebastian Huber]

On 25.04.23 13:02, Karel Gardas wrote:

On 4/25/23 12:32, Sebastian Huber wrote:

On 25.04.23 12:10, Karel Gardas wrote:

On 4/25/23 11:03, Sebastian Huber wrote:



On 25.04.23 11:00, Karel Gardas wrote:

On 4/25/23 09:35, Sebastian Huber wrote:
The change from YAML to JSON for the build specification files is 
just an implementation detail of the new build system. For the 
users of the new build system nothing changes.


Let me ask for clarification. Does this yaml -> json transition 
include (or not) files in RTEMS spec directory, e.g. files here:


https://git.rtems.org/rtems/tree/spec


It would affect all YAML files in this directory and no other files.


Oh. Let me ask, what is your future plan with the spec files? 
Considering you would like to move them to JSON, would you also like 
to provide some DSL + compiler which would generates those? Or would 
you just like to keep JSON and have developers editing those?


I would keep the JSON and have developer editing those.

An alternative to changing the format could be to use the CSafeLoader 
of the system yaml module if it is available. It is not as fast as the 
JSON loader, but acceptable (0.65s to 0.2s on my machine for loading 
the items).


Sorry for perhaps silly question, but why do you invest that much energy 
in optimizing build speed -- by fraction of seconds here? I so far fail 
so to see driving motivation force hence my question...


We have a fraction of a second if we use the CSafeLoader and no item 
cache. Currently we use the SafeLoader which results in about 5 seconds. 
I would like to use the build system for more stuff, so this could grow 
to 10, 15, or more seconds which then start to get annoying if you work 
frequently with it.


Given the performance of the CSafeLoader I will probably use it and keep 
the YAML format.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Change build specification files from YAML to JSON?

[Karel Gardas]

On 4/25/23 12:32, Sebastian Huber wrote:

On 25.04.23 12:10, Karel Gardas wrote:

On 4/25/23 11:03, Sebastian Huber wrote:



On 25.04.23 11:00, Karel Gardas wrote:

On 4/25/23 09:35, Sebastian Huber wrote:
The change from YAML to JSON for the build specification files is 
just an implementation detail of the new build system. For the 
users of the new build system nothing changes.


Let me ask for clarification. Does this yaml -> json transition 
include (or not) files in RTEMS spec directory, e.g. files here:


https://git.rtems.org/rtems/tree/spec


It would affect all YAML files in this directory and no other files.


Oh. Let me ask, what is your future plan with the spec files? 
Considering you would like to move them to JSON, would you also like 
to provide some DSL + compiler which would generates those? Or would 
you just like to keep JSON and have developers editing those?


I would keep the JSON and have developer editing those.

An alternative to changing the format could be to use the CSafeLoader of 
the system yaml module if it is available. It is not as fast as the JSON 
loader, but acceptable (0.65s to 0.2s on my machine for loading the items).


Sorry for perhaps silly question, but why do you invest that much energy 
in optimizing build speed -- by fraction of seconds here? I so far fail 
so to see driving motivation force hence my question...


Thanks,
Karel




___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Change build specification files from YAML to JSON?

[Sebastian Huber]

On 25.04.23 12:10, Karel Gardas wrote:

On 4/25/23 11:03, Sebastian Huber wrote:



On 25.04.23 11:00, Karel Gardas wrote:

On 4/25/23 09:35, Sebastian Huber wrote:
The change from YAML to JSON for the build specification files is 
just an implementation detail of the new build system. For the users 
of the new build system nothing changes.


Let me ask for clarification. Does this yaml -> json transition 
include (or not) files in RTEMS spec directory, e.g. files here:


https://git.rtems.org/rtems/tree/spec


It would affect all YAML files in this directory and no other files.


Oh. Let me ask, what is your future plan with the spec files? 
Considering you would like to move them to JSON, would you also like to 
provide some DSL + compiler which would generates those? Or would you 
just like to keep JSON and have developers editing those?


I would keep the JSON and have developer editing those.

An alternative to changing the format could be to use the CSafeLoader of 
the system yaml module if it is available. It is not as fast as the JSON 
loader, but acceptable (0.65s to 0.2s on my machine for loading the items).


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Change build specification files from YAML to JSON?

[Karel Gardas]

On 4/25/23 11:03, Sebastian Huber wrote:



On 25.04.23 11:00, Karel Gardas wrote:

On 4/25/23 09:35, Sebastian Huber wrote:
The change from YAML to JSON for the build specification files is 
just an implementation detail of the new build system. For the users 
of the new build system nothing changes.


Let me ask for clarification. Does this yaml -> json transition 
include (or not) files in RTEMS spec directory, e.g. files here:


https://git.rtems.org/rtems/tree/spec


It would affect all YAML files in this directory and no other files.


Oh. Let me ask, what is your future plan with the spec files? 
Considering you would like to move them to JSON, would you also like to 
provide some DSL + compiler which would generates those? Or would you 
just like to keep JSON and have developers editing those?


Thanks,
Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Change build specification files from YAML to JSON?

[Sebastian Huber]

On 25.04.23 11:00, Karel Gardas wrote:

On 4/25/23 09:35, Sebastian Huber wrote:
The change from YAML to JSON for the build specification files is just 
an implementation detail of the new build system. For the users of the 
new build system nothing changes.


Let me ask for clarification. Does this yaml -> json transition include 
(or not) files in RTEMS spec directory, e.g. files here:


https://git.rtems.org/rtems/tree/spec


It would affect all YAML files in this directory and no other files.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Change build specification files from YAML to JSON?

[Karel Gardas]

On 4/25/23 09:35, Sebastian Huber wrote:
The change from YAML to JSON for the build specification files is just 
an implementation detail of the new build system. For the users of the 
new build system nothing changes.


Let me ask for clarification. Does this yaml -> json transition include 
(or not) files in RTEMS spec directory, e.g. files here:


https://git.rtems.org/rtems/tree/spec

Thanks!
Karel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Change build specification files from YAML to JSON?

[Sebastian Huber]

On 24.04.23 23:45, Chris Johns wrote:

On 25/4/2023 12:20 am, Sebastian Huber wrote:

On 24.04.23 16:17, Kinsey Moore wrote:

I think we've been moving away from in-file comments in the YAML and toward
actual labels in the data, anyway. If it's important information, it should be
kept properly.


Yes, there should be no comments in the build specification files. They would be
lost in YAML load/save cycle.


I am fine with json as a format. Comments are useful even for copyright notices
which would be lost. Is that OK?


We don't have comments in the build specification files. There is an 
attribute for copyright notices, for example:


SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
build-type: library
cflags:
- ${COVERAGE_COMPILER_FLAGS}
copyrights:
- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
cppflags: []



My concern is a major shift on top of a major change to waf so close together.
As a community we have only just started to get a number of people across what
we have and then things change? I see the counter point about making this happen
before 6 however I am still not sure what the cost/benefit is?


The change from YAML to JSON for the build specification files is just 
an implementation detail of the new build system. For the users of the 
new build system nothing changes. If we want to change to JSON, then 
this should definitely happen before the RTEMS 6 release or not at all. 
The cost of moving to JSON is that the file format is a bit more verbose 
(lots of " quotation). The benefit is a less complex wscript and faster 
build times. The change is trivial to do:


https://github.com/sebhub/rtems/commit/47c1e7218984ad0140d677d21c8526ec4fef653e

The JSON files produced by the Python json.dump(data2, out, 
sort_keys=True, indent=2) have a Git friendly format.


A bit problematic is multiline content:

https://github.com/sebhub/rtems/commit/47c1e7218984ad0140d677d21c8526ec4fef653e#diff-5a11531b07bc2a92e083a72414b45f96824a276a4dd925f9639cfc40081cba4b

We could work around this by using a list of lines.



The YAML lacks support tooling in rtems.git but it is usable as is. I am
concerned a move to json would compound the problem. On the other hand if we
considered json as the data could tooling mean we avoid hand editing?

If that was the approach how would we move to have tooling to help?


Tooling makes sense if you have a high change rate. This is not the case 
for the RTEMS build specification items. For which use case do we need 
tooling support? For a new option or BSP, you just copy and past from 
existing files/BSPs. Changing a specific part of an existing file is 
just copy and paste some lines and edit them in most cases.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Simplify _Objects_Is_api_valid()

[Sebastian Huber]

On 23.03.23 17:46, Joel Sherrill wrote:



On Thu, Mar 23, 2023 at 11:09 AM Sebastian Huber 
> wrote:


On 23.03.23 17:03, Joel Sherrill wrote:
 >
 > On Thu, Mar 23, 2023 at 10:40 AM Sebastian Huber
 > mailto:sebastian.hu...@embedded-brains.de>
 > >> wrote:
 >
 >     Close #4863.
 >     ---
 >       cpukit/include/rtems/score/objectimpl.h | 4 +---
 >       1 file changed, 1 insertion(+), 3 deletions(-)
 >
 >     diff --git a/cpukit/include/rtems/score/objectimpl.h
 >     b/cpukit/include/rtems/score/objectimpl.h
 >     index c58957ccb5..a1a87b5ccb 100644
 >     --- a/cpukit/include/rtems/score/objectimpl.h
 >     +++ b/cpukit/include/rtems/score/objectimpl.h
 >     @@ -542,9 +542,7 @@ static inline bool _Objects_Is_api_valid(
 >         uint32_t   the_api
 >       )
 >       {
 >     -  if ( !the_api || the_api > OBJECTS_APIS_LAST )
 >     -   return false;
 >     -  return true;
 >     +  return ( 1 <= the_api && the_api <= OBJECTS_APIS_LAST );
 >       }
 >
 >
 > I'd really prefer we avoid compound logical expressions since it
 > becomes something that needs MCDC analysis at higher levels
 > of verification/qualification.

How does this simplify MC/DC analysis? The truth table doesn't
change if
I replace a short-circuit boolean expression with if + return.


gcov cannot directly do mcdc analysis but using simple expressions
avoids the introduction of those cases. So gcov reports can be equivalent
of an expensive MCDC analysis tool.

I'm at the FSW this week and one of the NASA Johnson people shared
information on an open source tool and way to use gcov where you
are guaranteed to have gcov reports cover this. I'm going to experiment
with this when I get home. If it is as easy as it sounds, I'll write up 
something

on the technique and we can discuss if we want to apply this to RTEMS.
I think we do since it would allow us to use gcov to ensure we do
MCDC level analysis as required by the highest level of all the safety
standards I know.


Any news with respect to this topic?




 >
 > Please rewrite using simple logical expressions even if it means
 > two exit paths at the source leve. It's the same machine code.

Yes.


Do you really want to change

static inline bool _Objects_Is_api_valid(
  uint32_t   the_api
)
{
  return ( 1 <= the_api && the_api <= OBJECTS_APIS_LAST );
}

in

static inline bool _Objects_Is_api_valid(
  uint32_t   the_api
)
{
  if ( the_api < 1 ) {
return false;
  }

  if ( the_api > OBJECTS_APIS_LAST ) {
return false;
  }

  return true;
}

?

I am not really sure why we should do this.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel