[pwdisswordfishc]

> 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]

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

[vlovich123]

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]

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]

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]

Oh, I see you want to annotate the parameter in the type position, so the annotation act as some sort of qualifier.