Opened on 07/23/13 at 10:28:30

Last modified on 11/09/17 at 06:27:14

#2133 closed defect

<rtems/score/basedefs.h> superfluously includes <string.h> — at Version 10

Reported by: Sebastian Huber Owned by: Joel Sherrill
Priority: normal Milestone: 5.1
Component: score Version:
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description (last modified by Chris Johns)

In older RTEMS versions <rtems.h> provided <string.h> indirectly. The include
of <string.h> was added to not break application source files that relied on
this accidentally.

We may remove this include in the future.

Change History (10)

comment:1 Changed on 07/23/13 at 10:28:30 by Sebastian Huber

In older RTEMS versions <rtems.h> provided <string.h> indirectly. The include
of <string.h> was added to not break application source files that relied on
this accidentally.

We may remove this include in the future.

comment:2 Changed on 11/23/14 at 16:45:56 by Joel Sherrill

Description: modified (diff)

Can this be closed? The ticket is a warning about a change to basedefs.h and the comment makes no sense.

comment:3 Changed on 11/24/14 at 18:58:28 by Gedare Bloom

Version: HEAD → 4.11

Replace Version=HEAD with Version=4.11 for the tickets with Milestone >= 4.11

comment:4 Changed on 11/27/14 at 13:50:45 by Sebastian Huber

Milestone: 4.11 → 5.0

comment:5 Changed on 11/27/14 at 14:47:36 by Joel Sherrill

Out of curiosity, why shouldn't we just remove these includes now? There is no way to warn a user at compile time that they will be impacted. All we are doing is delaying the inevitable random number of users who are impacted. Hopefully that number is higher in the future than now.

My proposal is:

+ make a announcement to users@ and devel@ that these includes were removed and any

code that unintentionally depended on them will have compile errors or warnings.
This will serve as a hit in Google.

+ Remove it and see what tests break. Make sure the commits for those issues include

enough information in the log so Google will see those as related.

Break and move forward.

comment:6 in reply to:  5 Changed on 11/27/14 at 14:49:14 by Amar Takhar

Replying to joel.sherrill:

Out of curiosity, why shouldn't we just remove these includes now? There is no way to warn a user at compile time that they will be impacted. All we are doing is delaying the inevitable random number of users who are impacted. Hopefully that number is higher in the future than now.

All of these are moving in 5.0 anyway why bother moving it now when it works? I don't disagree with your reasoning but closing milestone:4.11 would be nice!

comment:7 Changed on 11/27/14 at 15:02:35 by Sebastian Huber

At the time I created the *impl.h header files, a lot of stuff broke due to the now missing indirect include. I guess this is also true for application code. Especially <string.h>. Maybe this include is a feature not a bug.

comment:8 Changed on 11/27/14 at 15:32:18 by Joel Sherrill

I agree on closing milestone 4.11 but this isn't the long pole in the tent. If we want to just get this behind us, let's do it. No point putting it off.

comment:9 Changed on 11/27/14 at 15:45:08 by Sebastian Huber

We still have the option to set this to WONTFIX and close it forever.

comment:10 Changed on 08/13/17 at 23:55:42 by Chris Johns

Description: modified (diff)
Milestone: 5.0 → 4.11.3

Please fix or close this ticket? Thanks.

Note: See TracTickets for help on using tickets.