Uploaded image for project: 'Core ReactOS'
  1. Core ReactOS
  2. CORE-15984

"CCFDATAStorage.cxx:(.text+0xaf): warning: the use of `tmpnam' is dangerous, better use `mkstemp'"

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • Trivial
    • 0.4.12, 0.4.13
    • None

    Description

      Follow-up to PR514: CORE-14431 bcb0d7c,
      which causes

      Build GCCLin_x86: Apr 27 14:02 6a7d8112c368... success #24438
      Build GCCLin_x86 Release: Apr 27 06:37 19fc9415bfc8... success #2748
      Test KVM AHK: Apr 27 13:14 3cc216955650... success #8195

      CCFDATAStorage.cxx:(.text+0xaf): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
      


      Please, check my suggestions.

      Investigating tmpnam():
      ReactOS: https://git.reactos.org/?p=reactos.git&a=search&h=HEAD&st=grep&s=[^a-z_]tmpnam[^a-z\\._]&sr=1
      Wine: https://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=grep&s=[^a-z_]tmpnam[^a-z\\._]&sr=1

      1)

      dll/win32/crtdll/crtdll.spec
       492   @ cdecl tmpnam(str) msvcrt.tmpnam
      


      Is that how ROS does it, on purpose?
      Otherwise, suggest s/str/ptr/:
      Added as is on r43085.
      Should "WineSync" https://source.winehq.org/git/wine.git/commit/5ac184cad58e78419fcbb934d8f40d9c67fdc161.

      While there, I am not sure why there are spaces at beginning of lines in this ROS file.

      Cc learn_more

      2)

      dll/apisets/api-ms-win-crt-stdio-l1-1-0.spec
       159 @ stdcall tmpnam() msvcrt.tmpnam
      


      Is that how ROS does it, on purpose?
      Otherwise, suggest s/stdcall tmpnam()/cdecl tmpnam(ptr)/:
      Added as is on CORE-13231 3f15a0d.
      Wine has it "right" since https://source.winehq.org/git/wine.git/commit/7c5190e90e7780eb9abbc753c32ed8176afa9b4a.

      Cc learn_more

      3)

      sdk/tools/cabman/CCFDATAStorage.cxx
        61         FileHandle = fopen(tmpnam(NULL) + 1, "wb");
      


      Suggest:
      Shouldn't this workaround be inside an "#ifdef GCC" and/or "#ifdef Windows(64)"?
      Also, shouldn't this file be explicitly removed in Destroy() and maybe Truncate()?

      While there, should this workaround use another function than tmpnam()?
      Like tmpnam_s() (Hum, seems to be a stub), mkstemps(), ...?

      Cc ThePhysicist

      Attachments

        Issue Links

          Activity

            People

              ThePhysicist Timo Kreuzer
              Serge Gautherie Serge Gautherie
              Votes:
              2 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: