3 ms·

Safer code in C++ with lifetime bounds

26 points by mpweiher 2y ago

jeffbee 2y ago
I am in favor of these kinds of annotations but in a recent clang I get this already, no annotations: object backing the pointer will be destroyed at the end of the full-expression [-Werror,-Wdangling-gsl]
klyrs 2y ago
Gesundheit
wakawaka28 2y ago
Does anyone actually want to clutter their code with such annotations? The example looks like something that should always warn or always generate an error, which makes this whole exercise seem that much worse.
- tempodox 2y ago
  Agreed, it's a day late and a dollar short for the kind of footgun that has been cocked and ready to shoot since forever. At least it's a small step in the right direction.
  - wakawaka28 2y ago
    I just think it should be done by default instead of with crazy annotations...
- gumby 2y ago
  You put it in library code so the callers don't have to see it. I am always amused when a new C++ standard issues how many people complain "why did they add this obscure stuff and not my favourite feature?". Many of those changes are for library writers and don't have a lot of applicability for use in "normal" code. But everybody gets the benefit when the standard library speeds up or handles a non-obvious corner case.
  - wakawaka28 2y ago
    I'm glad I could amuse you but your smugness is unwarranted. I am well aware that this is aimed at library writers but everyone probably should be getting warnings for this crap anyway. Tell me when you can opt me into the warning some other way besides polluting the code with more Byzantine compiler-specific annotations. Are there really so many false positives and legitimate uses of this behavior that you have to opt in on a function by function basis? I could accept that possibility but inquiring minds want to know that there isn't a better way to do this that truly maximizes the benefit of the new feature. I don't want to create more work for myself reading or writing annotations because there are already so many things to think about. The only time I could see myself using this annotation is if the code is so complex (possibly due to crap like this) that I can't tell if this one specific error can happen and I somehow remember this obscure feature that day.
- pjmlp 2y ago
  Yes, Microsoft since Windows XP SP2, the use of SAL is pretty much a requirement for many business units SDLC processes. However many aren't aware of SAL all these years, given how many think of these new clang annotations as a novelty.
MaxBarraclough 2y ago
Presumably these issues could be detected at runtime by having the compiler add checking logic into dev/debug builds. The static approach used here may have the advantage of giving a more categorical assurance, i.e. one that doesn't depend on the particular behaviour exercised at runtime, but it requires annotations, meaning that: 1. It can't be used on an existing codebase lacking these annotations 2. It trusts the programmer to get the annotations right (I'm not particularly well informed of recent developments in C++, perhaps such runtime instrumentation already exists?)

26 points by mpweiher 2y ago

I am in favor of these kinds of annotations but in a recent clang I get this already, no annotations: object backing the pointer will be destroyed at the end of the full-expression [-Werror,-Wdangling-gsl]

klyrs 2y ago

Gesundheit

wakawaka28 2y ago

Does anyone actually want to clutter their code with such annotations? The example looks like something that should always warn or always generate an error, which makes this whole exercise seem that much worse.

tempodox 2y ago
Agreed, it's a day late and a dollar short for the kind of footgun that has been cocked and ready to shoot since forever. At least it's a small step in the right direction.
- wakawaka28 2y ago
  I just think it should be done by default instead of with crazy annotations...
gumby 2y ago
You put it in library code so the callers don't have to see it. I am always amused when a new C++ standard issues how many people complain "why did they add this obscure stuff and not my favourite feature?". Many of those changes are for library writers and don't have a lot of applicability for use in "normal" code. But everybody gets the benefit when the standard library speeds up or handles a non-obvious corner case.
- wakawaka28 2y ago
  I'm glad I could amuse you but your smugness is unwarranted. I am well aware that this is aimed at library writers but everyone probably should be getting warnings for this crap anyway. Tell me when you can opt me into the warning some other way besides polluting the code with more Byzantine compiler-specific annotations. Are there really so many false positives and legitimate uses of this behavior that you have to opt in on a function by function basis? I could accept that possibility but inquiring minds want to know that there isn't a better way to do this that truly maximizes the benefit of the new feature. I don't want to create more work for myself reading or writing annotations because there are already so many things to think about. The only time I could see myself using this annotation is if the code is so complex (possibly due to crap like this) that I can't tell if this one specific error can happen and I somehow remember this obscure feature that day.
pjmlp 2y ago
Yes, Microsoft since Windows XP SP2, the use of SAL is pretty much a requirement for many business units SDLC processes. However many aren't aware of SAL all these years, given how many think of these new clang annotations as a novelty.

MaxBarraclough 2y ago

Presumably these issues could be detected at runtime by having the compiler add checking logic into dev/debug builds. The static approach used here may have the advantage of giving a more categorical assurance, i.e. one that doesn't depend on the particular behaviour exercised at runtime, but it requires annotations, meaning that: 1. It can't be used on an existing codebase lacking these annotations 2. It trusts the programmer to get the annotations right (I'm not particularly well informed of recent developments in C++, perhaps such runtime instrumentation already exists?)