10 ms·

Kind of wish people would stop inventing new notation. There's already Microsoft SAL. Just use the existing annotations (like _In_reads_(N) here) instead of for

Kind of wish people would stop inventing new notation. There's already Microsoft SAL. Just use the existing annotations (like _In_reads_(N) here) instead of forcing people to adopt two of them their codebases! https://learn.microsoft.com/en-us/cpp/code-quality/understanding-sal https://learn.microsoft.com/en-us/cpp/code-quality/understan...

shadowgovt 3y ago
After Oracle v. Google, can a project consider a protocol designed by Microsoft safe to use even if they're doing their own implementation of the contract enforcement engine?
- dataflow 3y ago
  Clang already supports a bunch of MS compiler features. I don't see why this is any different?
- jcranmer 3y ago
  Given that SCOTUS essentially ruled that clean-room implementation is more or less automatically fair use, why not?
  - Someone 3y ago
    Making sure, firstly, that your implementation is clean room and, secondly, that you can prove that in court, is quite a hassle, though, especially if your implementers visited various conferences and standard meetings where they met people working on the feature being reimplemented.
nynx 3y ago
You’d think maybe they could make the annotations less ugly
- dataflow 3y ago
  Who's they? Both annotations seem ugly. And ugliness is hardly a reason to litter everyone's code with a parallel set of names.
- olliej 3y ago
  What is the ugliness you're talking about? They're clear and explicitly named so I'm not sure what you could change that would make things better
TazeTSchnitzel 3y ago
C99 also lets you do this: void foo(size_t elem_count, int elems[elem_count]); Unfortunately this constraints the argument order. C23 fixes that with something like this: void foo(size_t elem_count; int elems[elem_count], elem_count); (Might be slightly wrong, going from memory.)
- shadowgovt 3y ago
  > Unfortunately this constraints the argument order In both C and C++, it drives me absolutely bonkers that declaration order matters so much. Point of personal preference, but they're the last languages I use with any regularity where you can't just reference a symbol that will be declared later in the file. In this case, the compiler should be able to figure it out without any of that hinting; the scope of potential valid bindings is in the parentheses. It's a very constrained scope!
  - saurik 3y ago
    Requiring things be defined in the right order is a bit annoying, as the computer can surely figure it out... but a lot of us are working with really large codebases that are very slow to compile and alleviating the compiler from having to know the entire file--or in some cases entire modules... madness!!--before being able to understand what any of it means really helps.
    - shadowgovt 3y ago
      If compilation speed is an issue, you're already sunk in C and C++ because the #include evaluation rules leave very little room to optimize the massive redundancy of computing headers over and over (and every header includes all its headers, and etc).
      - uecker 3y ago
        In C headers are not a problem. They are simple and effective. C++ made the mistake of putting implementations into headers for generic programming.
olliej 3y ago
As far as I can tell SAL is a static analyzer aid, and only applies to specifically annotated values. This RFC applies to all pointers in all cases, and bounds checking occurs on every pointer access at runtime. So while the annotations clearly overlap, the language semantics are vastly different.
- dataflow 3y ago
  There are no language semantics for either, they're just declarative annotations about run time behavior. Either compiler can add checks at compile or run time for the annotations. There's really no reason to have two sets of parallel annotations for the same constraint.
  - olliej 3y ago
    Oh, your issue is the different syntax not the feature itself? The syntax this RFC uses is based on the standardized syntax for attributes in C.
    - dataflow 3y ago
      In what sense is __counted_by "standardized"? And is it really worth deviating from what's already there?
      - olliej 3y ago
        Sorry that was really badly phrased. GCC and Clang have a standard syntax for attributes, which is what this feature uses. Moreover the position semantics of the __attribute__ syntax matches the positional semantics of the standardized C++ attribute syntax, which is (fingers crossed) finally being picked up in C23. So with that mea culpa let's address the rest. __counted_by is obviously not standardized - this is an RFC for clang, let alone a spec proposal. __counted_by is a macro that expands to: __attribute__((__counted_by__(T))) Which is the standard syntax for all attributes in clang and gcc. So the question is why the position is different from under SAL. SAL considers the bounds of a pointer to be a feature of the declaration, not the type. This RFC consider pointer bounds to be an attribute of the type itself. Because of that, the syntax of the attribute needs to be in the location for type attributes. You might reasonably respond with "a one off match of this other syntax would have been ok", but the SAL syntax also means that you can only specify one set of bounds per declaration. By having bounds be an attribute of the type you can specify the bounds at each level of indirection in a declaration, so you can have something like: void dump_string_list(int N, const char * __null_terminated * __counted_by(N) thing); The other part is that this RFC also allows for opt in wide pointers so you can do void something_else(int N, int * __indexable * __counted_by(N) thing); Which would presumably not be usable for an existing API, but for internal logic that isn't subject to ABI constraints would allow the adoption of bounds safety without significant source changes. It also highlights the impact on syntactic consistency of having this be an attribute of the type. Now, given the necessary positional difference, reusing the same token as used for MS's SAL would make these incompatible, so code bases would need to use different macro names for each anyway. Finally, if it was considered really valuable, then someone could implement the same implicit adoption that occurs when SAL attributes are present, as already occurs if you do something like void f(int N, int buffer[N]) while retaining the significantly more powerful and flexible attributes provided by this RFC.
TeaDude 3y ago
I recall reading that SAL was patent encumbered but I can't for the life of me find the actual patent. I remember it coming up in the llvm forums though..
- dataflow 3y ago
  Oh wow, thanks, I had no idea. Googling brings this up, though: https://patents.google.com/patent/US7584458B2/en https://patents.google.com/patent/US7584458B2/en If this patent is genuinely enforceable, surely the names of the keywords aren't relevant?

shadowgovt 3y ago

After Oracle v. Google, can a project consider a protocol designed by Microsoft safe to use even if they're doing their own implementation of the contract enforcement engine?

dataflow 3y ago
Clang already supports a bunch of MS compiler features. I don't see why this is any different?
jcranmer 3y ago
Given that SCOTUS essentially ruled that clean-room implementation is more or less automatically fair use, why not?
- Someone 3y ago
  Making sure, firstly, that your implementation is clean room and, secondly, that you can prove that in court, is quite a hassle, though, especially if your implementers visited various conferences and standard meetings where they met people working on the feature being reimplemented.

nynx 3y ago

You’d think maybe they could make the annotations less ugly

dataflow 3y ago
Who's they? Both annotations seem ugly. And ugliness is hardly a reason to litter everyone's code with a parallel set of names.
olliej 3y ago
What is the ugliness you're talking about? They're clear and explicitly named so I'm not sure what you could change that would make things better

TazeTSchnitzel 3y ago

C99 also lets you do this: void foo(size_t elem_count, int elems[elem_count]); Unfortunately this constraints the argument order. C23 fixes that with something like this: void foo(size_t elem_count; int elems[elem_count], elem_count); (Might be slightly wrong, going from memory.)

shadowgovt 3y ago
> Unfortunately this constraints the argument order In both C and C++, it drives me absolutely bonkers that declaration order matters so much. Point of personal preference, but they're the last languages I use with any regularity where you can't just reference a symbol that will be declared later in the file. In this case, the compiler should be able to figure it out without any of that hinting; the scope of potential valid bindings is in the parentheses. It's a very constrained scope!
- saurik 3y ago
  Requiring things be defined in the right order is a bit annoying, as the computer can surely figure it out... but a lot of us are working with really large codebases that are very slow to compile and alleviating the compiler from having to know the entire file--or in some cases entire modules... madness!!--before being able to understand what any of it means really helps.
  - shadowgovt 3y ago
    If compilation speed is an issue, you're already sunk in C and C++ because the #include evaluation rules leave very little room to optimize the massive redundancy of computing headers over and over (and every header includes all its headers, and etc).
    - uecker 3y ago
      In C headers are not a problem. They are simple and effective. C++ made the mistake of putting implementations into headers for generic programming.

olliej 3y ago

As far as I can tell SAL is a static analyzer aid, and only applies to specifically annotated values. This RFC applies to all pointers in all cases, and bounds checking occurs on every pointer access at runtime. So while the annotations clearly overlap, the language semantics are vastly different.

dataflow 3y ago
There are no language semantics for either, they're just declarative annotations about run time behavior. Either compiler can add checks at compile or run time for the annotations. There's really no reason to have two sets of parallel annotations for the same constraint.
- olliej 3y ago
  Oh, your issue is the different syntax not the feature itself? The syntax this RFC uses is based on the standardized syntax for attributes in C.
  - dataflow 3y ago
    In what sense is __counted_by "standardized"? And is it really worth deviating from what's already there?
    - olliej 3y ago
      Sorry that was really badly phrased. GCC and Clang have a standard syntax for attributes, which is what this feature uses. Moreover the position semantics of the __attribute__ syntax matches the positional semantics of the standardized C++ attribute syntax, which is (fingers crossed) finally being picked up in C23. So with that mea culpa let's address the rest. __counted_by is obviously not standardized - this is an RFC for clang, let alone a spec proposal. __counted_by is a macro that expands to: __attribute__((__counted_by__(T))) Which is the standard syntax for all attributes in clang and gcc. So the question is why the position is different from under SAL. SAL considers the bounds of a pointer to be a feature of the declaration, not the type. This RFC consider pointer bounds to be an attribute of the type itself. Because of that, the syntax of the attribute needs to be in the location for type attributes. You might reasonably respond with "a one off match of this other syntax would have been ok", but the SAL syntax also means that you can only specify one set of bounds per declaration. By having bounds be an attribute of the type you can specify the bounds at each level of indirection in a declaration, so you can have something like: void dump_string_list(int N, const char * __null_terminated * __counted_by(N) thing); The other part is that this RFC also allows for opt in wide pointers so you can do void something_else(int N, int * __indexable * __counted_by(N) thing); Which would presumably not be usable for an existing API, but for internal logic that isn't subject to ABI constraints would allow the adoption of bounds safety without significant source changes. It also highlights the impact on syntactic consistency of having this be an attribute of the type. Now, given the necessary positional difference, reusing the same token as used for MS's SAL would make these incompatible, so code bases would need to use different macro names for each anyway. Finally, if it was considered really valuable, then someone could implement the same implicit adoption that occurs when SAL attributes are present, as already occurs if you do something like void f(int N, int buffer[N]) while retaining the significantly more powerful and flexible attributes provided by this RFC.

TeaDude 3y ago

I recall reading that SAL was patent encumbered but I can't for the life of me find the actual patent. I remember it coming up in the llvm forums though..

dataflow 3y ago
Oh wow, thanks, I had no idea. Googling brings this up, though: https://patents.google.com/patent/US7584458B2/en https://patents.google.com/patent/US7584458B2/en If this patent is genuinely enforceable, surely the names of the keywords aren't relevant?