Spelling

[jsoref]

Generated by https://github.com/jsoref/spelling f; to maintain your repo, please consider fchurn

Notes:

• I try to tag things I'm less sure of w/ ??
• I'm usually more thorough about figuring out which items are third party libraries. For this repo, I didn't. If code comes from an upstream, let me know and I'll shift the changes from this PR to a PR/similar for that upstream
• @defgroup some instances of this are of the form @defgroup foo foo and others were of the form @defgroup foot foo -- I didn't see any particular indication as to why there was a divergence and some fraction of the time I dropped the trailing t and I think I generally included ?? in my commit messages
• I generally try to enforce a single spelling for a word. (In some cases for this repo, I let multiple spellings remain as one was dominant and another appeared to be coming from a dependency.)
• I generally express a preference between en-US and en-GB, although I didn't apply it much here (mostly synchroniz*)
• I do try to ignore files (you can see what I ignored by looking at https://github.com/strongswan/strongswan/compare/master...jsoref:ignore?expand=1) -- if there are additional files/paths I should ignore, let me know, I just add them (i.e. remove them) in that branch and rebase my work and then rebase back onto master
• Sometimes I try to address indentation damage when I make changes, I didn't for this repository. I'd rather do that once people are happy w/ the general changes as such things increase the pain of merging/rebasing while I'm working on a PR.
• Names, email addresses, brands, domains: I generally assume people aren't intentionally misspelling an entity, e.g. strongwan / stronswan. My preference is that for samples things be clearly distinct as opposed to "oh, that's a typo".
• Yes, I've changed function names, defines, local variables, as well as comments, documentation, and the occasional license header.
• I'm willing to split things into a limited number of distinct PRs as requested
• I prefer to squash at the very end, as it's much harder to deal w/ merge conflicts once my changes are squashed.

[tobiasbrunner]

Thanks a lot for this. The number of typos found is quite impressive considering that we regularly use codespell :) Then again, that uses a relatively small list of common misspellings.

I've added some comments.

[jsoref]

I'm not sure I'll have time tonight, in which case I'll get to this on the weekend.

I'm not terribly surprised at the amount of finds even with your use of codespell, as I've run this tool on other projects that use it. It's obviously better than nothing. And until fairly recently, I haven't offered a user friendly way to integrate my tooling. (I'm finally writing my third round of integrations this week. The first was for checkstyle, the second was removed as it was too painful for a group, and the third I just turned on for my employer yesterday.) As I'm improving my tooling, I'm probably at the point where I could easily generate a table and statistics for suggesting additions to codespell.

Fwiw, for a project of this size and age, I'd say your codebase is about where I'd expect.

And thanks for the prompt response, I know it can be pretty daunting to get such a large PR.

[jsoref]

@tobiasbrunner; I think I've addressed everything...

[tobiasbrunner]

Thanks, looks good. I think it should be fine to squash all changes into a single commit, except perhaps the "routability" fix (because of the code changes). Would you mind preparing this?

[jsoref]

@tobiasbrunner: done

[tobiasbrunner]

Thanks a lot for your work on this.