On Wed, Jun 27, 2012 at 8:48 AM, JMGross <msp...@grossibaer.de> wrote: > > ----- Ursprüngliche Nachricht ----- > Von: Simeon Felis > Gesendet am: 27 Jun 2012 02:05:00 > >> Did I understand you right: The manual is wrong and should quote READ_SR >> instead of READ_SR()? > >> I wasn't used to errors in system headers, and was digging manuals, >> google and my code for hours, until I decided to look into the system >> headers. It wasn't obvious to find there, too. That wasn't fun at all >> and messed up my day. I thought this one-liner could save a lot of >> stress for other beginners like me. But: lessen learned ;) > > I fully understand your frustration. > However, some things have been wrong from the beginning and people > are used to use them wrong. > So deliberately (desperately) fixing them will break them for all others.
Yes. > I've seen this happening too often in the open source scene: > "This API implementation is to be considered wrong because of this > or that reason. So we 'fix' it in the next release and everyone who used > the old wrong API only has to patch his source code and recompile" > > And those software depending on the API will temporarily fail until a > new release is done, or permanently, if not maintained anymore. > This attitude has wiped many good tools from the planet. This is why LTS releases exist: API won't change in them unless it is absolutely impossible somebody could have been using it in its as-released form. Had I broken READ_SR sometime recently, it would have been a tougher call, since I will change things during a development series, thus resulting in a change in the next LTS release (normally this would be by adding a new capability rather than changing an existing interface, though). I assumed that's what happened until I went back to see where the error was introduced, so I could assess the impact of fixing it. Been that way since day one, though? It stays that way forever. Especially since it's a legacy interface; the right way to do that now is the __read_status_register() intrinsic. > JMGross > > P.s.: I also wish all this TIMER1_VECTOR/TIMER0_A1_VECTOR > confusion would vanish from the header files. But then, many > code examples wouldn't compile anymore. And those who require > them are definitely not in the position to patch them properly. > So I guess, we'll have to live with this until end of time. That's been fixed as much as it can be. See: https://sourceforge.net/tracker/?func=detail&aid=3484369&group_id=42303&atid=432701 Since this was done upstream, it should also be available in future IAR and CCS releases. Now all we need to do is convince TI not to hard-code device-specific headers in their generic examples, e.g. for the Launchpad. AFAICT <msp430.h> ought to work for everybody. Peter > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
