I would like to follow the MISRA C++:2023 coding guideline. But it targets C++17, while the code and compiler follow C++14.
The document reads:
The guidelines within this document target C++17, and they may not be appropriate or adequate when applied to other versions of the language — specifically, additional guidelines may be needed to prevent undesirable behaviours that arenot covered by this document.
But I would see C++14 as a subset of C++17 (with only few breaking changes). Would I not be MISRA-C++-2023 compliant or only with additional rules?
The MISRA C++:2023 document itself is non-public, so it's hard to give an authoritative answer. However, your question boils down to "Can I write C++14 code that conforms to MISRA C++:2023?" and the answer is "Of course you can."
Now, suppose MISRA C++:2023 had said "Rule 42.42: Every program must contain at least one fold-expression." Then you'd be out of luck, because there's no way to write a C++14 program that conforms to that rule. But I'm pretty sure that MISRA C++:2023 doesn't actually say any such thing. As @Lundin commented, MISRA is more interested in banning newfangled features than mandating them.
Second: As @NathanOliver commented, MISRA C++:2023 might say something like "Rule 42.43: Ensure that no object is modified twice in the same expression, unless it's on opposite sides of an assignment expression. For example (a++) + (a++)
is forbidden, but (a++) = (a++)
is permitted." You would have to be smart enough to realize that even though (a++) = (a++)
was permitted by MISRA C++:2023, it was still forbidden (that is, UB) in C++14. (The behavior of that expression wasn't defined until C++17.) So this won't physically prevent you from writing good code in the intersection of C++14 and MISRA C++:2023... but it does mean that some parts of the document might be misleading, and you'd have to watch out for that.
However, that's par for the course in C++. Even if you were using the latest and greatest MISRA C++:2023 with C++23 or whatever, you could still easily write a program with bugs in it, either by not knowing the quirks of the language or simply by, you know, writing bugs. Following MISRA's rules cannot eliminate that chance. So, I don't think there's any qualitative difference between
writing code in the intersection of MISRA C++:2023 and well-defined C++17 and correct program behavior
writing code in the intersection of MISRA C++:2023 and well-defined C++14 and correct program behavior
The latter won't really be any harder than the former.
Finally, what about tooling? To assert you're staying within MISRA C++:2023, you need a compiler that diagnoses MISRA C++:2023 violations. Do you have one? Does that compiler support C++14? If it doesn't, then again you're completely out of luck. If it does, then I'm sure you're fine.