@telephon that branch has dubious quality and someone will have to go through it in order to separate the good parts from the crap

@timblechmann, while your review of PRs is very useful and appreciated, please don't call other people's contributions crap. We have a hard enough time keeping developers involved, especially on the Windows version, and using insulting language adds nothing useful to the discussion.

Tim must have meant something like "dross" here. Yes, I'd also appreciate if someone could clean it up, but I think we have to live with it as it is for now and merge master into it if we can (not the other way round).

i've spend a significant time to review that PR and gave a huge amount of comments, which parts are useful and important (the parser part), which parts i don't consider badly researched and going to the wrong direction (not using local sockets) ... and unfortunately there are some parts, which are semantically wrong, violating the coding style, hardcoding a specific setup etc ...

the important parts should go in: someone will have to look at the diff and take the useful parts out. tbo, this should not take longer than an hour or so. the socket part should go to a branch and a bug should reported upstream, so it can be tracked and fixed by the qt developers. the part that does is wrong or violating standards or has nothing to do with the actual changes should not go it.

it is pretty unfortunate that the original author never tried to address those comments or even doubted that there was anything wrong with that code.

btw, @muellmusik: you might also want to consider that the lack of code quality, a software architecture from the last millenium and resistance of the community to adopt state of the art technologies keeps people away from contributing. personally i would contribute much more, if the community would favor a clean and robust architecture more than having nice-to have features of dubious code quality of compatibility with ancient technologies.

side note: i continued to contribute a significant amount of code to supercollider despite (1) homophobic hate mails and (2) complaints by academics (read: professors of well-known universities) about how much bad things i had done to supercollider, after spending (edit: after i have spent) dozens of hours isolating and fixing a bug that was introduced by a community member, who stopped contributing code a long time ago ...

so don't get me wrong, but people who contribute to any project should be aware of the fact that their code is going to be criticized and they will be encouraged to improve it .... this is nothing personal, but helps the long-term maintenance!

side note: i continued to contribute a significant amount of code to supercollider despite …

thank you, your contributions are welcome!

"refactoring"
"this makes the codebase much more robust ..."
"include: common - all modern compilers support c99
this includes msvc"

None of these are helping me to understand the implications of changing these typedefs.

but its better to use uint32_t rather than unsigned int because the later could change on a future machine and would then not be 32 bits.

and the _WIN32 alternative is no longer needed

uint32_t has a standardized size, unsigned int doesn't ... compare https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models and #1692 and #1693