1

Using the pattern explained here as follows:

auto action = 
  std::unique_ptr< posix_spawn_file_actions_t, decltype(&posix_spawn_file_actions_destroy) > 
  { new posix_spawn_file_actions_t(), posix_spawn_file_actions_destroy };

triggers a [-Wignored-attributes] in gcc v10.1.0 -std=c++20:

warning: ignoring attributes on template argument ‘int (*)(posix_spawn_file_actions_t*) noexcept’
|         std::unique_ptr<posix_spawn_file_actions_t, decltype(&posix_spawn_file_actions_destroy)>
|                                                                                                ^

Why is that? Should it be ignored or is there a way to adjust the code?

DarioP
  • 5,377
  • 1
  • 33
  • 52

1 Answers1

1

It is saying you are ignoring the fact the function pointer doesn't throw.

Your code has other errors, like newing a pointer that isn't cleaned up by delete.

In or later I use

template<auto x> using kval_t=std::intergral_constant<std::decay_t<decltype(x)>,x>;
template<auto x> constexpr kval_t<x> kval={};

You can then:

auto action = 
  std::unique_ptr< posix_spawn_file_actions_t, kval_t<posix_spawn_file_actions_destroy> >  =
     { new posix_spawn_file_actions_t() };

but new here is probably the wrong way to create a posix_spawn_file_actions_t.

This stores the function pointer in a compile time constant, and may get rid of that warning.

Yakk - Adam Nevraumont
  • 262,606
  • 27
  • 330
  • 524
  • Ok, according to https://unix.stackexchange.com/a/479567/82783 `posix_spawn_file_actions_destroy` can act on the address of a stack allocated `posix_spawn_file_actions_t`. Then I should probably get rid of the `unique_ptr` altogether, although the possibility of not reaching the call to `posix_spawn_file_actions_destroy` remains... ahw I hate when C mixes in C++ – DarioP Jun 16 '20 at 16:03
  • @dario you want a nullable handle like https://en.cppreference.com/w/cpp/named_req/NullablePointer if you want to avoid a heap allocation. – Yakk - Adam Nevraumont Jun 16 '20 at 19:48
  • Thanks, I don't think I really need that. It is usual for C interfaces to provide a function that returns an allocated pointer and a second function to free it when done. I like to wrap these two in a smart pointer enforcing RAII, but I did not notice that these posix functions are slightly different. – DarioP Jun 17 '20 at 08:22