1. GHA/windows: enable WinIDN in Linux cross-builds.
(to reveal the issue in CI.)
2. fix compiler warning when building with mingw-w64 supporting
WinIDN, while targeting pre-Vista Windows, with a `WINVER` set to
target Vista or newer. (Such was Ubuntu's mingw-w64 with the
classic-mingw-specific trick in point 3 of this PR.)
```
../../lib/idn.c:154:23: error: redundant redeclaration of ‘IdnToAscii’ [-Werror=redundant-decls]
154 | WINBASEAPI int WINAPI IdnToAscii(DWORD dwFlags,
| ^~~~~~~~~~
In file included from /usr/share/mingw-w64/include/windows.h:73,
from /usr/share/mingw-w64/include/winsock2.h:23,
from ../../lib/setup-win32.h:91,
from ../../lib/curl_setup.h:308,
from ../../lib/idn.c:29:
/usr/share/mingw-w64/include/winnls.h:1075:30: note: previous declaration of ‘IdnToAscii’ was here
1075 | WINNORMALIZEAPI int WINAPI IdnToAscii (DWORD dwFlags, LPCWSTR lpUnicodeCharStr, int cchUnicodeChar, LPWSTR lpASCIICharStr, int cchASCIIChar);
| ^~~~~~~~~~
[...same for IdnToUnicode...]
```
Ref: https://github.com/curl/curl/actions/runs/10542832783/job/29210098553#step:7:89
3. drop `WINVER` override for classic-mingw. curl no longer supports
building with classic-mingw.
Reverts 37f1c21cb9#7581
4. sync `if IdnToUnicode can be linked` detection snippet with the live
code in `lib/idn.c`. It fixes detection for the scenario in point 2.
5. delete unused `WINIDN_DIR` variable.
Bug: https://github.com/curl/curl/pull/12606#issuecomment-1885381038
Previous abandoned attempt: #12684
Reviewed-by: Jay Satiro
Closes#14680
Add flags UIDNA_NONTRANSITIONAL_TO_ASCII and
UIDNA_NONTRANSITIONAL_TO_UNICODE to encode ß correctly.
It fixes test 165.
Reported-by: Viktor Szakats
Bug: #14176Closes#14179
Based on the standards and guidelines we use for our documentation.
- expand contractions (they're => they are etc)
- host name = > hostname
- file name => filename
- user name = username
- man page => manpage
- run-time => runtime
- set-up => setup
- back-end => backend
- a HTTP => an HTTP
- Two spaces after a period => one space after period
Closes#14073
I implemented the IDN functions for macOS and iOS using Unicode
libraries coming with macOS and iOS.
Builds and runs here on macOS 14.2.1. Also verified to load and
run on older macOS version 10.13.
Build requires macOS SDK 13 or equivalent.
Set `-DUSE_APPLE_IDN=ON` CMake option to enable it.
With autotools and other build tools, set these manual options:
```
CPPFLAGS=-DUSE_APPLE_IDN
LIBS=-licucore
```
Completes TODO 1.6.
TODO: add autotools option and feature-detection.
Refs: #5330#5371
Co-authored-by: Viktor Szakats
Closes#13246
Windows compilers define `_WIN32` automatically. Windows SDK headers
or build env defines `WIN32`, or we have to take care of it. The
agreement seems to be that `_WIN32` is the preferred practice here.
Make the source code rely on that to detect we're building for Windows.
Public `curl.h` was using `WIN32`, `__WIN32__` and `CURL_WIN32` for
Windows detection, next to the official `_WIN32`. After this patch it
only uses `_WIN32` for this. Also, make it stop defining `CURL_WIN32`.
There is a slight chance these break compatibility with Windows
compilers that fail to define `_WIN32`. I'm not aware of any obsolete
or modern compiler affected, but in case there is one, one possible
solution is to define this macro manually.
grepping for `WIN32` remains useful to discover Windows-specific code.
Also:
- extend `checksrc` to ensure we're not using `WIN32` anymore.
- apply minor formatting here and there.
- delete unnecessary checks for `!MSDOS` when `_WIN32` is present.
Co-authored-by: Jay Satiro
Reviewed-by: Daniel Stenberg
Closes#12376
- Return CURLE_URL_MALFORMAT if IDN hostname cannot be converted from
UTF-8 to UTF-16.
Prior to this change a failed conversion erroneously returned CURLE_OK
which meant 'decoded' pointer (what would normally point to the
punycode) would not be written to, remain NULL and be dereferenced
causing an access violation.
Closes https://github.com/curl/curl/pull/11983
Some IDN sequences are converted into "" (nothing), which can make this
function end up with a zero length host name and we cannot consider that
a valid host to continue with.
Reported-by: Maciej Domanski
Closes#10617
- they are mostly pointless in all major jurisdictions
- many big corporations and projects already don't use them
- saves us from pointless churn
- git keeps history for us
- the year range is kept in COPYING
checksrc is updated to allow non-year using copyright statements
Closes#10205
