delta/curl.git, branch bagder/generate-lib1521

libtest/CMakeLists: generate lib1521.c

2017-06-27T11:57:32+00:00

libtest/Makefile.am: add mk-lib1521.pl to the tarball

2017-06-27T09:58:44+00:00

libtest/make: generate lib1521.c

2017-06-27T08:19:32+00:00

... instead of having the generated code checked in. This saves space in
the tarball but primarily automatically adapts to newly added options.

tool_getparam: fix memory leak on test 1147 OOM (torture tests)

2017-06-26T05:05:02+00:00

Bug: https://github.com/curl/curl/pull/1486#issuecomment-310926872
Reported-by: Dan Fandrich

test1537: fixed memory leak on OOM

2017-06-25T20:59:55+00:00

test1521: fix compiler warnings

2017-06-25T11:46:51+00:00

The integer literal 3123123123 doesn't fit into a 32-bit signed
integer, so GCC with 32-bit long warns in C90 mode:
this decimal constant is unsigned only in ISO C90 [enabled by default]
Fix this by using ULONG_MAX, which should fit in any curl_off_t and has
the correct suffix to not issue any warnings.
Also adds the missing CURLOPT_REQUEST_TARGET from commit
9b167fd090f596eac828817d48c247eeae53407f.

Closes https://github.com/curl/curl/pull/1611

curl/system.h: add check for XTENSA for 32bit gcc

2017-06-24T20:26:54+00:00

Reported-by: Neil Kolban
Fixes: 1598

winbuild: fix boringssl build

2017-06-24T20:13:21+00:00

Compile with `WIN32_LEAN_AND_MEAN` which prevents `windows.h` from
including too much clutter including `wincrypt.h` which in turn contains
some preprocessor macros that clash with boringssl symbols.

Detect boringssl by checking the existance of `is_boringssl.h` and set
the corresponding `HAVE_BORINGSSL` for compilation which is used in
`ldap.c` to undefine the evil macros.

Closes #1610

progress: progress.timespent needs to be us

2017-06-24T19:14:50+00:00

follow-up to 64ed44a815e4e to fix test 500 failures

curl-compilers.m4: fix unknown-warning-option on Apple clang

2017-06-24T09:10:38+00:00

Since 5598b0bd63f690c151074494ce47ef872f004ab4, clang -v is used to
detect the clang version. The version number was expected to come after
the word "version". For Apple clang, this doesn't work as it has its
own versioning scheme.
The version number is now first searched after the string
"based on LLVM". This works for Apple clang before version 7, and also
for e.g. Ubuntu's clang up to version 3.7. If it's not found and the
version string contains "Apple LLVM version", clang version 3.7 is
assumed, which is the version that comes with Xcode 7. Otherwise, the
version number is still expected after the word "version", which works
for very old Apple clang versions.

Ref: https://trac.macports.org/wiki/XcodeVersionInfo
Fixes https://github.com/curl/curl/issues/1606
Closes https://github.com/curl/curl/pull/1607