On 05/11/2020 21:28, Gedare Bloom wrote: > On Thu, Nov 5, 2020 at 1:14 PM Joel Sherrill <j...@rtems.org> wrote: >> >> I tried at one point to figure out how to script the changes when I ran into >> them. >> But it was easier to fix them by hand. If you have a simple script, it would >> be good >> to have a home for it. We could grow it then.
Sorry, I didn't use a script either. I just wanted to try a tool on a larger code base and blindly removed everything that has been a problem for it. >> >> Not accepting unicode should be checked for patches and should be in >> Coding Conventions. >> >> I think you made a couple of bad mapping choices. See above: The target was not to have a good choice but just to get rid of them. Never intended to create a real patch from it. But like I said: I'll polish it a bit and send patches. >> >> - "(r)" for the registered symbol (circle R) >> - "u" for the micro Greek letter in usec and us (which is strange for usec) For me "s" is a quite common short for seconds. And u is quite common for replacing a micro if there is no special micro character. Most likely in English there is a higher chance to mis-read it as an "us" like the one in "tell us something" and therefore the short form is considered strange ;-) >> >> Some I have no idea about. >> >> + aes.c - absolutely no idea >> + rtl22xx/console/uart.c - maybe an x >> + powerpc/include/mpc83xx/mpc83xx.h - maybe an x >> >> I think a patch series doing copyright symbols, (r), and u for micro >> as individual changes would eliminate a lot and not be controversial. >> That should leave the remaining for a second pass. >> >> One patch per character change is safer to review. > "per kind of character" > > feel free to send all the (C) together, etc. OK. > > I think the AES one is pTq, math notation for a vector product using > transpose. > > I used https://www.branah.com/unicode-converter and put the UTF-8 we > have in our repo in the box, and that gives some idea what it should > be in the top unicode box. i.e., put "¡°T¡±" in the UTF-8 box and see > what pops out on top That's a nice tool. Thanks for the hint. Best regards Christian > >> >> --joel >> >> >> On Thu, Nov 5, 2020 at 1:34 PM Christian Mauderer <o...@c-mauderer.de> wrote: >>> >>> Hello Joel, >>> >>> On 05/11/2020 20:15, Joel Sherrill wrote: >>>> >>>> >>>> On Thu, Nov 5, 2020, 1:12 PM Christian Mauderer <o...@c-mauderer.de >>>> <mailto:o...@c-mauderer.de>> wrote: >>>> >>>> Hello Joel and Sebastian, >>>> >>>> On 05/11/2020 16:44, Joel Sherrill wrote: >>>> > >>>> > >>>> > On Thu, Nov 5, 2020, 9:26 AM Sebastian Huber >>>> > <sebastian.hu...@embedded-brains.de >>>> <mailto:sebastian.hu...@embedded-brains.de> >>>> > <mailto:sebastian.hu...@embedded-brains.de >>>> <mailto:sebastian.hu...@embedded-brains.de>>> wrote: >>>> > >>>> > Hello, >>>> > >>>> > I review currently the Coding Conventions. Should the 80 >>>> characters >>>> > limit be really a 79 characters limit with the \n as the >>>> invisible 80th >>>> > character? >>>> > >>>> > >>>> > Yes. >>>> > >>>> > As old as this makes me feel, I remember printers which did an >>>> automatic >>>> > linefeed and then the newline one if you hit column 80. So it >>>> really is >>>> > 79 unfortunately. >>>> >>>> I don't think printers with an automatic linefeed are a common use case >>>> for reading the RTEMS source code nowadays. So that maybe isn't the >>>> best >>>> reason for using 79 characters. >>>> >>>> >>>> +1 >>>> >>>> >>>> I would suggest to use the same convention that most coding styles use >>>> which seems to be 80 characters: >>>> >>>> https://en.wikipedia.org/wiki/Characters_per_line#In_programming >>>> >>>> At least if there are no more recent examples for tools or editors >>>> where >>>> 79 is a benefit. 80 seems just feels a bit more natural. >>>> >>>> >>>> By the way: If we count '\n': Should we count a tab '\t' as a single >>>> character, as 2, as 4 or as 8 ones? >>>> >>>> >>>> We shouldn't have tabs in code we own. >>> >>> Good point. >>> >>>> >>>> What about the few Unicode >>>> characters that slipped in over the years? >>>> >>>> >>>> We also shouldn't have unicode characters randomly floating around. They >>>> tend to pop up in my experience when people copy from word processors >>>> and get fancy quotes. Those cases should be eliminated >>> >>> Last time I stumbled across a tool that didn't like unicode characters I >>> found about 75 lines in RTEMS with unicode characters. I have been to >>> lazy to fix them back then. Mostly because some of them would have >>> needed some thought about what there should have been (I assume it has >>> been a microsecond in some cases, but still not sure). Attached you can >>> find a patch that should replaces most of them without much thought >>> about the content. If you think it's useful, I can polish it up a bit. >>> >>> Best regards >>> >>> Christian >>> >>>> >>>> >>>> Best regards >>>> >>>> Christian >>>> >>>> > >>>> > >>>> > -- >>>> > embedded brains GmbH >>>> > Sebastian HUBER >>>> > Dornierstr. 4 >>>> > 82178 Puchheim >>>> > Germany >>>> > email: sebastian.hu...@embedded-brains.de >>>> <mailto:sebastian.hu...@embedded-brains.de> >>>> > <mailto:sebastian.hu...@embedded-brains.de >>>> <mailto:sebastian.hu...@embedded-brains.de>> >>>> > Phone: +49-89-18 94 741 - 16 >>>> > Fax: +49-89-18 94 741 - 08 >>>> > PGP: Public key available on request. >>>> > >>>> > embedded brains GmbH >>>> > 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 <mailto:devel@rtems.org> >>>> <mailto:devel@rtems.org <mailto:devel@rtems.org>> >>>> > http://lists.rtems.org/mailman/listinfo/devel >>>> > >>>> > >>>> > _______________________________________________ >>>> > devel mailing list >>>> > devel@rtems.org <mailto:devel@rtems.org> >>>> > http://lists.rtems.org/mailman/listinfo/devel >>>> > >>>> >> >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel