On 19. 5. 26 22:12, Timofei Zhakov wrote:
On Tue, May 19, 2026 at 8:52 PM Nathan Hartman
<[email protected]> wrote:
On Tue, May 19, 2026 at 1:37 PM Branko Čibej <[email protected]> wrote:
On 19. 5. 26 19:10, Timofei Zhakov wrote:
On Tue, May 19, 2026 at 5:02 PM Branko Čibej
<[email protected]> wrote:
On 19. 5. 26 15:19, Timofei Zhakov wrote:
On Mon, May 18, 2026 at 11:20 PM Branko Čibej
<[email protected]> wrote:
On 18. 5. 26 22:27, Ivan Zhakov wrote:
On Mon, 18 May 2026 at 21:24, Timofei Zhakov
<[email protected]> wrote:
On Mon, May 18, 2026 at 5:22 PM Branko Čibej
<[email protected]> wrote:
On 18. 5. 26 17:04, Ivan Zhakov wrote:
[..]
Yes, especially because the Unix and Win32
versions share a lot of things in common but
sometimes need to do it in a slightly different
way.
Also what do you guys think about the fact that
Win32 apr.h includes windows.h? It seems odd to
me. APR promises to eliminate platform
dependence by wrapping everything into
POSIX-ish style API
Cross-platform API. I'm not sure what you mean by
POSIX-ish, but APR isn't that.
I mean that the API is similar. For example,
apr_file_open() kind of works almost like fopen(). Not
exactly but in my head I have this connection. Okay
their signatures are very different and even naming, but
I think there is some pattern of doing the same thing
but in a slightly more modern way with a bit more control.
without extra unneeded junk and then all high
level code essentially has GetLastError in the
scope. I think if one wants to explicitly use
win32 API, they should include those headers
themselves.
It's a good question. I agree that apr.h should not
depend on system headers like Windows.h. But one
reason that Windows error codes are used in
apr_errno.h.
apr.h is a generated, /system-specific/ header. Of
course it can and should depend on system headers if
it needs them. It also includes sys/types.h and
sys/socket.h and sys/wait.h and os2.h and so on,
depending on the target. That makes perfect sense.
The question I have is whether we really want it or not.
In reality it's always included in every source file.
Take svn_wc.h for example:
[[[
#include <apr.h>
#include <apr_pools.h>
#include <apr_tables.h>
#include <apr_hash.h>
#include <apr_time.h>
#include <apr_file_io.h>
#include "svn_types.h"
#include "svn_string.h"
#include "svn_checksum.h"
#include "svn_io.h"
#include "svn_delta.h" /* for svn_stream_t */
#include "svn_opt.h"
#include "svn_ra.h" /* for svn_ra_reporter_t type */
]]]
You'll have to be more specific: what exactly is wrong
with that? apr.h uses symbols defined in windows.h, what
else is it supposed to do? I really don't understand your
objections.
It shouldn't use any symbols from it. That's what I'm saying.
However, there are a few places that currently potentially do
use it:
[[[
#if APR_HAS_UNICODE_FS
/* An arbitrary size that is digestable. True max is a bit
less than 32000 */
#define APR_PATH_MAX 8192
#else /* !APR_HAS_UNICODE_FS */
#define APR_PATH_MAX MAX_PATH
#endif
]]]
and
[[[
/* Appears in later flavors, not the originals. */
#ifndef in_addr6
#define in6_addr in_addr6
#endif
#ifndef WS2TCPIP_INLINE
#define IN6_IS_ADDR_V4MAPPED(a) \
( (*(const apr_uint64_t *)(const void
*)(&(a)->s6_addr[0]) == 0) \
&& (*(const apr_uint32_t *)(const void
*)(&(a)->s6_addr[8]) == ntohl(0x0000ffff)))
#endif
]]]
(MAX_PATH, ntohl, in_addr6 are the ones affected)
I really think those should be somewhere in private headers
or in the sources. MAX_PATH is fine. But ipv6 magic - I don't
like it.
I really don't know what to say (that isn't sarcastic or
condescending). Please take some time to research the
consequences of what you're suggesting and while you're doing
that, think wider than just Windows. I'll give you a hint: the
key words are "APR" and "API".
I guess I didn't quite reach the !(sarcastic || condescending)
goal. My apologies.
Then we basically just have a header that nobody uses. It
also brings a lot of stuff into the autocomplete.
That's just about the worst argument for a wrong technical
proposal that I've ever seen. Get a better editor.
-- Brane
At $dayjob we have a portability library of sorts and, like APR,
it includes various system headers. Which ones depends on the system.
I think when using APR as a consumer, ideally no system API should be
used. Users should use wrappers instead and avoid calling win32 API
directly (unless they really need it of course).
Let's be clear here. Including some declarations is not the same as
calling Win32 APIs. Nothing that apr.h does exposes any Win32 types in
the APR API.
Wrapping some symbols into the APR namespace is different, expected, and
correct. Your proposal to pull some magic number out of thin air for the
value of APR_PATH_MAX is just wrong.
You really don't need system's headers to create a file.
Irrelevant.
The only exception where APR exposes system's types is apr_portable.h.
apr_portable.h does something completely different than apr.h: it
declares APR functions that return or consume system types.
This of course cannot be changed.
And shouldn't. You're implying there's something wrong with that. There
isn't.
Just to use this one example, MAX_PATH depends on the system so
whatever program you build with the library will need to know what
it is, for array sizing and other purposes.
If you really want to eliminate all system headers, you could
consider a "null system" which would include no system headers at
all. It probably wouldn't build or run, but it might be useful for
things like static analysis where you don't want the details of
any particular system to influence the analysis. Any functions
that must be provided by the underlying system would need to be
NOPs or perhaps simulated in some way.
Cheers,
Nathan
PS, This is a separate topic than CMake, unless there's a
connection I missed?
Yeah... Timofei, pleas start a new thread if you want to further discuss
APR design and philosophy.
-- Brane
