On 11 Mar 2021 at 07:04p, Michael Dukelsky pondered and said...

7 Mar:11:2021:16:26:15 Forwarding fire-34.zip with tic 1byzrpvz.tic for
21:1/213 via 21:1/213
double free or corruption (fasttop)
Aborted

Hopefully, I fixed it. Please pull and rebuild everything.

OK I am new to Linux but I went into my source files for the following directories and did a 'git pull' for each

hpt
htick
huskylib
fidoconf
areafix
huskybse
smapi
hptzip

I then ran 'make' and 'make install' in this order

huskylib
smapi
fidoconf
areafix
hptzip
hpt
htick

Testing htick I see the same error

7 Mar:13:2021:16:07:14 Forwarding
blocktronics-2021-valentines-day-cards.zip with tic 1bz3g66y.tic for 21:1/212 via 21:1/212
7 Mar:13:2021:16:07:14 Forwarding
blocktronics-2021-valentines-day-cards.zip with tic 1bz3g66z.tic for 21:1/213 via 21:1/213
double free or corruption (fasttop)
Aborted


But I did have a thought.... should I have copied the new huskymak.xx and edited it and placed that in the root huksy directory before I complied the
new versions?

I am now running versions

htick/lnx 1.9.0-cur 2021-03-11
hpt/lnx 1.9.0-cur 2021-03-11

--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

Hello Paul,

Saturday March 13 2021, Paul Hayton wrote to Michael Dukelsky:

7 Mar:11:2021:16:26:15 Forwarding fire-34.zip with tic

1byzrpvz.tic

for
21:1/213 via 21:1/213
double free or corruption (fasttop)
Aborted

Hopefully, I fixed it. Please pull and rebuild everything.

OK I am new to Linux but I went into my source files for the following directories and did a 'git pull' for each

hpt
htick
huskylib
fidoconf
areafix
huskybse
smapi
hptzip

I then ran 'make' and 'make install' in this order

huskylib
smapi
fidoconf
areafix
hptzip
hpt
htick

Testing htick I see the same error

7 Mar:13:2021:16:07:14 Forwarding blocktronics-2021-valentines-day-cards.zip with tic 1bz3g66y.tic for 21:1/212 via 21:1/212 7 Mar:13:2021:16:07:14
Forwarding blocktronics-2021-valentines-day-cards.zip with tic 1bz3g66z.tic for 21:1/213 via 21:1/213 double free or corruption
(fasttop) Aborted

But I did have a thought.... should I have copied the new huskymak.xx
and edited it and placed that in the root huksy directory before I complied the new versions?

Yes, of course. Did not you do it? If no, please rebuild and if the error persists please send me your FULL config without passwords to my email in tagline.

Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20180707
* Origin: Moscow, Russia (2:5020/1042)

On 2021-03-12 15:29:34, Michael Dukelsky (2:5020/1042) wrote to andrew clarke:

Here foo() can only set its local copy of p to NULL. It can't
modify the original pointer.

There's not really any way around this kind of mistake in C, other
than to run it through a debugger, examine the code and fix it by
hand.

We'll wait for Paul to test it.

Yes. Though I'm not satisfied with nfree() as it feels like it's masking bugs rather than fixing them at the origin. Just my 5c. :)

--- GoldED+/BSD 1.1.5-b20180707
* Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)

On 2021-03-12 15:30:48, Michael Dukelsky (2:5020/1042) wrote to Wilfred van Velzen:

#define nfree(a) {if(a != NULL) {free(a); a = NULL;}}

And the test for NULL isn't necessary, because free() is by
definition doing nothing if the pointer passed to it is NULL.

Yes, I know it. It was written long ago and not by me and I do not
change it because I do not know whether free() always worked as it works now or it did not test the pointer for NULL in some ancient systems.

Wilfred is right, though I'd prefer nfree() was not used rather than changing it.

Having a macro modify the variable passed to it just feels like bad code to me. But I will leave it.

Incidentally I think the "oldest" compiler still supported (properly) by HPT's build files is Open Watcom 2.0. The OW2.0 fork is an active project but its WCL386 compiler is still only C95 compliant, as evident from the internal __STDC_VERSION__ macro being set to 199409.

Though C95 is still newer than ISO/IEC 9899:1990, aka C89/C90.

--- GoldED+/BSD 1.1.5-b20180707
* Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)

Hello andrew,

Saturday March 13 2021, andrew clarke wrote to Michael Dukelsky:

Here foo() can only set its local copy of p to NULL. It can't
modify the original pointer.

There's not really any way around this kind of mistake in C,
other than to run it through a debugger, examine the code and
fix it by hand.

We'll wait for Paul to test it.

Yes. Though I'm not satisfied with nfree() as it feels like it's
masking bugs rather than fixing them at the origin. Just my 5c. :)

No problem. If you want to do it better, just do it. :)

Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20180707
* Origin: Moscow, Russia (2:5020/1042)

Hello andrew,

Saturday March 13 2021, andrew clarke wrote to Michael Dukelsky:

#define nfree(a) {if(a != NULL) {free(a); a = NULL;}}

And the test for NULL isn't necessary, because free() is by
definition doing nothing if the pointer passed to it is NULL.

Yes, I know it. It was written long ago and not by me and I do
not change it because I do not know whether free() always worked
as it works now or it did not test the pointer for NULL in some
ancient systems.

Wilfred is right, though I'd prefer nfree() was not used rather than changing it.

Having a macro modify the variable passed to it just feels like bad
code to me.

There's a lot of bad code here.

But I will leave it.

So be it.

Incidentally I think the "oldest" compiler still supported (properly)
by HPT's build files is Open Watcom 2.0. The OW2.0 fork is an active project but its WCL386 compiler is still only C95 compliant, as
evident from the internal __STDC_VERSION__ macro being set to 199409.

Though C95 is still newer than ISO/IEC 9899:1990, aka C89/C90.

Some persons emerge from time to time who want to build the sources for DOS. Or maybe that was in BINKD echo...

Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20180707
* Origin: Moscow, Russia (2:5020/1042)

On 2021-03-13 12:55:08, Michael Dukelsky (2:5020/1042) wrote to andrew clarke:

Yes. Though I'm not satisfied with nfree() as it feels like it's
masking bugs rather than fixing them at the origin. Just my 5c. :)

No problem. If you want to do it better, just do it. :)

Maybe. :)

For now, there are some more important bugs I want to focus on.

--- GoldED+/BSD 1.1.5-b20180707
* Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)

On 2021-03-13 13:11:58, Michael Dukelsky (2:5020/1042) wrote to andrew clarke:

Having a macro modify the variable passed to it just feels like bad
code to me.

There's a lot of bad code here.

Yes.

Though somehow HPT works (mostly!) despite it all, so I don't like to be too harsh on any of the contributors.

None of the code I wrote 20 years ago is very good, in hindsight.

We are only human. :)

Incidentally I think the "oldest" compiler still supported
(properly) by HPT's build files is Open Watcom 2.0. The OW2.0 fork
is an active project but its WCL386 compiler is still only C95
compliant, as evident from the internal __STDC_VERSION__ macro
being set to 199409.

Though C95 is still newer than ISO/IEC 9899:1990, aka C89/C90.

Some persons emerge from time to time who want to build the sources for DOS. Or maybe that was in BINKD echo...

Building for 32-bit DOS (DOS4GW) shouldn't be too difficult with OW2.0 now that the OW2.0 NT & OS/2 ports are building well. I've thought about a DOS4GW port but I'm not sure anyone would use it. At some point I may give it a try for a bit of fun and see how far I get, but I'd prefer to focus on fixing bugs and adding features.

Also it might already be possible to run the Win32 version of HPT under DOS using the HX DOS-Extender. HX is similar to PharLap/286 (one of the first DOS extenders) which provided emulation for a subset of 16-bit OS/2 functions. This allowed you to run a lot of text mode 16-bit OS/2 apps under regular DOS. HX does basically the same, but for a subset of Win32 programs (mostly text apps) on 386+ machines.

A 16-bit DOS port of HPT is theoretically possible but unrealistic, mostly due to the size of HPT and the DOS 640K limit, and even fewer people would use it compared to a potential DOS4GW version.

A 16-bit OS/2 port is also theoretically possible but would not be useful to anyone, except as a coding challenge.

--- GoldED+/BSD 1.1.5-b20180707
* Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)

On 13 Mar 2021 at 11:09a, Michael Dukelsky pondered and said...

But I did have a thought.... should I have copied the new huskymak.xx and edited it and placed that in the root huksy directory before I complied the new versions?

Yes, of course. Did not you do it? If no, please rebuild and if the
error persists please send me your FULL config without passwords to my email in tagline.

No I did not. I am new to this software. I was under the impression once the huskymak.cfg was set up I didn't need to update that again each time?

I did copy the new one over, update it (it was no different to my first one) then rebuilt and still hit the same problem

7 Mar:14:2021:10:13:11 Forwarding blocktronics-2021-calendar.zip with tic 1bz4ug3y.tic for 21:1/212 via 21:1/212
7 Mar:14:2021:10:13:11 Forwarding blocktronics-2021-calendar.zip with tic 1bz4ug3z.tic for 21:1/213 via 21:1/213
double free or corruption (fasttop)
Aborted

So you want all my config files? Areas, config, links, route... is that correct?

Best, Paul

--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

Hello Paul,

Sunday March 14 2021, Paul Hayton wrote to Michael Dukelsky:

So you want all my config files? Areas, config, links, route... is
that correct?

Exactly.

Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20180707
* Origin: Moscow, Russia (2:5020/1042)

On 14 Mar 2021 at 03:16p, Michael Dukelsky pondered and said...

Exactly.

OK

--- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)