Gabriela Moldovan wrote:
Hi,
On Sat Mar 18, 2023 at 1:05 PM GMT, Gisle Vanem wrote:
Hello list. Anybody out there?
Trying to compile Tor with 'cl' ver. 19.36.32323 from
yesterdays 'git master', I got this error in
'src/feature/hs/hs_metrics_entry.c':
hs/hs_metr
Hello list. Anybody out there?
Trying to compile Tor with 'cl' ver. 19.36.32323 from
yesterdays 'git master', I got this error in
'src/feature/hs/hs_metrics_entry.c':
hs/hs_metrics_entry.c(98,3): error C2099: initializer is not a constant
{
^
hs/hs_metrics_entry.c(106,3): error C2099: initia
Some recent change has added a:
#include
which fails for MSVC (it doesn't have it).
Since I fail to find any way to comment on Trac or Gitweb,
I give notice here. Patching into:
--- a/src/lib/net/buffers_net.c 2019-01-02 18:57:42
+++ b/src/lib/net/buffers_net.c 2019-01-03 03:16:32
@@ -21,7 +
Running 'test.exe bridges/clear_bridge_list' causes this assertion:
bridges/clear_bridge_list: May 23 17:12:53.714 [err] tor_assertion_failed_():
Bug: container.h:70: smartlist_get: Assertion sl->num_used > idx failed;
AFAICS, since 'sweep_bridge_list()' caused all entries in
'bridgelist' to
isis agora lovecruft wrote:
Thanks for the bug report and the patch! I've made #25479 [0] for this.
Can I ask what version of Windows you were running the benchmarks on?
Windows-10 (v1701). 64-bit.
It seems like it might possibly have been due to differences in behaviours
between various
I wrote:
Seems bench.c uses some mutex which is not initialised
with 'tor_mutex_init()'. I fail to see which that should
be.
With this patch, I no longer get that crash:
--- a/bench.c 2018-01-25 20:15:13
+++ b/bench.c 2018-03-13 12:38:09
@@ -713,6 +713,8 @@
printf("Couldn't seed RNG; exi
There is a crash in bench.exe. Running 'cdb -c g bench.exe':
ntdll!RtlpWaitOnCriticalSection+0x6b:
77a9cfd6 ff4014 inc dword ptr [eax+14h] ds:002b:0014=
ChildEBP RetAddr
0137f750 77aba38a ntdll!RtlpWaitOnCriticalSection+0x6b
0137f770 77aba259 ntdll!RtlpEnterCriticalSect
The 'IF_BUG_ONCE__' for non-gcc is wrong. A simple patch:
--- a/util_bug.h 2016-09-13 10:44:59
+++ b/util_bug.h 2016-09-08 20:24:45
@@ -117,7 +117,7 @@
#else
#define IF_BUG_ONCE__(cond,var) \
static int var = 0;
Seems these two OpenSSL functions:
ENGINE_get_default_ECDSA()
ENGINE_get_default_ECDH()
have been dropped; in util/libeay32.num:
...
ENGINE_get_default_ECDH 33871_1_0 NOEXIST::FUNCTION:
ENGINE_get_default_ECDSA36621_1_0 NOEXIST::FUNCTION:
...
https://raw.gi
The src/test/test_util.c have this statement:
#ifdef _WIN32
#define UTIL_TEST_NO_WIN(n, f) { #n, NULL, TT_SKIP, NULL, NULL }
#define UTIL_TEST_WIN_ONLY(n, f) UTIL_TEST(n, (f))
#define UTIL_LEGACY_NO_WIN(n) UTIL_NO_WIN(n)
But I fail to see where 'UTIL_NO_WIN(n)' is defined. Should not the
abov
ros when the compiler is not GCC. This avoids
failing compilations on MSVC, and fixes a log-file-based race
condition in our old workarounds. Original patch from Gisle Vanem.
I don't know what the "race conditions" is about, but this (?) change
broke MSVC again by a &#
Ping list?
Gisle Vanem wrote:
This gcc-centric macro in or/config.c doesn't work well in
MSVC v16/18:
#define COMPLAIN(args...) \
STMT_BEGIN log_warn(LD_CONFIG, args); STMT_END
Even MSVC v19 doesn't have such preprocessor magic. It's
gcc specific and not C99 I guess. Can
This gcc-centric macro in or/config.c doesn't work well in
MSVC v16/18:
#define COMPLAIN(args...) \
STMT_BEGIN log_warn(LD_CONFIG, args); STMT_END
I suggest it should be patched like this:
--- a/config.c 2015-05-06 22:22:09 +
+++ b/config.c 2015-05-06 23:15:57 +
@@ -2571,8 +2571
The "compat.h" is needed due to the use of 'OP_EQ', etc:
diff --git a/src/ext/tinytest_demo.c b/src/ext/tinytest_demo.c
index c07f099..cfb524b 100644
--- a/src/ext/tinytest_demo.c
+++ b/src/ext/tinytest_demo.c
@@ -30,6 +30,7 @@
/* Make sure you include these headers. */
#include "tinytest.h"
#
Nick Mathewson wrote:
If possible, it would be handy to have a patch as an attachment, or a
complete diff, or something I could apply?
Attached.
--
--gv
diff --git a/src/test/test_cmdline_args.py b/src/test/test_cmdline_args.py
index 55d1cdb..c8e68e8 100755
--- a/src/test/test_cmdline_args.p
Gisle Vanem wrote:
I only get 2 errors in that script. The others like:
self.assertTrue(out_verif.endswith("Configuration was valid\n"))
needs another patch which is beyond my Python knowledge.
I think it's fine now with this change:
@@ -57,14 +57,14 @@
raise Un
There are some problems with 'run_tor()' and line-endings.
It doesn't forsee any '\r\n' from 'Popen()' and since 'lines()'
only splits on '\n', most of the tests fails.
With this little patch:
@@ -64,7 +64,7 @@
yield fp[i:i+4]
def lines(s):
-out = s.split("\n")
+out = s.splitl
The 'U64_PRINTF_TYPE' is defined twice for MSVC.
An 'I64_PRINTF_TYPE' is needed too:
--- orig/src/test/test.h 2014-05-13 23:24:22 +
+++ src/test/test.h 2014-05-13 23:26:51 +
@@ -61,7 +61,7 @@
#ifdef _MSC_VER
#define U64_PRINTF_TYPE uint64_t
-#define U64_PRINTF_TYPE int64_t
+#define
-
I also tested 'test.exe --warn' without any TMP or TEMP. Thus my USERPROFILE is
used:
Jun 05 10:46:47.984 [warn] Could not open "f:\Documents and Settings\Gisle Vanem\tor_test_6368_s62ks2fe/xyzzy": No such file or
directory
Jun 05 10:46:47.984 [warn] Error reading private key
The test/test_status.c fails to compile using MSVC since
the statement:
log_global_min_severity_ = LOG_DEBUG;
Ref.
https://gitweb.torproject.org/tor.git/commit/3ce3984772b673b82a87aded1bc8a1a0f1969e19?f=src/test/test_status.c
This 'log_global_min_severity_' variable should not be only for GNU-
"Nick Mathewson" wrote:
I assume this test works on Linux where AFAICS malloc() returns a buffer
with zeros. If so, shouldn't calloc() be used in 'setup_data_buffer()'
instead?
The test is broken: it doesn't work on any platform. Look how buffer2
was copied directly from buffer1: they can't
The 'test_memcpy()' in tinytest_demo.c assumes
there is a NUL in one of the buffers. (the comment says so). That's
not the case here on Windows. At least not in MSVC debug-mode
where malloc'ed buffers are filled with '0xCD'. A snippet from my output:
../ext/tinytest_demo.c:159: assert(db->buff
Since tinytest_demo.c now calls Sleep(), we must include .
Patch:
--- Git-latest/src/ext/tinytest_demo.c 2014-03-13 20:44:56 +
+++ src/ext/tinytest_demo.c 2014-03-14 11:21:56 +
@@ -36,7 +36,10 @@
#include
#include
#include
-#ifndef _WIN32
+
+#ifdef _WIN32
+#include
+#else
#includ
Running "test --verbose util/logging/sigsafe_err" gives me an debug-assert in
write(STDERR_FILENO,...). Assert that failed is: "(_osfile(h) & FOPEN)"
Here's the call-stack in WinDbg:
MSVCR100D!_write+0x126
test!tor_log_err_sigsafe_write(char * s = 0x00707290 ".==
===
I've been building tor myself for 2 years now. In order to reduce the
number of warnings, I've added '-D_USE_32BIT_TIME_T' to my CFLAG.
This has worked fine until I updated and built OpenSSL 4 days ago.
It's 'ASN1_time_adj()' function and related 'OPENSSL_gmtime()' just
doesn't work when given a
There's an extra ';' in src/or/config.h that MSVC doesn't like so much.
Patch:
--- Git-latest\src\or\config.h 2013-05-28 07:32:46 +
+++ src\or\config.h 2013-05-28 07:39:42 +
@@ -109,7 +109,7 @@
char *transport_name; /* The name of the pluggable transport that
I suggest that the whole body of this file gets included
inside an "#ifdef CURVE25519_ENABLED" in-case someone
(like me!) inadvertently tries to compile it w/o this define
set. Patch:
--- Git-latest\src\or\onion_ntor.c Tue Feb 12 18:40:04 2013
+++ or\onion_ntor.c Tue Feb 12 23:46:51 2013
@@
"Nick Mathewson" wrote:
I'm happy to open another ticket for these, but have you tried using the
bugtracker yourself? Is there some UI issue or something that prevents you
from opening tickets?
I used the easy way-out; sent an email. It didn't occured at the time, there
was a bugtracker. Wil
These gcc extensions:
/*** EWMA circuitmux_policy_t method table ***/
circuitmux_policy_t ewma_policy = { .alloc_cmux_data = ewma_alloc_cmux_data,
.free_cmux_data = ewma_free_cmux_data,
Doesn't work well with MSVC. Here is a patch:
--- ..\..\Git-latest\src\or\circuitmux_ewma.c 2012-11-01 1
The code in tools\tor-fw-helper\tor-fw-helper-natpmp.c does
things wrong on Winsock where e.g. errno isn't set on
socket-errors and 'fd' is (always?) >= FD_SETSIZE.
Patch attached.
--gv
--- Git-latest\src\tools\tor-fw-helper\tor-fw-helper-natpmp.c 2012-11-01
18:05:12.246093500 +0100
+++
"Sebastian Hahn" wrote:
Tinytest is supposed to be an independent library, so including a
tor-specific header file doesn't work here.
Ok, I didn't know. But my patch to tinytest.c doesn't require any functions
from the Tor libs. (as test*.c does).
There are more MSVC-issues in other test/*.
There are 2 problems with the use of 'stricmp()' (line 295) in tinytest.c.
1. As it is now, I'm getting an undefined reference to 'stricmp' when
linking tinytest.exe and using '-nodefault:oldnames' in the link-flags.
Can we please remove this lib from the requirements?
2. 'stricmp()' is use
MSVC doesn't have . Hence this little patch is needed:
--- Git-latest\src\tools\tor-gencert.c Tue Jan 24 17:05:52 2012
+++ src\tools\tor-gencert.c Thu Apr 26 08:51:02 2012
@@ -9,7 +9,9 @@
#include
#include
#include
+#ifdef HAVE_UNISTD_H
#include
+#endif
#include
#include
The src/test/test_util.c doesn't compile with MSVC (CL ver. 16.00.30319.01).
It doesn't like the "#ifdef 0" construct, but the whole chunk should be
enabled with some modifications IMHO.
'path_is_relative()' doesn't handle the "http:\\dir" case though. Why should
it? Besides 'expand_filename()' i
"Nick Mathewson" wrote:
I'd say "not so good" if it only applies to MSVC builds.
I applies to all Win builds. Are you not getting any warnings
and errors when compiling aes.c?
Of course, if we patched the autoconf script so that it defined the
macro when building on windows with mingw, that
In common/aes.c:
#include "orconfig.h"
#include
...
#include
..
#include "compat.h"
By default is included in when
WIN32_LEAN_AND_MEAN is not defined. But this is defined too
late; in compat.h. So when in OpenSSL pulls in
and gets included in compat.h, I'm getting lots of warnings
and red
"Nick Mathewson" wrote:
It looks like you're using a version of openssl that isn't actually
released. (There is no openssl 1.1.0 yet; only a series of
not-yet-released development snapshots.)
True when you mention it. I have a "work-in-progress" from:
ftp://ftp.openssl.org/snapshot/openssl-S
Seems that this function isn't available in OpenSSL 1.1.0. On Windows
at least. The function is enclosed in a "#if 0" in OpenSSL's and
util/libeay.num also has this:
AES_ctr128_encrypt3216NOEXIST::FUNCTION:
So should we make an exception for Windows in common/aes.c:
--- Git-latest/sr
I just built Tor and the test suite with UNICODE enabled (MS Visual-C v16
on Win-XP SP3). With some patching, the test-programs compiled and ran
mostly fine. Except test_util_spawn_background_ok() failed for a reason I
did't understand initially:
test --warn
util/spawn_background_ok: Nov 23
Those '{}' constructs are not well liked by MSVC (cl v.16.xx).
An easy fix:
diff --git a/src/test/test_util.c b/src/test/test_util.c
index 2146299..64bf52e 100644
--- a/src/test/test_util.c
+++ b/src/test/test_util.c
@@ -1597,7 +1597,7 @@ test_util_join_win_cmdline(void *ptr)
{"a\\b", "de
"Nick Mathewson" wrote:
I can't merge this one because we're trying to minimize drift between
Libevent's evdns.c and Tor's eventdns.c. Once we (eventually) require
libevent 2.0, we can just throw out our own eventdns.c .
I cannot see that my use of set_socket_nonblocking() and network_init(
I've made eventdns.c + '-DEVDNS_MAIN' compile and work
under Windows / MSVC. Some simple patches:
* Use set_socket_nonblocking() instead of the F_SETFL hacks.
* Preserve the ret-val from evdns_config_windows_nameservers().
* In main(), call network_init() to call WSAStartup() etc.
* Removed 'evdn
The use of 'pid_t' confuses me a bit:
In common/procmon.c (inside MS_WINDOWS), it's typedef'ed to
'int' unconditionally.
And then in common/util.* (tor_terminate_process()) it is assumed to be
defined in orconfig.h or somewhere else. It's not AFAICS.
It is true that _getpid() returns an
lround() is missing in MS Visual-C's . Not available anywhere.
Here is an easy patch:
--- Git-latest\src\common\util.cSun Aug 14 13:48:49 2011
+++ src\common\util.c Tue Aug 23 21:15:25 2011
@@ -335,7 +335,11 @@
long
tor_lround(double d)
{
+#ifdef _MSC_VER
+ return (long)(d > 0 ? d + 0.
"Nick Mathewson" wrote:
On Sun, Jul 31, 2011 at 7:10 AM, Gisle Vanem wrote:
Hi list.
In or/networkstatus.c there is a "#if 0" block inside the macro
"SMARTLIST_FOREACH_JOIN". Not all compilers handle such contructs.
In the prosess of making solution/project
Hi list.
In or/networkstatus.c there is a "#if 0" block inside the macro
"SMARTLIST_FOREACH_JOIN". Not all compilers handle such contructs.
In the prosess of making solution/projects file for "MS Visual C++ 2010
Express",
I hit this problem (cl Version 16.00.30319.01). Can you please accept
"Nick Mathewson" wrote:
On Mon, Jun 20, 2011 at 6:32 PM, Gisle Vanem juswrote:
I think that the values for 'WIN32_WINNT' and '_WIN32_WINNT'
should be protected against redefinement.
Reason: In order for MingW to prototype getaddrinfo() and freeaddrinfo()
correct
I think that the values for 'WIN32_WINNT' and '_WIN32_WINNT'
should be protected against redefinement.
Reason: In order for MingW to prototype getaddrinfo() and freeaddrinfo()
correctly (in ), '_WIN32_WINNT' *must* be defined as 0x0501
or higher. or/or.h blindly defines them as 0x0400. So, buil
Hi list!
I've been staring at this file for some time trying to find the elusive
compile-error (MingW-gcc v4.50) on Win_XP). The bug was a missing
comma (!) and a typo ('err_msg' at line 277 changed to 'err_msg').
I've also changed the format for 'err_code' at line 293 into a "%ld" to suppress
"Nick Mathewson" wrote:
But hey, it's free software. If you wanted to write and maintain an
alternative set of build scripts to work with different versions of
mingw, that would be great.
I'm using the top of the line version of MingW (v3.18). I don't think
MingW has changed too much the las
I have a question regarding src/win32/orconfig.h. I guess this hand-
edited file is supposed to be used by MSVC (targeting Win32, WinCE and
whatnot). Or? What prevents it from being used by e.g. MingW in a non-
autoconf build?
If someone (like me that doesn't want to touch autotool with a ten-f
"Nick Mathewson" wrote:
Sounds fine to me. Alternatively, I believe we could just call
GetTempPath(): that's what it's there for.
Agreed. I first thought of using GetTempPath() but that involves another
buffer and checking the ret-val. It's safes though. From:
http://msdn.microsoft.com/en-
I don't think it's a good idea to use hard-coded paths. Even in a
test source-file. Easy patch:
--- Git-latest\src\test\test.c Wed Mar 30 11:58:28 2011
+++ src\test\test.c Thu Mar 31 14:06:14 2011
@@ -86,7 +86,7 @@
#ifdef MS_WINDOWS
//
tor_snprintf(temp_dir, sizeof(temp_dir),
-
53 matches
Mail list logo
