You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As the best practice for C APIs is to "namespace" them with a prefix refering to the library they are from, I suggest adding simple glob support to the function name part of annotations, so users could write
#cgonocallbackFooLib_*
and mark all functions from FooLib used in this file as nocallback.
The downside to this is the potential to glob functions where the annotation is not correct, but I do not think this is more error prone than having users automate generating the 100+ annotations they need in a file via external tooling.
Alternative direction would be to lean into the automated generation side, and support having these annotations be specified in an external file, that the users can autogenerate, instead of having to add these into each file where they wrap the C API. I prefer the globbing option, as that seems more inline with the current design of cgo directives.
The text was updated successfully, but these errors were encountered:
seankhliao
changed the title
proposal: cmd/cgo: Support bulk annotation of C functions with attributes
proposal: cmd/cgo: support bulk annotation of C functions with attributes
Feb 19, 2025
Proposal Details
Currently the
noescape
andnocallback
annotations have to be applied to each function individually.This leads to people having over 300 lines of annotations in their code as they try to get better codegen for their wrappers of C libraries.
As the best practice for C APIs is to "namespace" them with a prefix refering to the library they are from, I suggest adding simple glob support to the function name part of annotations, so users could write
and mark all functions from
FooLib
used in this file asnocallback
.The downside to this is the potential to glob functions where the annotation is not correct, but I do not think this is more error prone than having users automate generating the 100+ annotations they need in a file via external tooling.
Alternative direction would be to lean into the automated generation side, and support having these annotations be specified in an external file, that the users can autogenerate, instead of having to add these into each file where they wrap the C API. I prefer the globbing option, as that seems more inline with the current design of cgo directives.
The text was updated successfully, but these errors were encountered: