3 ms·

> New function attribute null_terminated_string_arg(PARAM_IDX) for indicating parameters that are expected to be null-terminated strings. Why is this not a typ

> New function attribute null_terminated_string_arg(PARAM_IDX) for indicating parameters that are expected to be null-terminated strings. Why is this not a type attribute?

gpderetta 2y ago
because most of the time the parameter is going to be a plain char*.
- vlovich123 2y ago
  They’re asking why it’s not an attribute on the type instead of on the function. I don’t believe your answer explains that unless I’m overlooking some obvious implication of your statement.
  - avar 2y ago
    For reasons that are too hairy to go into here C doesn't "really" have a string type (yeah, yeah pendants, I know about fixed strings etc.). It just has arrays of char, which you pinky promise will end in a \0 for things that expect strings. By declaring that yes, this function really must have that terminating \0 a sufficiently smart compiler can statically analyze some errant use of functions expecting terminated strings. I haven't looked into this new feature, but I assume that's what it's doing. If you mean why is the "__attribute__" syntax not declaring such a thing adjacent to the function, the answer is that this allows for shoving the . extended syntax into standard C in a mostly backwards compatible way.
    - vlovich123 2y ago
      No, I’m asking why you can’t apply this variable on types within a function to verify that for example: __attribute__((null_terminated)) const char* x = strcpy(maybe_not_null_terminated, “some string”); Is a warning. Similarly, if it’s a type attribute then you’d apply it on the argument itself instead of needing to specify it on the function + an IDX parameter: void do_something(__attribute__((null_terminated)) char* f); The newly introduced strub attribute works this way, so it’s unclear why a function attribute was chosen for this attribute instead of a type attribute.
  - gpderetta 2y ago
    Oh, I see you want to annotate the parameter in the type position, so the annotation act as some sort of qualifier.

> New function attribute null_terminated_string_arg(PARAM_IDX) for indicating parameters that are expected to be null-terminated strings. Why is this not a type attribute?

gpderetta 2y ago

because most of the time the parameter is going to be a plain char*.

vlovich123 2y ago
They’re asking why it’s not an attribute on the type instead of on the function. I don’t believe your answer explains that unless I’m overlooking some obvious implication of your statement.
- avar 2y ago
  For reasons that are too hairy to go into here C doesn't "really" have a string type (yeah, yeah pendants, I know about fixed strings etc.). It just has arrays of char, which you pinky promise will end in a \0 for things that expect strings. By declaring that yes, this function really must have that terminating \0 a sufficiently smart compiler can statically analyze some errant use of functions expecting terminated strings. I haven't looked into this new feature, but I assume that's what it's doing. If you mean why is the "__attribute__" syntax not declaring such a thing adjacent to the function, the answer is that this allows for shoving the . extended syntax into standard C in a mostly backwards compatible way.
  - vlovich123 2y ago
    No, I’m asking why you can’t apply this variable on types within a function to verify that for example: __attribute__((null_terminated)) const char* x = strcpy(maybe_not_null_terminated, “some string”); Is a warning. Similarly, if it’s a type attribute then you’d apply it on the argument itself instead of needing to specify it on the function + an IDX parameter: void do_something(__attribute__((null_terminated)) char* f); The newly introduced strub attribute works this way, so it’s unclear why a function attribute was chosen for this attribute instead of a type attribute.
- gpderetta 2y ago
  Oh, I see you want to annotate the parameter in the type position, so the annotation act as some sort of qualifier.