Corrected description of pointer operator-macro order.

README/API_AND_NAMESPACE.md

@@ -36,7 +36,7 @@ The `TIDY_EXPORT` call clearly indicates that this function prototype is meant t
 
 Although this makes things obvious from the documentation perspective, the truth is a little murkier. In some environments one might define `TIDY_EXPORT` and `TIDY_CALL` differently in order to control compiler behavior, especially in environments that have special requirements for dynamic libraries. In general, though, you shouldn't have to worry about this.
 
-Note that MSVC has issues with macros inserted before pointer operators, and so the preferred use of pointer operators when documenting with macros is this:
+The preferred use of pointer operators when documenting with macros is this:
 
 ~~~
 const tidyLocaleMapItem* TIDY_CALL getNextWindowsLanguage( TidyIterator* iter )

README/CODESTYLE.md

@@ -18,7 +18,7 @@ From reading of the Tidy source, some things are self evident,  in no particular
  - No C++ single line comments using `//`.
  - The openning `{` is indented on the next newline.
  - While the maximum code line length varies, generally long `if`, `while`, ... statements are wrapped to newlines.
- - For compatibility with MSVC, pointer operators in declarations must precede any macro documentation, e.g, `const tidyLocaleMapItem* TIDY_CALL getNextWindowsLanguage( TidyIterator* iter )` instead of `const tidyLocaleMapItem TIDY_CALL *getNextWindowsLanguage( TidyIterator* iter )`.
+ - Pointer operators in declarations must precede any macro documentation, e.g, `const tidyLocaleMapItem* TIDY_CALL getNextWindowsLanguage( TidyIterator* iter )` instead of `const tidyLocaleMapItem TIDY_CALL *getNextWindowsLanguage( TidyIterator* iter )` in case `TIDY_CALL` is defined.