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
Motivation: I want to support gcc's __attribute__((nonnull)) and clang's _Nonnull pointer qualifier in translate-c, but I think this is a good idea either way.
C pointers currently (taken from language reference):
Supports all the syntax of the other two pointer types.
Coerces to other pointer types, as well as Optional Pointers. When a C pointer is coerced to a non-optional pointer, safety-checked Undefined Behavior occurs if the address is 0.
You should still be able to index with [] and dereference with .*. .?/try/orelse come free with optional types.
Allows address 0. On non-freestanding targets, dereferencing address 0 is safety-checked Undefined Behavior. Optional C pointers introduce another bit to keep track of null, just like ?usize. Note that creating an optional C pointer is unnecessary as one can use normal Optional Pointers.
C pointers should be non-optional by default, and translate-c should translate most pointers as ?[*c]T.
This reduces the number of special cases in the compiler, syntax for optional pointers and c pointers have separate code paths
Removing this is already partially accepted, other than comptime-known 0.
From what I can gather, this was initially for translate-c before it became as smart as it is now.
Motivation: I want to support gcc's
__attribute__((nonnull))
and clang's_Nonnull
pointer qualifier in translate-c, but I think this is a good idea either way.C pointers currently (taken from language reference):
You should still be able to index with
[]
and dereference with.*
..?
/try
/orelse
come free with optional types.C pointers should be non-optional by default, and translate-c should translate most pointers as
?[*c]T
.[*c]T
as a type in translate-c for__attribute__((nonnull))
-annotated function parameters or return types, orclang's
_Nonnull
annotatation (translate-c: ability to annotate types in C code for better translation #2457 but useful for C consumers too!)This should be removed completely.
Removing this is already partially accepted, other than comptime-known 0.
From what I can gather, this was initially for translate-c before it became as smart as it is now.
I think C APIs that benefit from this implicit behaviour are pretty rare, and we shouldn't make the language more weird to accomodate them.
We already don't change the language to accomodate using enums as bitflags, which are much more common.
No change here.
The text was updated successfully, but these errors were encountered: