-fpic is a single letter option, -f, followed by the parameter pic. Clang still uses two hyphens for long options including --help.
There are tons of options that start with -f and can't be decomposed in that way [1, e.g. -framework]. They are essentially atomic options with a loose naming convention.
Correct. You cannot use “ramework” as an argument to “-f”. Instead use two dashes and it is unambiguous.
It took me some thoughts to realize what you wanted to say, and you are incorrect: there is no single option `-f` in cc options! `-f` is just a common prefix of hundreds of independent options, like `-fsanitize=...` (which can't be used as `-f sanitize=...`). As I've iterated before, those prefixes mostly represent broad categories of options and not hard and fast rules: `-g` for debug, `-i` for directories, `-m` for target architectures, `-W` for warnings, and `-f` for virtually everything else.
But maybe we should talk about the lack of space character between the flag and the argument…
That's just how short options with arguments work in getopt POSIX land: '-oARG' is equivalent to '-o' 'ARG' just like '--option=ARG' is equivalent to '--option' 'ARG' (for GNU long options). This means that you cannot chain any other short options after one with an (optional) argument but otherwise does not cause any problems.
Yes not every Linux/unix arg parser conforms to posix, some require a space, others do not.
To be fair to Clang, the -arguments are inherited from GCC for compatibility (which perhaps inherited them from other CCs) and then extended from there in the most consistent way possible. Similarily, clang-cl supports cl.exe-style flags for drop-in compatibility.
saneclang, saneswift, (sanegcc?) cli wrappers around clang, swift which fix the insane porcelains of those toolchains.
We built a million GUIs for these, why did we never build CLIs for bad CLIs?