80 or 79 characters limit?

Joel Sherrill joel at rtems.org
Thu Nov 5 20:41:28 UTC 2020 

On Thu, Nov 5, 2020 at 2:28 PM Gedare Bloom <gedare at rtems.org> wrote:

> On Thu, Nov 5, 2020 at 1:14 PM Joel Sherrill <joel at 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.
>

+1

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

I was hoping you weren't rickrolling us but that's a neat site. :)

I think your translation is right.

--joel

>
> >
> > --joel
> >
> >
> > On Thu, Nov 5, 2020 at 1:34 PM Christian Mauderer <oss at 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 <oss at c-mauderer.de
> >> > <mailto:oss at 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.huber at embedded-brains.de
> >> >     <mailto:sebastian.huber at embedded-brains.de>
> >> >     > <mailto:sebastian.huber at embedded-brains.de
> >> >     <mailto:sebastian.huber at 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.huber at embedded-brains.de
> >> >     <mailto:sebastian.huber at embedded-brains.de>
> >> >     >     <mailto:sebastian.huber at embedded-brains.de
> >> >     <mailto:sebastian.huber at 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 at rtems.org <mailto:devel at rtems.org>
> >> >     <mailto:devel at rtems.org <mailto:devel at rtems.org>>
> >> >     >     http://lists.rtems.org/mailman/listinfo/devel
> >> >     >
> >> >     >
> >> >     > _______________________________________________
> >> >     > devel mailing list
> >> >     > devel at rtems.org <mailto:devel at rtems.org>
> >> >     > http://lists.rtems.org/mailman/listinfo/devel
> >> >     >
> >> >
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201105/6f654049/attachment-0001.html>

More information about the devel mailing list