# file(STRINGS ...) with empty filename does not fail

**URL:** <https://discourse.cmake.org/t/file-strings-with-empty-filename-does-not-fail/8027>\
**Category:** Code\
**Created:** [May 1, 2023, 4:14pm UTC](https://discourse.cmake.org/t/file-strings-with-empty-filename-does-not-fail/8027 "2023-05-01T16:14:00Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![georg](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/g/9f8e36/32.png) [@georg](https://discourse.cmake.org/u/georg)\
**Post date:** [May 1, 2023, 4:14pm UTC](https://discourse.cmake.org/t/file-strings-with-empty-filename-does-not-fail/8027/1 "2023-05-01T16:14:00Z")

</div>

Recently I was hunting down an issue related to a call to `file(STRINGS ...)` until I realized that I mispelled a variable name:

```auto
file(STRINGS "${mispelledVarName}" content)

```

As `mispelledVarName` is not a valid existing variable name this evaluates to:

```auto
file(STRINGS "" content)

```

To my surprise the file function does not fail here, but just returns without any error (leaving the variable `content` empty).

With a non existing file name like

```auto
file(STRINGS "/nonexistent.txt" content)

```

CMake exits with an error:

```auto
CMake Error at test.cmake:x (file):
  file STRINGS file
  "/nonexistent.txt"
  cannot be read.

```

Shouldn’t an empty filename be handled like a non existing filename? Or is this behavior intended?

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [May 1, 2023, 7:05pm UTC](https://discourse.cmake.org/t/file-strings-with-empty-filename-does-not-fail/8027/2 "2023-05-01T19:05:23Z")

</div>

It’s probably not intended, but will likely need a policy to turn into an error. Looking at the code, if the path is not absolute, it gets appended to the current source directory. It seems that this ends up reading a directory…but not failing? Does it do the same thing with another directory (not file) path?

---

<div class="post-metadata">

**Author:** ![georg](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/g/9f8e36/32.png) [@georg](https://discourse.cmake.org/u/georg)\
**Post date:** [May 1, 2023, 7:36pm UTC](https://discourse.cmake.org/t/file-strings-with-empty-filename-does-not-fail/8027/3 "2023-05-01T19:36:36Z")

</div>

All of the following do not fail and return an empty string (tested with CMake 3.22.1):

```auto
file(STRINGS "${nonexistent}" content)
message("content: '${content}'")

file(STRINGS "" content)
message("content: '${content}'")

file(STRINGS "/" content)
message("content: '${content}'")

file(STRINGS "." content)
message("content: '${content}'")

```

Interestingly `file(READ ...)` behaves a bit different and returns a single newline character instead:

```auto
file(READ "" content)
message("content: '${content}'")

file(READ "/" content)
message("content: '${content}'")

file(READ "." content)
message("content: '${content}'")

```

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [May 1, 2023, 8:49pm UTC](https://discourse.cmake.org/t/file-strings-with-empty-filename-does-not-fail/8027/4 "2023-05-01T20:49:23Z")

</div>

Ugh, thanks. We’ll have to really increase the test suite to cover this policy’s behavior (assuming we want it to fix all relevant `file(*)` subcommands).