Assigning them to NULL coredumps as fp->last gets dereferenced in name.c (line
1192).
Directions on cloning and checking out the branch:
git clone --recurse-submodules
git checkout --recurse-submodules ksh93-master-upgrade
Building should still be straightforward, make World, however, if you want to
manually clean, a bug in how the Imakefiles would generate dependencies means
that you need to manually run ./programs/dtksh/bin/package clean and then make
clean
Alternatively, we could fork, but I think this should be a last resort if
upstream dies. This could also be advantageous to us if we wanted to convert
ksh93 to automake, but in a list of things I want to do in my life, that task
ranks extremely low.
As for testing on alternative platforms, I really have no expertise with
anything other than linux, maybe others would be willing to test on their
machines, but I understand asking for work is a no-no.
Thank you for your time,
-Chase
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, October 19, 2020 7:45 PM, Jon Trulson <j...@radscan.com> wrote:
> On 10/18/20 11:58 AM, Chase via cdesktopenv-devel wrote:
>
> Hi,
>
>> So, the first patch removes a lot of our custom localization changes, as
>> between 1993 and 2012 kornshell figured out how to do i18n properly,
>> normally I'd like to keep ksh93 functions out of dtksh, but this allows us
>> to skip a lot of the custom code we needed to add to init.
>>
>> The second patch just brings us up to date with ksh93.
>>
>> The thirst patch finally fixes the callback segfaults for good, how it works
>> however, is a mystery to me.
>
> This one concerns me - what you did was assign "" to a pointer. Yes, this
> does ensure the pointer is valid, though it will point into the BSS. If
> something is scribbling in there, it will corrupt things there.
>
> Did you try just assigning these to NULL?
>
> I've gone ahead and applied these to the master-ksh93-upgrade branch. But
> please, check those assignments - they are suspicious.
>
>> We should now be able to merge the ksh93 branch into master unless there are
>> any further objections.
>
> Hmm, no... A few things need to happen first, I think:
>
> - We need instructions on how to check it out and build it (I still haven't
> attempted it yet). Now that we are using a sub module, those instructions
> will change. These would need to go into the documentation/wiki so people can
> build it for example.
> - this would need to be tested/built on multiple systems - different linuxen
> and at least one of the BSDs, like FreeBSD.
> - would also need to run through the examples and things on these other
> systems to make sure stuff works the way it is supposed to.
>
> It needs to work at least as well as the current version does, and we've
> built that version on a lot of different systems.
>
> I would think we'd need to do these at a minimum. You have done some
> fantastic work here though - it is just not ready to be dumped into master
> yet without more testing, especially building on more platforms.
>
> -jon
>
>> Thank you for your time,
>> -Chase
>>
>> _______________________________________________
>> cdesktopenv-devel mailing list
>> cdesktopenv-devel@lists.sourceforge.net
>>
>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
>
> --
> Jon Trulson
>
> "Entropy. It isn't what it used to be."
> -- Sheldon
_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
