I see that those comments are there starting from the initial commit. Maybe
f...@feedforward.com.cn can update those comments to something readable
(added to recipients list)?
Best regards,
Petro
пн, 10 жовт. 2022 р. о 19:05 Fotis Panagiotopoulos
пише:
> I used the following two commands to che
I used the following two commands to check for non-ASCII characters within
the codebase:
find . -name "*.h" -exec grep --color='auto' -P -n "[\x80-\xFF]" {} \;
find . -name "*.c" -exec grep --color='auto' -P -n "[\x80-\xFF]" {} \;
The problematic characters are very few.
I could only see two nam
> nxstyle should only complain if this is a source or build file, right?
> And only if if the unicode is outside of a comment. Unicode characters
> are useful in .txtf, .md, a probably other file typles and also in code
> comments.
Of course I am talking strictly about .h/.c files. Documentation
I am not a attorney, but I seem to recall that a legal reference
reference to a copyright or a trademark require the © and small tm
superscript .
This -- plus the names that Brennan mentions -- are some of the reasons
why unicode really needs to be permitted within comments. None of these
sh
nxstyle should only complain if this is a source or build file, right?
And only if if the unicode is outside of a comment. Unicode characters
are useful in .txtf, .md, a probably other file typles and also in code
comments.
There are flags in nxstyle that tells if you the type of file (by
e
Some of these are are people's names or in documentation, I don't see any
reason to update that. Things like mu or I2C seems reasonable to convert
for searchability.
--Brennan
On Mon, Oct 10, 2022, 8:33 AM Fotis Panagiotopoulos
wrote:
> Shall I enhance nxstyle to check for this? Is this the c
Shall I enhance nxstyle to check for this? Is this the correct place for
this check?
On Mon, Oct 10, 2022 at 6:30 PM Alin Jerpelea wrote:
> Let's remove them!
>
> Thanks for looking into this issue
>
> Best Regards
> Alin
>
> On Mon, 10 Oct 2022, 17:25 Alan C. Assis, wrote:
>
> > Agree! It is b
Let's remove them!
Thanks for looking into this issue
Best Regards
Alin
On Mon, 10 Oct 2022, 17:25 Alan C. Assis, wrote:
> Agree! It is better to avoid it.
>
> On 10/10/22, Fotis Panagiotopoulos wrote:
> > Hello!
> >
> > A few weeks ago I had some problems with a static analysis tool that
> >
Agree! It is better to avoid it.
On 10/10/22, Fotis Panagiotopoulos wrote:
> Hello!
>
> A few weeks ago I had some problems with a static analysis tool that
> couldn't parse NuttX code, due to non-Unicode characters. I provided a
> couple of PRs and fixed the issues, but it got me thinking...
>
>
