char* combine(char* s, char* t) { ... }

Opinions differ on whether the * should be next to the type or next to the identifier. I prefer putting it next to the type.

I mean, short of enabling declarations like:

    char *a, *b;

  char* a, b;

  char b, *a;

  char *a, *b;

    char* a, b;

I assume there was some reason originally, but it's made everything a bit more confusing ever since for a lot of people. :/

Edit: Apparently it's so declaration mirrors use. Not a good enough reason IMO. But plenty of languages have warts and bad choices that get brought forth. I'm a Perl dev, so I speak from experience (even if I think it's not nearly as bad as most people make out).

C does this very cute (read: horrifyingly unintuitive) thing where the type reads how it's used. So "char ⋆a" is written so because "⋆a" is a "char", i.e. pointer declarations mimic dereferencing, and similarly, function pointer declarations mimic function application, and array declarations mimic indexing into the array.

It helped than I've learned by K&R C book. Windows API and code examples are horrific, like another language.

https://docs.microsoft.com/en-us/windows/win32/learnwin32/wi...

https://docs.microsoft.com/en-us/windows/win32/learnwin32/ma...

  char *

  int a

  char* a

The fly in this ointment is that C type syntax doesn’t want to work that way. It’s designed to make the definition of the variable look like the use of the variable. A clever idea, but unlike nearly every other language, which BTW is why I think you should really use typedefs for any type at all complicated in C.

For example, the type-then-variable style falls down if you need to declare an array

  int foo[4]

  int *(*a)(void)

So I’m perfectly willing to do it the “C way”, I just find out more readable to do it the other way unless it just won’t work (and then prefer to use typedefs to make it work anyway).

Note that this was rethought for Go syntax.

  char *a         => *a is a char
  char a[3]       => a[i] is a char
  char f(char)    => f(c) is a char
  char (*f)(char) => (*f)(c) is a char (short form: f(c))

sizeof(a[3]) is not evaluating a[3], so it also isn't UB.

  int const * const i;

In the above, you're declaring the types of * a and * b to be char, making a and b pointers to char.

(EDIT: how do you escape * properly inline with other text?)

   main(int argc, char **argv)

   main(int argc, char* *argv)

   main(int argc, char** argv)

   main(int argc, char* argv[])

    char * a;

In C++, the same line declares a variable, `a`, of type `pointer-to-int`.

C cuddles the asterisk up to the variable name to reflect use. C++ cuddles it up to the type because it's a part of the type. Opinions don't really differ on whether C-style or C++-style is better, but a lot of cargo-cult programmers don't bother adjusting the style of the code snippet they paste out of Stack Exchange so you see a lot of mixtures.

https://wozniak.ca/blog/2018/06/25/1/code.html

The difference is the function prototype `void newprint(char *, int);` at the start, which is missing in the second example. With the forward declaration, the compiler knows what arguments newprint takes and errors out if you pass something else. C is compiled top to bottom so in the older version of the example the compiler has no way of knowing what number of arguments the function takes at the point whree it is called. In (not so) old versions of C that implicitly declared a function taking whatever you passed it.

Because the parameter passing was uniform, you didn't need to inspect anything at the call site. All functions get called the same, so just push your params and call it. Types were for the callee and were optional. This is what powered printf, surely the highest expression of K&R C.

In modern C-lineage style, we enumerate our formal parameters, and variadic functions are awkward and rare. But LISP and JavaScript embrace them; perhaps C could have gone down a different path.

The interesting thing is that with K&R C a function declaration/prototype is optional. That means you can call a function that the compiler has not even seen. Mismatches in parameter/return types (which are optional and default to int in declarations as well) are normally not a problem, because of the aforementioned promotion. If you have the declaration, then the compiler will at least let you know about wrong number of arguments.

But I think it's good to know other pitfalls:

- The "default" return type of a function is int

- A function that does not use void to tell that it takes no argument just have an undefined number of parameters

See this example: https://ideone.com/GfwS4O

You could in theory use the address of a local variable (allocated on the stack) to access the arguments passed to the function directly on the stack.

But this is just madness... Or is it ? Isn't C just assembly with a "nicer" syntax ?

Here is the "modern" equivalent:

char combine(char s, char* t) {

As an aside it's not always more verbose because you can group parameters by type, eg:

  int foo (c1, i1, c2, i2)
    char c1, c2;
    register int i1, i2;
  {
  ...

  char *combine(char *s, char *t)

As of the 2011 standard, that's still the case. I think that C2X will finally remove them.

modern syntax is:

    char *Combine(char *S, char *T) {

        ...
    }