0

My use case is as follows. In the automated testing of one of my libraries I use the mktemp function in order to obtain a filename in order to create a temporary file. Xcode correctly complains about this as a security risk, but in this case I have no option (the API I must follow demands filenames) and I am willing to take the risk since the code is only the test code and not in an actual service. (Hence the security risk is not applicable.)

I suppose I could create my own version of a mktemp that is local to my testing, but I would prefer not to write things that have already been written.

So what I am wondering is if there is a way that I can tell the analyzer to stop complaining this instance of the problem? Note that this differs from the question asked in Is it possible to suppress Xcode 4 static analyzer warnings? in that this is not a false positive, and I do not want to suppress analyzing the file or all instances of this check. I just want to suppress this one instance. (i.e. something similar to cppcheck-suppress comment in Cppcheck)

Steven W. Klassen
  • 1,401
  • 12
  • 26
  • Almost all warnings can be disabled. Have you checked through the long list of flags you can turn on and off in the Target settings? A small code sample here and the precise error you're getting would help as with `clang` you often get the name of the warning that's triggered. – tadman Aug 31 '18 at 17:33
  • Why can't you use `mkstemp()` — possibly in conjunction with `fdopen()` — instead of `mktemp()`? Or choose another file name generation mechanism. – Jonathan Leffler Aug 31 '18 at 19:08
  • 1
    @JonathanLeffler I’m sorry to report that mkstemp() will not solve my problem as the API I must use (not under my control) requires that a file name be given to the function which will write the file. Hence any method that creates the file and returns a file descriptor is not an option. – Steven W. Klassen Aug 31 '18 at 23:42
  • Note that `mkstemp()` both sets the name and returns the file descriptor. You can use it. Or, at least, what you've said are the requirements doesn't yet preclude you from using it. – Jonathan Leffler Aug 31 '18 at 23:43
  • @tadman Disabling the warning for this instance is essentially what I’m asking about. However this isn’t a compiler warning, it is a result of the static analyzer and the options that I’ve been able to find so far seem limited. That said I’ll take a closer look at the raw output and see if there are any clues that I’ve missed so far. As for a code sample, a simple one-line `main()` function that calls `mktemp()` should be sufficient to get the same result. – Steven W. Klassen Aug 31 '18 at 23:44
  • @JonathanLeffler If I use `mkstemp()` I would have to close the file descriptor and then pass the name into the API. That would essentially cause the same race condition that using `mktemp()` involves. However, since in my case I’m not concerned about the security implications, this may be a sufficient way to suppress the warning. – Steven W. Klassen Aug 31 '18 at 23:49
  • What compiler options are you using? I used: `/usr/bin/clang -O3 -g -std=c11 -Wall -Wextra -Werror -Wmissing-prototypes -Wstrict-prototypes -c mktm97.c` to create the object file, and there are no witterings. Indeed, there's no wittering when I omit the `-c` and add `-o mktm97` to the command line. So, what are you using? (I'm using XCode 9.1.0 on macOS 10.13.6 High Sierra). – Jonathan Leffler Aug 31 '18 at 23:51
  • No; the file is already created, but closing the file does not delete it. That race is not present. – Jonathan Leffler Aug 31 '18 at 23:52
  • And the code I'm testing is: `#include ` — `#include ` — `int main(void) { char tempname[32] = "./data.XXXXXX"; mktemp(tempname); printf("[%s]\n", tempname); return 0; }` — JFTR. – Jonathan Leffler Aug 31 '18 at 23:53
  • There are no compiler warnings. As I mentioned in the original question I am asking how to suppress a complaint from the static analyzer that is used by Xcode. Assuming you put your test program in an Xcode project, instead of compiling and running, tell it to perform the code analysis. Then you should see it’s complain. – Steven W. Klassen Aug 31 '18 at 23:53
  • Then don't use the code analysis on your test code, or ignore the warning since you've decided it is not relevant to you — and your decision is not to think it is relevant is reasonable. I run XCode once every two or three months, maybe. I've yet to meet an IDE that I found helpful — XCode is no different from Eclipse or Code::Blocks or ... that I've tried. If you're using the XCode GUI, you can't be automating the testing — you have to drive it with a mouse/touchpad so you can decide whether or not the warnings are significant. Or you can go the safe route and use `mkstemp()`. – Jonathan Leffler Aug 31 '18 at 23:56
  • 2
    It also looks like the accepted answer to the question you reference would help. Add `#ifndef __clang_analyzer__` before and `#endif` after the code that uses `mktemp()` — that would suppress the warning from your `mktemp()` line. If you're worried that there might be other warnings on the line that you should be worried about, your line is probably too complex. At most, you should be doing `if (mktemp(template) == 0)` to test for failure. – Jonathan Leffler Sep 01 '18 at 00:01

1 Answers1

0

@JonathanLeffler last comment was absolutely correct and I don't know how I missed it when I read the question I referenced. The following code segment does exactly what I want - it suppresses the analyzer warning in this instance of mktemp while leaving it active for all other instances that would use mktemp.

#if defined(__clang_analyzer__)
   char* filename = "/tmp/somename";
#else
   char* filename = mktemp("/tmp/prefixXXXX");
#endif
Steven W. Klassen
  • 1,401
  • 12
  • 26
  • 1
    You meant `const char * const filename = "/tmp/somename";`, of course. Always `const` all the things (at least those that shouldn't change). :) – unwind Sep 03 '18 at 08:37
  • Although I'm leaving this as the correct answer (since the question was about suppressing a warning I want to ignore), I have changed my code in this instance to use mkstemp instead of mktemp. While I still have a race condition since I must close the file descriptor and then re-create the file of the same name, it may be less of a race condition (the file would be truncated and recreated in the same system call so the time it is vulnerable may be less), and in any event it is no less secure than using mktemp. This eliminates the need for my question as it also gets rid of the warnings. – Steven W. Klassen Sep 03 '18 at 14:49
  • @unwind I left it as `char*` so that it would match the return type of the `mktemp` call. In any event, it is now a moot point as I've replaced it with `mkstemp()`. – Steven W. Klassen Sep 03 '18 at 14:51