Update codespell configuration to reduce false positives

[gyanranjanpanda]

Fixes #1108

Summary

This PR updates the codespell configuration to reduce false positives by adding an ignore-regex pattern that skips common code constructs while still checking natural language text in comments and documentation.

Changes

• Added ignore-regex to .codespellrc to skip:
  • camelCase identifiers (e.g., myVariable, someFunction)
  • snake_case identifiers (e.g., my_variable, some_function)
  • Hexadecimal numbers (e.g., 0x1234)
  • Import/package/use/include statements

Testing

The existing CI workflow will verify that codespell runs successfully with the new configuration. The updated regex pattern significantly reduces false positives on code elements while maintaining spell checking for comments and documentation.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: gyanranjanpanda / name: Gyan Ranjan (92c1acb, a2bbae3, c228015)

[christos68k]

Hi @gyanranjanpanda can you update your PR to take the (just merged) #1119 into account? Thanks!

[gyanranjanpanda]

Thanks @christos68k! I've rebased on the latest main to include the changes from #1119.

I resolved the conflict in
.codespellrc
by merging the configurations: I kept the updated upstream CamelCase regex (which allows numbers) and combined it with the additional ignore patterns from this PR (for snake_case, hex values, etc.).

Required checks should be running now.

[gyanranjanpanda]

hi @christos68k ,@rogercoll
if any thing i have to change pls let me know

[christos68k]

Suggested change

	return addresses that's follow a call
	return address that follows a call

[gyanranjanpanda]

Thank you for catching that! You're absolutely right - I've updated line 110 to fix the grammar. The change has been pushed.

Please let me know if there's anything else that needs adjustment!

[christos68k]

It's still not correct, see my suggestion

[gyanranjanpanda]

i did it what u want if i have to do any thing pls let me know

[christos68k]

For future reference, I think it's just easier to accept a reviewer's suggestion in the GH UI instead of reimplementing it. It saves time (as the reviewer can see that the suggestion was implemented exactly as given and doesn't have to check again) and avoids errors like the one that took place here.