search for: midipix

AKA: MinGW + win32threads is holding LLVM (and all of its subprojects) back. We need to stop supporting this host platform. I'm aware of essentially 2 reasonably important use cases for supporting MinGW + win32threads: 1) Sane host toolchain on Windows that doesn't require downloading MSVC. (I'm dubious about the value of this one...) 2) Cross-compiling a Windows clang.exe (and

...efined Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: major Priority: P5 Component: sshd Assignee: unassigned-bugs at mindrot.org Reporter: writeonce at midipix.org Created attachment 2487 --> https://bugzilla.mindrot.org/attachment.cgi?id=2487&action=edit loginrec.c: change the 'ut' typo to 'utx' where applicable In loginrec.c: construct_utmpx(), the effective code path when HAVE_ADDR_V6_IN_UTMP is defined contains a typo which...

I’m not totally sold on the idea of having it be a layer between system libc and application. I think this is likely to create a split between windows and non windows that will be difficult to overcome. It also seems like it brings with it its own set of difficulties. Where can you make a separation in libc such that you’re guaranteed that the two pieces do not share any state, especially given