On Thu, Nov 5, 2020 at 2:42 PM Christian Mauderer <o...@c-mauderer.de> wrote:
> 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. > Well this is a challenge for another day. We can always use file and if gives the wrong answer, then we know something is broken in the file. > > >> > >> 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. > Thanks. > > >> > >> - "(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 ;-) > I have seen people use msec or ms for microsecond and that is wrong. I tend to like to see millisecond and microsecond spelled out unless there is a really good reason not to. Usually there is plenty of space to hedge on the side of perfect clarity. > > >> > >> 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