3 ms·

How naive! > every C99/POSIX system supports the entry points they are guarding The most popular compiler, msvc, still cannot support C99/POSIX. And some of m

• Too 3y ago
  For a long time this was true but recently MS turned around and is now supposedly supporting even C17. https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/ https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-...
  • camel-cdr 3y ago
    Meanwhile you still need to add a special compilation flag to get a c89 and above compatible preprocessor: https://learn.microsoft.com/en-us/cpp/build/reference/zc-preprocessor?view=msvc-170 https://learn.microsoft.com/en-us/cpp/build/reference/zc-pre...
    • Kwpolska 3y ago
      Default flags of compilers tend to prefer backwards compatibility over correctness and modernity. Passing flags to make the compiler behave correctly or report all errors is nothing new.
      • camel-cdr 3y ago
        Yes, but it shouldn't take +35 years to change the default to the correct behavior.
• jraph 3y ago
  Do one run ./configure on Windows to compile with msvc? (genuine question, not familiar with this)
  • rurban 3y ago
    No, you'd use cmake
  • bregma 3y ago
    No. One uses Linux plus mingw to cross build for a Windows host. ./configue --build=x86_64-pc-linux-gnu --host=x86_64-pc-mingw64 It usually magically just works, as long as the project author has a clue about portability. That's generally the limiting factor.
    • bhaak 3y ago
      This. I have a project that has the additional problem that during building some generated Windows binaries have to be called. On Debian with wine-binfmt the build can call the crosscompiled intermediate binaries and have them executed with Wine. Pretty crazy but it works.
• MaulingMonkey 3y ago
  > entry points I was curious where this was from, so I looked at https://gitlab.com/esr/autodafe/-/blob/master/de-autoconfiscation.adoc?ref_type=heads#user-content-deconditionalize-c99posix-features https://gitlab.com/esr/autodafe/-/blob/master/de-autoconfisc... As someone who targets clang/gcc/msvc/icc, I don't see much value in these defines. Let's pick on HAVE_STRDUP: what's the point? If it's always defined on your target platforms, just use the stdlib unconditionally - the define is pointless. If it's never defined on your target platforms, you'll have to roll an alternative of your own no matter what - the define is pointless. So the presumed theoretical use case for this is if you sometimes want to define your own, and sometimes want to use the standard library. But do I actually want that? Rarely. Very rarely. If I care to target old systems, I'd generally rather unconditionally define my own version that doesn't conflict with the standard library, that gets tested and used in all builds on all platforms - it'll be less code than adding a bunch of #ifdef soup, and it'll be less brittle - no "works on my machine but fails on the build server" nonsense because of a typo in sometimes-dead code. That leaves one even narrower use case which isn't entirely theoretical: wanting to backport a modern codebase to an "ancient" toolchain/stdlib via polyfills without touching the modern codebase or the toolchain/stdlib. That approach has it's niches, but... it is worth emphasizing, niches.
  • vidarh 3y ago
    There are some few cases where I'd probably prefer the "standard" version where available: memcpy etc. that are often extensively optimised, and that are a lot of work to write a non-naive version off that performs well. But I agree that most of the time you categorically should not use feature detection like that, and in the few cases you're dealing with systems lacking things that basic you have bigger problems...
• camel-cdr 3y ago
  Almost nobody writes POSIX make, the vast majority of makefiles use GNU make extensions.
  • rurban 3y ago
    Exactly. bmake is the only true make