My point was to the fact that they chose to have a fuss about what they're going to vote for, especially considering that they're a very small shareholder of MSFT.
No, it's not. "Grift" is a count noun. You can't say "grift is occurring here"; you can say "a grift is occuring here", or "grifts are occurring here", but not just "grift is occurring here". Meanwhile, "graft", in the sense of the abuse of an office for personal gain, is a mass noun and can be used this way. Perhaps the commenter's mistake was leaving out an article rather than using the wrong word? The latter seems more likely to me, however.
Has anyone found a static analysis tool which understands C11 annex K (aka “safe C”) functions? I’ve found some tools like CLANG static analysis will raise errors for potentially incorrect calls to stdlib C functions, but doesn’t understand the replacements, which means some errors previously caught by analysis can only be caught at runtime.
Annex K is optional and the only compiler I'm aware of implementing it is MSVC (and only Microsoft wanted that in the standard), so the support for it will be nonexistent in "normal" tooling. If you need it, check if MS has something.
> Annex K is optional and the only compiler I'm aware of implementing it is MSVC (and only Microsoft wanted that in the standard),
And to rub salt into the wound, the Annex K functions supplied with MSVC are non-conforming to the standards Annex K functions, which were also pushed hard by Microsoft, which make them kinda doubly pointless: you use them and make code that is neither portable to another compiler nor conforming to the standard :-/
The name SRS for a "software requirements specification" is well established and depending on how it's understood it could be written by the customer or written by the supplier. Colloquially, both "requirements" and "specification" are regularly used to refer to such document. It is similar to calling a document that describes test instructions either a "test specification" or a "test procedure" -- different people/projects/companies, different conventions.
What matters is to have a common understanding and work together.
Different terms for the same concepts. You could call it high- and low-level requirements, customer/supplier requirements or requirements and specification. While the form is important, a common understanding is core to be able to work together.
I agree, but I think one key distinction here is that I for my part tend to avoid classification. It's a spectrum of refinement, not two distinct classes IMHO.
The concept I use is that the next stage is all about how you implement the previous one: the spec is how you implement the requirements, the design is how you implement the spec, the code is how you implement the design.
As okl said, it’s arguably terminology, and maybe high and low level requirements would work for you? I prefer to separate out the terms though, so that “requirements” are the thing that the engineering team can’t unilaterally change without upsetting the stakeholders. If I can change a spec item mid-delivery and it doesn’t matter to the customer, then it wasn’t a requirement. If I can’t change it, then it’s a requirement.
Slight twist I learned from my wife: MoSCoW lists - Must, Should, Could, Won't.
The "Won't"s really tie down the boundaries of the system. If your PM is smart they probably won't call them "Won't"s, much more likely to bunch them into a column labelled "Phase 2".
Note that legal tender != can buy milk with. Legal tender is only about payment of debt. A shop selling you something doesn’t have to accept any specific form of payment, as they don’t let you build up a tab which needs repaying.
Windows allows you to use a PIN for regular device logon - so you have a longer, more secure password for general use of the account, but an eg 8 digit numeric PIN _only_ for that device.
