minor cleanup for code scan

[liquidaty]

• Minor cleanup for code scan
• Use clang-format-15
• Format source files if required (missing ones)

[iamazeem]

@liquidaty: Please review.
The formatting and tests issues have been fixed. Thanks!

[iamazeem]

CodeQL Code Scanning Report for this branch:
https://github.com/liquidaty/zsv/security/code-scanning?query=is%3Aopen+branch%3Acleanup-20240919

Apparently, the first two are fixable.
The last two may also be fixed by writing our own function to encode SQL query. 🤔
The rest third-party ones, coming from SQLite3 source, may be marked as "won't fix".

[iamazeem]

Just verified with clang-format 18.1.3 on https://clang-format-configurator.site with our config that this line:

if(err)

is formatting correctly i.e.:

-if(err)
+if (err)

[iamazeem]

Looked into these CodeQL issues:

• https://github.com/liquidaty/zsv/security/code-scanning/2 (zsv.c:299)
• https://github.com/liquidaty/zsv/security/code-scanning/26 (select.c:800)

Both seem to be false positives.

Tried setting the respective pointer to NULL. No effect.
Tried alternate if-else flows for both cases but they had no effect:

zsv.c

  parser->fixed.offsets = calloc(count, sizeof(*parser->fixed.offsets));
  if (parser->fixed.offsets) {
    parser->fixed.count = count;
    for (unsigned i = 0; i < count; i++)
      parser->fixed.offsets[i] = offsets[i];
  } else {
    fprintf(stderr, "Out of memory!\n");
    return zsv_status_memory;
  }

select.c

        free(data.fixed.offsets);
        data.fixed.offsets = malloc(data.fixed.count * sizeof(*data.fixed.offsets));
        if (data.fixed.offsets) {
          size_t count = 0;
          const char *start = argv[arg_i];
          for (const char *end = argv[arg_i];; end++) {
            if (*end == ',' || *end == '\0') {
              if (sscanf(start, "%zu,", &data.fixed.offsets[count++]) != 1) {
                stat = zsv_printerr(1, "Invalid offset: %.*s\n", end - start, start);
                break;
              } else if (*end == '\0')
                break;
              else {
                start = end + 1;
                if (*start == '\0')
                  break;
              }
            }
          }
        } else {
          fprintf(stderr, "Out of memory!\n");
          return zsv_status_memory;
        }

Tested with "out of memory" check first too. No effect at all.

Also, on these checks, there's this warning:

WARNING: This check is an approximation, so some results may not be actual defects in the program. It is not possible in general to compute the values of pointers without running the program with all input data.

Given above, looks like these can safely be marked/dismissed as false positives from their respective links.

[iamazeem]

I was wondering if n will ever be 0 for these cases. 🤔
Checking n against strlen() seems to be enough.
Please see these examples:

• https://godbolt.org/z/oKn5oGGdW (with n check)
• https://godbolt.org/z/7jT4PGzhe (without n check)

n is never 0 here.

Also, the negative lower-bounded case (-5) seems to be handled as single index.
It's being read and wrapped around as its type is unsigned int.

Here's a sample CLI interaction: