Skip to main content
Explorer II
September 2, 2025
Solved

UsbX example

  • September 2, 2025
  • 2 replies
  • 632 views

Hi ST,

 

i have one question for you. Could you please make "examples" more messy? Is it even possible? Lets see, i believe you can do it even worse. 

To be honest, i have never saw this nonsense and mess in my life. And i have also worked as ABAP developper. 

Have you ever heard about rule, that strongly recommends NOT to use "goto"? No? I thought so.

Have you ever heard about spaghetti code? Because you created one really huge. 

That example about UsbX for Stm32u5 is awfull. Who did it? Intern? Student? 

What is wrong with you? Even renesas is now better than you. 

    This topic has been closed for replies.
    Best answer by CTapp.1

    MISRA revised its guidance on the use of goto from "shall not be used" (required) in 2004 to "should not be used" (advisory) in 2012, in acknowledgement that, in a limited number of cases, the use of goto is the "correct" solution. At the same time, it introduced (required) guidance to limit how goto is used to prevent undesirable use.

    Changing the initial (2004) rule from "required" to "advisory" makes it much easier for a project to use goto when complying with the "required" rule that was introduced in 2012. It is also perfectly acceptable for a project to re-categorize the (now "advisory") rule as "required" or "mandatory", as is permitted under MISRA Compliance - meaning that the use of goto is either prohibited (when "mandatory"), or needs to be supported by a deviation (when "required"). MISRA re-worked the rules in this way to acknowledge that appropriate use should be easy whilst still allowing a project to prohibit its use entirely.

    Note that there are a number of other areas within MISRA where an "advisory" rule is used to recommend that a feature should not be used, with one or more "required" rules being used to restrict its use where that recommendation is not followed. This allows a project to determine which parts of the language are or are not permitted, allowing the guidelines to be more easily adopted by projects having different safety requirements.

    2 replies

    Super User
    September 2, 2025

    @Eiffel 

    Have you ever heard about rule, that strongly recommends NOT to use "goto"?

    AFAIK there's no such rule. Some projects and teams have their coding& style standards, others have other standards. In plain C, goto often helps reducing cyclomatic complexity.

     

    EiffelAuthor
    Explorer II
    September 4, 2025

    Every single project and team have coding style standards. 

    In plain C, goto cause mess. What about to use longjump? Where it will end? Why not to write code directly in main function.

    The use of goto is just poor experience. Same as while loops in HAL codes. 

    Super User
    September 4, 2025

    Obviously you are not familiar with Linux kernel codebase.

    Well, people get used to any circumstances, even to MISRA  :persevering_face: or AUTOSAR conventions - and like them.

     

    CTapp.1Answer
    Graduate II
    September 18, 2025

    MISRA revised its guidance on the use of goto from "shall not be used" (required) in 2004 to "should not be used" (advisory) in 2012, in acknowledgement that, in a limited number of cases, the use of goto is the "correct" solution. At the same time, it introduced (required) guidance to limit how goto is used to prevent undesirable use.

    Changing the initial (2004) rule from "required" to "advisory" makes it much easier for a project to use goto when complying with the "required" rule that was introduced in 2012. It is also perfectly acceptable for a project to re-categorize the (now "advisory") rule as "required" or "mandatory", as is permitted under MISRA Compliance - meaning that the use of goto is either prohibited (when "mandatory"), or needs to be supported by a deviation (when "required"). MISRA re-worked the rules in this way to acknowledge that appropriate use should be easy whilst still allowing a project to prohibit its use entirely.

    Note that there are a number of other areas within MISRA where an "advisory" rule is used to recommend that a feature should not be used, with one or more "required" rules being used to restrict its use where that recommendation is not followed. This allows a project to determine which parts of the language are or are not permitted, allowing the guidelines to be more easily adopted by projects having different safety requirements.

    Super User
    September 18, 2025

    You have lifted the heavy stone from my heart, Mr. Tapp.