This website has helped me out on various occasions to figure out what was going on: http://cdecl.org/ (it won't say if something is illegal though or not)
First, symbols. Read
* as "pointer to" - always on the left side
[] as "array of" - always on the right side
() as "function returning" - always on the right side
If all of these type operators were on the right side, there would be no need for such a guide. Parenthesis would never be necessary for type declarations, and they could be read in one direction.
It's unclear why C authors chose to have both prefix and postfix type operators.
Similarly, the value-level dereference operator could be post-fix, avoiding the need for (->), and making it much easier to dereference and subscript array pointers. That would make it feasible to pass arrays by pointer-to-array, allowing to feasibly pass them by value and have simpler and more consistent language semantics.
Though I absolutely dislike the excessive use of typedefs (e.g. Windows with its use of DWORD_PTR instead of unsigned long * or uint32_t * ), I think it's appropriate to use a typedef or two to simplify declarations of function pointers which themselves accept or return function pointers.
Oracle OCI does this, but it's clear why: Oracle has supported some 90 platforms over its long history, many of which no longer exist, or are no longer supported, and it's not inconcievable that more will be supported in future. So instead of char* you say OraText* (for example, there are loads of these) and for that you get Oracle's guarantee that your code will compile everywhere Oracle runs.
It does makes sense for multi-platform software that predates C99's precisely-sized integer types. I first got my taste of them through a rough predecessor, the u32/i32/etc. types in the Linux kernel. I see them as a much more transparent approach to portability for system-level software, but concede that higher-level software may wish to preserve more meaning in some its type names (as in your example of OraText vs char). This still doesn't excuse DWORD_PTR, IMO :).
I'm still unsure how everyone feels about blocks. I love them myself and it's changed everything for me. I'm not sure the entire community is sold yet though. Apple's variants of GCC and Clang have them, but last I checked, no GCC variants on the lastest Linux distros I've used have them yet.
Although Apple's changes are released under the GPL, since Apple is no longer doing copyright assignment back to the GNU for it's fork of the GCC it maintains (it doesn't have a procedure in place to do it anymore according the LLVM guys), the changes will have to reimplemented again by someone that can assign copyright to the FSF/GNU or the FSF/GNU guys will have to make an exception to their rules to accept the code (which they will probably never do).
However, blocks are available IIRC to Clang should work under any Linux distro that has made the switch.
