UNSUPPORTED features - why not have some flexibility?
Hi all, I am working with Azure RTOS and from time to time I get in situations where there are protocols or other items unsupported by Azure. It make a lot of sense that Azure team dos not waste development time outside roadmap, no question. Nevertheless, some time we do need add these features; as today, only way is to patch Azure code and this is, in my mind, a true crime. There is a very nice way to solve this at zero cost. Every time there is a tree that ends into an error or discard for non supported item, add a macro that allows to add some code to any developer without modifying original code. Example: Azure ACTUAL CODE ***************************** if(protocolA){ ... } else if(protocolB){ ... } else { /* unsupported case */ error(); } ***************************** Proposed modification: ***************************** #define UNSUPPORTED_CASE_A if(protocolA){ ... } else if(protocolB){ ... } else { UNSUPPORTED_CASE_A; /* unsupported case */ error(); } ***************************** This allow to add user handling of unsupported feature, either implementing feature or just adding appropiate management instead of generic error or discard function. Adding undefined macro, will not weakens code quality, will not cost in code development, while it add flexibility to developers to custom handle unsupported cases. Any coment on this proposal? Mike Bargauan