C entry point generator: no unconditional conversion to pointer type

Do not try to create a pointer_typet when the type might not actually be
a pointer type. This was triggerable by syntactically well-formed C
input and should instead be handled by a user-facing error message.

Fixes: #6975

Author: tautschnig

regression/ansi-c/main1/main.c

@@ -0,0 +1,4 @@
+int main(char *argv, int arc)
+{
+  return 0;
+}

regression/ansi-c/main1/test.desc

@@ -0,0 +1,11 @@
+CORE test-c++-front-end
+main.c
+
+'main' with signature 'signed int \(char \*argv, signed int arc\)' found
+^EXIT=(64|1)$
+^SIGNAL=0$
+--
+Invariant check failed
+--
+This test is to ensure that non-standard C entry points are handled gracefully
+and with a message to the user.

src/ansi-c/ansi_c_entry_point.cpp

@@ -248,7 +248,16 @@ bool generate_ansi_c_start_function(
     {
       // ok
     }
-    else if(parameters.size()==2 || parameters.size()==3)
+    // The C standard (and any related architecture descriptions) enforces an
+    // order of parameters. The user, however, may supply arbitrary
+    // (syntactically valid) C code, even one that does not respect the calling
+    // conventions set out in the C standard. If the user does supply such code,
+    // then we can only tell them that they got it wrong, which is what we do
+    // via the error message in the else branch of this code.
+    else if(
+      parameters.size() >= 2 && parameters[1].type().id() == ID_pointer &&
+      (parameters.size() == 2 ||
+       (parameters.size() == 3 && parameters[2].type().id() == ID_pointer)))
     {
       namespacet ns(symbol_table);