компилятор нодлиста

[Ivan Novikov]

Привет, All!

а вот как бороться с юниксовыми и виндовыми слэшами в путях?
самому-то голдеду в своих конфигах, похоже, уже давно всё равно.
по крайней мере, виндовый спокойно жрёт пути вида /fido/golded
а вот компилятор нодлистовый создаёт файл goldnode.gxl, где внутри
\fido\nodelist\nodelist.123
или
/fido/nodelist/nodelist.123
в зависимости от платформы. и на этот файл голдед уже реагирует плохо.
то есть начинает верещать про отсутствие нодлиста.

два разных нодлиста держать? скучно.


С приветом, Ivan.

[Max Vasilyev]

Hello Ivan!

02 Aug 16 20:28, you wrote to All:

IN> а вот как бороться с юниксовыми и виндовыми слэшами в путях?
IN> самому-то голдеду в своих конфигах, похоже, уже давно всё равно.
IN> по крайней мере, виндовый спокойно жрёт пути вида /fido/golded
IN> а вот компилятор нодлистовый создаёт файл goldnode.gxl, где внутри
IN> \fido\nodelist\nodelist.123
IN> или
IN> /fido/nodelist/nodelist.123
IN> в зависимости от платформы. и на этот файл голдед уже реагирует плохо.
IN> то есть начинает верещать про отсутствие нодлиста.
IN> два разных нодлиста держать? скучно.
Там давно все пути так обрабатываются:
strchg(nodelist[n].fn, GOLD_WRONG_SLASH_CHR, GOLD_SLASH_CHR);
И с твоим примером у меня все работает.
Ты уверен, что там путь одинаковый, что в винде, что в линуксе получается
именно от корня?
А если в golded.cfg написать как-то так (т.е. путь относительно деда):
NODEPATH ..\NODELIST\


WBR, Max.

[Ivan Novikov]

Привет, Max!

03 Aug 16, Max Vasilyev накропал письмо к Ivan Novikov:

IN>> а вот как бороться с юниксовыми и виндовыми слэшами в путях?
IN>> самому-то голдеду в своих конфигах, похоже, уже давно всё равно.
IN>> по крайней мере, виндовый спокойно жрёт пути вида /fido/golded
IN>> а вот компилятор нодлистовый создаёт файл goldnode.gxl, где внутри
IN>> \fido\nodelist\nodelist.123
IN>> или
IN>> /fido/nodelist/nodelist.123
IN>> в зависимости от платформы. и на этот файл голдед уже реагирует плохо.
IN>> то есть начинает верещать про отсутствие нодлиста.
IN>> два разных нодлиста держать? скучно.
MV> Там давно все пути так обрабатываются:
MV> strchg(nodelist[n].fn, GOLD_WRONG_SLASH_CHR, GOLD_SLASH_CHR);
MV> И с твоим примером у меня все работает.
вот сейчас взял версию поновее.
оно теперь не ругается, но продолжает писать белиберду вместо списка нод.

MV> Ты уверен, что там путь одинаковый, что в винде, что в линуксе
MV> получается именно от корня?
абсолютно.
на одной платформе компилируешь - ругается на другой. и наоборот.
собственно, прямо в .gxl файле только слэши направления меняют.

MV> А если в golded.cfg написать как-то так (т.е. путь относительно деда):
MV> NODEPATH ..\NODELIST\
не помогло.
зато новая версия теперь орёт в логи при попытке полистать список:
MSVC версия после этого тупо закрашилась

---------- Thu 04 Aug 16, GoldED+/W64-MSVC 1.1.5-b20160322 (Apr 4 2016
19:02:24)
! 20:59:13 Memory error at [genode.cpp,208].
! 20:59:13 gsprintf(buffer,261, %s / %s ,...): buffer overflow, result in next
line:
! 20:59:13 GOLDNODE.GXA /
яяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяя
яяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяя
яяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяяя
яяяяяяя

а MINGW версия продолжала работать, но ругаться подобным образом:

---------- Thu 04 Aug 16, GoldED+/W32-MINGW 1.1.5-b20160322 (Apr 4 2016
19:03:39)
! 21:00:44 Memory error at [genode.cpp,208].
! 21:00:44 gsprintf(buffer,261, %s / %s ,...): buffer overflow (need 143541
bytes).




С приветом, Ivan.

[Max Vasilyev]

Hello Ivan!

04 Aug 16 21:02, you wrote to me:

MV>> Ты уверен, что там путь одинаковый, что в винде, что в линуксе
MV>> получается именно от корня?
IN> абсолютно.
IN> на одной платформе компилируешь - ругается на другой. и наоборот.
IN> собственно, прямо в .gxl файле только слэши направления меняют.
а индексы побайтно одинаковые, которые виндовая и линуксовая версия создают?
у меня MSVC на слэши не ругается, а что в твоей самостоятельно компиленой
версии под линукс происходит - я хз

IN> ---------- Thu 04 Aug 16, GoldED+/W64-MSVC 1.1.5-b20160322 (Apr 4
IN> 2016 19:02:24) ! 20:59:13 Memory error at [genode.cpp,208]. !
IN> 20:59:13 gsprintf(buffer,261, %s / %s ,...): buffer overflow, result
IN> in next line: ! 20:59:13 GOLDNODE.GXA /
оно не в слэшах падает, а в индексах
в твоем компиляторе что-то не так с разрядностью, которую дед предполагает по
умолчанию

WBR, Max. piwamoto!писем-нет

[Ivan Novikov]

Привет, Max!

04 Aug 16, Max Vasilyev накропал письмо к Ivan Novikov:

MV>>> Ты уверен, что там путь одинаковый, что в винде, что в линуксе
MV>>> получается именно от корня?
IN>> абсолютно.
IN>> на одной платформе компилируешь - ругается на другой. и наоборот.
IN>> собственно, прямо в .gxl файле только слэши направления меняют.
MV> а индексы побайтно одинаковые, которые виндовая и линуксовая версия
MV> создают?
.gxa одинаковые, а .gxn разные (но юниксовый из пакаджей, версия старее -
v.1.1.5/BSD-b20110223)
виндовые версии генерят одинаковые

MV> у меня MSVC на слэши не ругается, а что в твоей самостоятельно
MV> компиленой версии под линукс происходит - я хз
а какой-нибудь дебаг режим включить возможно?
ключ -VV, похоже, только на конфиг и распространяется. по крайней мере в логи
ничего не падает. да и, собственно, оно ж не падает. видимо и за ошибку не
считается.

MV> оно не в слэшах падает, а в индексах
MV> в твоем компиляторе что-то не так с разрядностью, которую дед предполагает
MV> по умолчанию

попробовать собрать руками вместо пакаджей? :-\


С приветом, Ivan.

[Max Vasilyev]

Hello Ivan!

05 Aug 16 18:26, you wrote to me:

MV>> а индексы побайтно одинаковые, которые виндовая и линуксовая
MV>> версия создают?
IN> .gxa одинаковые, а .gxn разные
Вот тебе и ответ.

IN> (но юниксовый из пакаджей, версия
IN> старее - v.1.1.5/BSD-b20110223) виндовые версии генерят одинаковые
С тех пор ничего кардинально не менялось.

MV>> оно не в слэшах падает, а в индексах
MV>> в твоем компиляторе что-то не так с разрядностью, которую дед
MV>> предполагает по умолчанию
IN> попробовать собрать руками вместо пакаджей? :-\
Попробуй, но это ничего не даст с вероятностью 99%

Смотри чем gxn отличаются и проверяй задание типов для этих структур.
В husky был такой баг со статистикой.

WBR, Max. piwamoto!писем-нет

[Alexey Vissarionov]

Доброго времени суток, Ivan!
05 Aug 2016 20:37:10, Max Vasilyev -> Ivan Novikov:

MV>>> в твоем компиляторе что-то не так с разрядностью, которую дед
MV>>> предполагает по умолчанию
IN>> попробовать собрать руками вместо пакаджей? :-\
MV> Попробуй, но это ничего не даст с вероятностью 99%
MV> Смотри чем gxn отличаются и проверяй задание типов для этих структур.
MV> В husky был такой баг со статистикой.

И если получится, опубликуй в эхе diff


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii

... Знание некоторых принципов компенсирует незнание многих фактов

[Max Vasilyev]

Hello Alexey!

05 Aug 16 23:01, you wrote to Ivan Novikov:

AV> И если получится, опубликуй в эхе diff
Он сделал. Одобряешь/закоммитишь?

WBR, Max.

[Alexey Vissarionov]

Доброго времени суток, Max!
12 Aug 2016 07:31:46, ты -> мне:

AV>> И если получится, опубликуй в эхе diff
MV> Он сделал.

Ага, видел.

MV> Одобряешь/закоммитишь?

Надо бы... И, возможно, добавить #include <stdint.h>


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii

... Закон многое преследует, но не все догоняет

[Nickita A Startcev]

Привет, Alexey !


12 Aug 16 , 08:16 Alexey Vissarionov писал к Max Vasilyev:

AV>>> И если получится, опубликуй в эхе diff
MV>> Он сделал.

AV> Ага, видел.

MV>> Одобряешь/закоммитишь?

AV> Надо бы... И, возможно, добавить #include <stdint.h>

кстати, а как кошернее, stdint.h или inttypes.h ? и почему.

. С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
... И нижнее бельё на каблуках

[Ivan Novikov]

Привет, Max!

05 Aug 16, Max Vasilyev накропал письмо к Ivan Novikov:
IN>> .gxa одинаковые, а .gxn разные
MV>
MV>>> оно не в слэшах падает, а в индексах
да, кстати, что-то я не подумал прежде
вот сейчас тупо .gxl с другими слэшами подсунул - жрёт нормально.

MV>>> в твоем компиляторе что-то не так с разрядностью, которую дед
MV>>> предполагает по умолчанию
IN>> попробовать собрать руками вместо пакаджей? :-\
MV> Попробуй, но это ничего не даст с вероятностью 99%
так и вышло.
но, по крайней мере, делает одинаковые файлы с пакаджевой версией.

MV> Смотри чем gxn отличаются и проверяй задание типов для этих структур.
это я не умею, я не программер.
чисто глазуально записи отличаются длиной:
в никсовой версии между четвёртым и пятым байтом вставлено ещё четыре байта
нулей. остальное одинаково.

то есть, по моему тупому размышлению и созерцанию файла gftnnlge.h

=== rezat tuta ===
struct _GEIdx {
long pos; // File Number OR'ed with pos in nodelist file
ftn_addr addr; // Node address
char name[36]; // Name in reversed form
=== rezat tuta ===
засада с представлением типа long (мабуть из-за 64-битности?), поскольку
дальше идёт адрес и он правильный, я проверил по нодлисту.
что с этим делать дальше - я не знаю.
компилятор такой:
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.3
Thread model: posix
Selected GCC installation:



С приветом, Ivan.

[Ivan Novikov]

Привет, Max!

08 Aug 16 19:32, I wrote to you:

IN> то есть, по моему тупому размышлению и созерцанию файла gftnnlge.h
IN> засада с представлением типа long (мабуть из-за 64-битности?),

так оно и есть.
в 64-битной версии long имеет длину 8 бит.
вобщем, я его подебил, заменив long на uint32_t
вот дифф:


=== rezat tuta ===
-+- goldlib/gall/gftnnlge.h.orig 2007-02-07 23:37:52.000000000 +0500
+++ goldlib/gall/gftnnlge.h 2016-08-08 20:57:35.124806602 +0500
@@ -41,7 +41,7 @@
#endif

struct _GEIdx {
- long pos; // File Number OR'ed with pos in nodelist file
+ uint32_t pos; // File Number OR'ed with pos in nodelist file
ftn_addr addr; // Node address
char name[36]; // Name in reversed form
_GEIdx() : pos(0), addr() { *name = NUL; }
=== rezat tuta ===

С приветом, Ivan.