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. --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