Issues for general cleanup?

[boaks]

As mentioned in add ccm - comment on too many whitespace change the current code seems the have a mixed up format.

Therefore I would like to collect some input for a general cleanup.

From my side:

• whitespace format
• license update to EPL v2.0
• logging:
  • check messages (e.g. calls dtls_debug_dump already with a ":" at the end of the name),
  • remove eols ("\n") from the messages and add that to the print functions in dtls_debug.

Such general cleanups usually "locks the code for some time", so maybe it's also worth to get some feedback, what should be done before (e.g. merging selected open PRs).

[obgm]

One task would be to adjust existing code to follow the basic coding style outlined in CONTRIBUTING and enforce contributions to follow that style. In another project, I am currently testing a clang-format specification that does almost the right thing. (The problem with these tools is that you need to write a lot of annotations where you want to deviate from the strict formatting rules.)

[obgm]

Regarding license update: What would be the reasons for undergoing the enormous pain of changing the license model? I presume you would not do this unless there is something entirely wrong with the existing EPL v1.0/EDL v1.0.

[boaks]

I may be wrong, but I assume, a new release requires a 2.0.

enormous pain

Because the difference in the license?
It mainly enables the user to combine it with code under GPL, if they want/need to do so.

Or because the editing?
Tinydtls is tiny, the editing will be done fast.
For some coorporate user it may be also important to have a "SPDX-License-Identifier: EPL-?.0" in order to apply scanners. That would anyway cause the edit.

[obgm]

I may be wrong, but I assume, a new release requires a 2.0.

Okay, more reading to do for release preparation.

The pain arises from reading legal stuff: All tinydtls users will have to make their lawyers process the new license. It is not the editing that makes license changes difficult but the changed contents of the license. I have not yes compared the two documents or read discussions that may have commented on the changes but then again, this is exactly what I meant with "pain".

[boaks]

EPL-v1.0-FAQ

EPL-v2.0-FAQ

Diffs

EPL-1.0 has been deprecated

Yes, some may require to read it.
But many people and companies are common to EPL 2.0 and therefore I consider, that processing it by lawyers is a rare exception.
EPL 2.0 is not intended to make the use harder, it's intended to make it easier.

[boaks]

In another project, I am currently testing a clang-format specification that does almost the right thing. (The problem with these tools is that you need to write a lot of annotations where you want to deviate from the strict formatting rules.)

As long as the tool is used manually, that should not cause too much trouble. I would propose to go with one commit with the applied format, and one commit (maybe one per file), which need manual corrections of that.
I would propose, to spare out the included third-party stuff as, "aes/rijndael" or "sha2/sha2".

[boaks]

If agreed, we may also update the copyright times for the EPL files.

[boaks]

My first experience with ".clang-format" using VS Code is promising.
It's also possible to apply a change only on a change section.
FMPOV, using it manually and not automated, will make it possible to have a couple of "custom formatted sections" (hopefully not too much) while the main parts will be formatted accordingly.

(When it gets clear, how many section requires a custom format, we may consider again to use the "protection comments".)

[boaks]

Follow the coding conventions, e.g.:

static inline uint8_t
contains_cipher_suite(...args...) {

(The function name starts on its own line, the opening brace is on the same line as the last formal parameter.)

[mrdeep1]

As a comment, 74 of the git tracked files have lines that end in white space. Things code wise need to be stable before this is changed.

It can get a bit annoying, but I just now

$ cp .git/hooks/pre-commit.sample .git/hooks/pre-commit

which will then trap any files I am trying to commit with whitespace errors (have been doing this for some time in libcoap)

[boaks]

In my experience, it easier to do such cleanup on a "code-freeze" period.
Even if I don't know, when we will be ready with the pending PRs :-).

[boaks]

Discussing the use/design of macros in PR #217 showed, that we also need some rules for macros.
Any proposals?