Per bug #76651 these changes do not appear to work correctly in
some cases. As no immediate fix seems to be forthcoming, I'm
reverting these changes.
Revert "Fixed invalid free introduced by d6e81f0bfd (avoid keeping "invalid" pointer)"
This reverts commit 11507c0e1b.
Revert "Fix mysqlnd build without openssl"
This reverts commit 6c9db02ff7.
Revert "Fix VC compilation as variable size array is not supported"
This reverts commit f96df64cb2.
Revert "Fix MySQL 8 auth"
This reverts commit d6e81f0bfd.
??= is a trigraph for #, so it needs to be escaped. To stay
consistent I'm escaping all question marks in this literal, even
though one of the latter two would suffice.
On line 512, I clarified the sentence which uses effect, previously the sentence was awkward.
On line 656, the wrong word is used, I changed affect to effect.
Autoconf 2.59d (released in 2006) [1] started promoting several macros
as not relevant for newer systems anymore, including the `AC_HEADER_TIME`.
This macro checks if both `<sys/time.h>` and `<time.h>` can be included
at the same time and defines the `TIME_WITH_SYS_TIME` and
`HAVE_SYS_TIME_H` symbols. On current system such check is not relevant
anymore because in case both headers are present both can be also
included at the same time.
This patch simplifies this checking.
Refs:
[1] http://git.savannah.gnu.org/cgit/autoconf.git/tree/NEWS
[2] https://www.gnu.org/software/autoconf/manual/autoconf-2.69/autoconf.html
Autoconf 2.59d (released in 2006) [1] started promoting several macros
as not relevant for newer systems, including the `AC_C_CONST`.
The `const` keyword is used in C since C89. On old systems some compilers
lacked the `const` and this macro defined it to be empty. This check was
relevant on systems with compilers before C89 and on current systems it
can be omitted. [2]
PHP also requires at least C89 so `const` is always available.
Refs:
[1] http://git.savannah.gnu.org/cgit/autoconf.git/tree/NEWS
[2] https://www.gnu.org/software/autoconf/manual/autoconf-2.69/autoconf.html
According to the POSIX specification of `getgrnam_r()` the result of
`sysconf(_SC_GETGR_R_SIZE_MAX)` is an initial value suggested for the
size of the buffer, and `ERANGE` signals that insufficient storage was
supplied. So if we get `ERANGE`, we try again with a buffer twice as
big, and so on, instead of failing.
As stated by RFC 5890, U-Labels might be up to 252 Unicode code points
long. This can be fixed in 7.1+ as well, but there might potentially be
issues in some existing apps expecting the output to be max 255 octets
long. Thus it seems to be safer to not to touch stable branches.
This reverts changes made in 2f700384 and 4fcaebba. This test is
supposed to run
only on Windows indeed, as in a Unix environment with a mail server
configured,
an email will be send. On Windows, only emptying the SMTP ini directives
is enough.
The checks can issue reads below and above the temporary buffer. A read
itself doesn't seem dangerous, but the condition result can be
arbitrary. Such reads have to be avoided. Likely this patch should be
backported.
(cherry picked from commit b053beee7e)
