[clang-tools-extra] [clang-tidy] Add bugprone-unsafe-api-functions-calls (PR #187637)

[Mats Kindahl via cfe-commits]

mkindahl wrote:

I ran a scan of GitHub and found a few entries that uses stack variables:
- This calls `fclose()`: https://github.com/okazakii/openmx/blob/0e0318222bc9e1d69c454241024fb63413296fe9/source/RestartFileDFT.c                                       
- This calls `fclose()`: https://github.com/DHKiem/openmx_patch/blob/f52bea3827b82dd28cdc225bd3882cbcf8e64c12/source/Dos/Dos_nearK_DH.c
- This do not call `fclose()` before exit and could be a potential bug (I didn't investigate closer): https://github.com/leoz/tiff/blob/8a911864a8aa1e0a3830b14c9c0a104b5fb8da8b/tools/gif2tiff.c
- This do not call `fclose()` before exit and could be a potential bug: https://github.com/SoK-Vul4C/SoK/blob/88676eb20acfd6dee7678a4614944d3b5f323638/Results/VulMaster/libtiff/CVE-2016-10268/Candidate_Patches/23.c

I think there still is value in capturing stack-allocated usage even with false positives since it is easy to turn off. Compare this with warnings for narrowing conversion in this case, for example:

```c
int create_listener(int port)                                                                                     
  {
      int fd = socket(AF_INET, SOCK_STREAM, 0);                                                                     
      if (fd < 0)                                                        
          return -1;                                                                                                
   
      struct sockaddr_in addr;                                                                                      
      memset(&addr, 0, sizeof(addr));                                    
      addr.sin_family      = AF_INET;
      addr.sin_addr.s_addr = htonl(INADDR_ANY);
      addr.sin_port        = htons(port);                                                                 
   
      if (bind(fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {                                                   
          close(fd);                                                     
          return -1;                                                                                                
      }                                                                  

      if (listen(fd, 128) < 0) {
          close(fd);
          return -1;
      }                                                                                                             
   
      return fd;                                                                                                    
  }                                                                      
```

For this case, a suggestion will be to add a cast to the `port` variable, which is not necessary if the port is in the correct range. The only way to know for sure that the cast is required is to do a semantic analysis of the range of values that `port` can take and only ask to add a cast if it is outside the range. It is easier to warn for this and require users to add the cast even when it is not needed, and I think it is value in that kind of check.

(The interesting take here is, however, that passing something outside the range of `uint16_t` here is in reality a bug. It will transform something outside the range to a value in the port range and bind to that: not likely to be what was intended. This is, however, silenced by adding a C-style cast, which I would argue is not correct.)

https://github.com/llvm/llvm-project/pull/187637