Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detect that a function pointer parameter has not the right size #305

Open
3 tasks done
zedalaye opened this issue Oct 17, 2024 · 4 comments
Open
3 tasks done

Detect that a function pointer parameter has not the right size #305

zedalaye opened this issue Oct 17, 2024 · 4 comments
Labels
feature New feature or request rule Improvements or additions to rules

Comments

@zedalaye
Copy link

Prerequisites

  • This rule has not already been suggested.
  • This should be a new rule, not an improvement to an existing rule.
  • This rule would be generally useful, not specific to my code or setup.

Suggested rule title

Pointers parameters should have the right size

Rule description

Check that pointer parameters have the right size according to the compiler architecture.

Rationale

In a migration process from Win32 to Win64, I encountered this error :

  n := tmpp.Count;
  p := nil;
  DynArraySetLength(p, field_type, 1, @n);

The code was build for Win32, so n was an Integer
Now DynArraySetLength takes a PNativeInt which is 64bits wide under Win64 and the Delphi compiler does not emit a single warning about this critical issue.

Would be awesome if Sonarqube could help finding those problems.

@zedalaye zedalaye added feature New feature or request rule Improvements or additions to rules triage This needs to be triaged by a maintainer labels Oct 17, 2024
@zaneduffield
Copy link
Collaborator

zaneduffield commented Oct 17, 2024

You may be interested in the Type-checked pointers compiler directive.

@zedalaye
Copy link
Author

I confirm that {$T+} find the problem. But as it's "project wide", it has consequences everywhere including in first party code.

@zaneduffield
Copy link
Collaborator

Yes, it has global scope. You'd have to deal with the stricter type checking in all compiled code.

Assuming you're using the precompiled RTL and precompiled 3rd party code, then it should only be an issue for the first party code — where you are able to fix the compiler errors.

@Cirras
Copy link
Collaborator

Cirras commented Nov 12, 2024

This could be a nice "progressive enhancement" sort of rule where you slowly migrate a codebase to using the {T+} directive, or a compromise where you want to enforce this in all of your application code but can't enable the directive due to noncompliant 3rdParty code being built into your project.

@Cirras Cirras removed the triage This needs to be triaged by a maintainer label Nov 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request rule Improvements or additions to rules
Projects
None yet
Development

No branches or pull requests

3 participants