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