assert is defined in the C standard, you don't have it in OS/400?

I just made a symbols fix, can you try it?
https://github.com/jay/curl/compare/fix_os400_symbols
I don't know what to do about the assert calls yet until you get back to me.

Thanks jay, the symbols fix works great.

OS/400 does have an assert.h, I think the problem here is that the code only "#include <assert.h>" if HAVE_ASSERT_H is defined (but it is not defined by packages/OS400/initscript.sh).

Even so, would it not be appropriate to be able to disable asserts in a build ? Looks like in memdebug.c for platforms that don't have this, assert is defined as a macro to Curl_nop_stmt.

assert.h is a standard header since C89 so I don't know why HAVE_ASSERT_H. Who doesn't have it? I suppose we could define it for OS400 but I'd rather get rid of it altogether.

would it not be appropriate to be able to disable asserts in a build

Another thing I don't know. Why are regular asserts used in those places instead of DEBUGASSERT? Some of the curl build systems define NDEBUG (makes assert a no-op) and some don't so there is some inconsistency in using assert.

OS/400 doesn't use configure like UNIX platforms so the "HAVE_xxx_H" macro needs to be defined in the script. Defining it in initscript.sh fixes the build, but you are right, if we expect every platform to have assert.h then its debatable whether it should be behind a conditional directive in the first place.

Why are regular asserts used in those places instead of DEBUGASSERT?

Just sloppiness I think. We should add a check for that to checksrc to make sure we don't let them slip through...

Apparently assert.h can be missing on WinCE sometimes, but I think this is a problem of WinCE. assert.h should always be available unless freestanding (ie we aren't using standard libraries and OS functions).

First draft removes guards around assert.h and limits.h, both standard headers. In addition assert is banned everywhere except tests/. Could assert be useful in tests or elsewhere where an assert is needed if not a DEBUGBUILD? For example all the asserts in memdebug I changed to DEBUGASSERT, but is that a good idea? For example someone is debugging without DEBUGBUILD? I'm having second thoughts, maybe there is reason I am not aware of it is useful to have both assert and DEBUGASSERT?

https://github.com/curl/curl/compare/master...jay:build_ban_assert?expand=1

I'm not sure I see the value in removing the #ifdef protections around the headers. They may be standard, but I'm sure there are lots of platforms and compilers out there that don't totally adhere to standards. Now I tried to research why we added the configure checks for them but the commits were light on details and very old so I couldn't figure that out.

I would suggest that we leave the checks and #ifdefs for them, but change to DEBUGASSERT() all over. With DEBUGASSERT it seems more up to us to control if they're present in a non-debug build or not. I'm not sure users will actually set NDEBUG.

Since commit 8589e1f, we only use DEBUGASSERT() and we should stick to that going forward. I thus think this issue is fixed.