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. > > Not accepting unicode should be checked for patches and should be in > Coding Conventions. > > I think you made a couple of bad mapping choices. > > - "(r)" for the registered symbol (circle R) > - "u" for the micro Greek letter in usec and us (which is strange for usec) > > 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. 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 > > --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
