aboutsummaryrefslogtreecommitdiffhomepage
path: root/src
AgeCommit message (Collapse)AuthorFilesLines
2022-11-28fixed a number of crashes due to empty string arguments or uninitialized ↵Robin Haberkorn9-5/+18
registers * An empty but valid teco_string_t can contain NULL pointers. More precisely, a state's done_cb() can be invoked with such empty strings in case of empty string arguments. Also a registers get_string() can return the NULL pointer for existing registers with uninitialized string parts. * In all of these cases, the language should treat "uninitialized" strings exactly like empty strings. * Not doing so, resulted in a number of vulnerabilities. * EN$$ crashed if "_" was uninitialized * The ^E@q and ^ENq string building constructs would crash for existing but uninitialized registers q. * ?$ would crash * ESSETILEXER$$ would crash * This is now fixed. Test cases have been added. * I cannot guarantee that I have found all such cases. Generally, it might be wise to change our definitions and make sure that every teco_string_t must have an associated heap object to be valid. All functions returning pointer+length pairs should consequently also never return NULL pointers.
2022-11-20bumped required PDCursesMod version to v4.3.4 or laterRobin Haberkorn1-16/+0
* allows us to get rid of some workarounds * the workarounds themselves required relatively recent PDCursesMod versions, so we can just as well bump the version yet another time. We are probably the only ones building it (via Github actions) anyway. * With v4.3.4 you should be able to link dynamically, but we are still linking statically for nightly builds to keep binary sizes small. Unfortunately, the glib builds shipping with MinGW still have dynamically linked helper executables.
2022-11-20fixed teco_qreg_table_set_environ() on Win32: sometimes keys unexpectedly ↵Robin Haberkorn1-1/+13
begin with an equals character * Has been observed on Windows Server 2008 with Glib 2.74.1-1, but not on the Github CI runner.
2022-11-20teco_qreg_table_set_environ() will now use g_get_environ() instead of ↵Robin Haberkorn1-9/+5
g_listenv() * This is assumed to fix current Windows CI build problems caused by g_getenv() returning NULL for keys contained in g_listenv(), which is probably a new Glib bug. * Using g_get_environ() is more efficient since we do not have to repeatedly search through the environment array with g_getenv(). * Windows 2000 - which supposedly relied on the old code because of its own bugs - is no longer supported by our minimum Glib version anyway.
2022-06-22PDCursesMod/WinGUI now uses the polling fallback again with a temporary ↵Robin Haberkorn1-76/+14
workaround * The keyboard hook required polling as well and was actually much less performant than the generic getch() polling fallback. Furthemore it did at least not work on Wine. * We instead now release the WinGUI-internal mutex and yield the thread giving it some time to process new key presses. * This workaround is temporary and will probably be part of the the next PDCursesMod-release (v4.3.4). We still want to support the latest MSYS/MinGW version though which is currently at v4.3.2. The fix will also currently only work when statically linking in libpdcurses_wingui.a. This is what we do for nightly builds. See also https://github.com/Bill-Gray/PDCursesMod/issues/197 * Once the fix is released upstream and into MSYS, we should probably bump our minimal required PDCursesMod version. The color-table workaround (cf9ffc0cec0d2e55930238d1752209bca659c96d) can then also be removed. * We should also consider dropping official support for the classic PDCurses and support only PDCursesMod - this will allow us to simplify interfaces-curses/interface.c a bit. Support for classic PDCurses is probably broken by now anyway and trying to support it is just too much.
2022-06-21updated copyright to 2022 and updated TODORobin Haberkorn61-61/+61
2022-06-21avoid unnecessary creation of undo tokensRobin Haberkorn2-5/+8
2022-06-21fixed rubout of certain constructs like Ifoo$FRX$$Robin Haberkorn3-4/+17
* avoid emitting SCI_UNDO undo tokens if the Scintilla undo action would actually be empty
2022-06-21better support recent versions of PDCursesMod (used to be the Win32a-port)Robin Haberkorn1-1/+2
* PDCursesMod is now the recommended PDCurses variant * you should use at least v4.3.2 since earlier versions have problems inserting CTRL+C and CTRL+V. * We now check for PDC_get_version() since initscr() was name-mangled at least for some time. The maintainers have now reverted to name-mangling endwin(), we still check for PDC_get_version() as it is probably safer in the future. * Properly define PDC_FORCE_UTF8 now. * We no longer have to check for PDC_set_resize_limits() since PDCursesMod now defines its own macro __PDCURSESMOD__ in curses.h.
2022-06-21PDCursesMod: fixed the light black color on all GUI backends (e.g. WinGUI)Robin Haberkorn1-0/+4
* This is already fixed upstream, but we still include the workaround, so we can build with the current MSYS package and during CI.
2022-06-21PDCurses: fixed CTRL+C interruptions on WinCON and WinGUIRobin Haberkorn1-28/+87
* Due to regressions, the Control handler needs to be installed later (PDCursesMod installs its own control handler). * We no longer have to manually set the control mode - at least on PDCursesMod/WinCON. It's not worth keeping the workaround for the original PDCurses. * For WinGUI neither the control handler, nor the polling-fallback will work, therefore we introduced yet another version based on keyboard hooks. See https://github.com/Bill-Gray/PDCursesMod/issues/197 This version may even become the default on all Win32-ports but I need to think this through more thorougly.
2022-06-21Gtk+: fixed interpretation of Alt-Gr-keypressesRobin Haberkorn1-1/+6
* this is a regression in Gtk+ 3 * nowadays, Alt-Gr-keycombos are sometimes reported as Ctrl+Alt which resulted in control characters to be inserted
2022-06-21Gtk+: Stop memory limiting when idlingRobin Haberkorn1-0/+8
* the same is done in the Curses UI * important for platforms that require busy polling of memory usage (Win32)
2022-01-15fixup: use a dedicated input queue data structures (teco_interface.input_queue)Robin Haberkorn1-22/+35
* Using ungetch() was of course broken and could easily result in hangs as wgetch() would never return ERR. * This wastes some bytes on platforms that do not need the teco_interface_is_interrupted() fallback. * introduced teco_interface_blocking_getch() * FIXME: This is still way too slow on PDCurses/GUI on Windows but this can potentially be fixed upstream.
2021-12-22Curses: added teco_interface_is_interrupted() fallback and standardized how ↵Robin Haberkorn2-10/+58
to detect interactive/batch mode * Adds support for CTRL+C interruptions on Curses variants like PDCurses/GUI and XCurses. This also affects the current Win32 nightly builds which should now support CTRL+C interruptions. * The fallback is of course less efficient than the existing platform optimizations (existing for UNIX and Win32 console builds) and slows down parsing in interactive mode. * Use teco_interface.cmdline_window consistently to detect interactive mode. This may theoretically speed up SciTECO code execution slightly on shutdown.
2021-12-19safer use of memcpy() and memchr(): we must not pass in NULL pointersRobin Haberkorn5-6/+19
* The C standard actually forbids this (undefined behaviour) even though it seems intuitive that something like `memcpy(foo, NULL, 0)` does no harm. * It turned out, there were actual real bugs related to this. If memchr() was called with a variable that can be NULL, the compiler could assume that the variable is actually always non-NULL (since glibc declares memchr() with nonnull), consequently eliminating checks for NULL afterwards. The same could theoretically happen with memcpy(). This manifested itself in the empty search crashing when building with -O3. Test case: sciteco -e '@S//' * Consequently, the nightly builds (at least for Ubuntu) also had this bug. * In some cases, the passed in pointers are passed down from the caller but should not be NULL, so I added runtime assertions to guard against it.
2021-10-24removed -rdynamic linker flag: should speed up release/nightly builds and ↵Robin Haberkorn1-6/+0
decrease the binary size significantly * -rdynamic was added to make sure that malloc replacement functions were exported and visible to shared libraries. It was more or less currently only used on Linux and Haiku as Win32 and Mac OS do not override malloc. * The option however exported all symbols which would prevent them to be removed at link-time. Other optimizations could also be affected, perhaps resulting in less inlining. * On Haiku, -rdynamic is not supported and cause build failures. * It has been tested (nm -D ./sciteco | grep ' T ') that malloc() and friends are exported even when linking with -O3. Even the __attribute__((used)) has been shown to be superfluous, but we keep it anyway just to be sure.
2021-10-24added Mac OS nightly builds (#8)Robin Haberkorn1-4/+3
* Only x86_64 builds are supported for the time being. They have been tested on Mac OS 10.15 (Darling) and 11 (thanks to @dertuxmalwieder). * Curses glitches remain on Mac OS as reported by @dertuxmalwieder. Under Darling with a Linux terminal emulator, everything looks as it should. * We don't build AppBundles or pkg installers but instead came up with a rather ideosyncratic way of packaging: The packages are tarballs of the installation tree with all dependant libraries added under /usr/local/lib/sciteco - thanks to dylibbundler. The archives are supposed to be unpacked into the UNIX tree root (`tar -C / -xf sciteco.tar`) and it will be necessary to "de-quarantine" all the binaries. Details will be documented in the wiki: https://github.com/rhaberkorn/sciteco/wiki/Mac-OS-Support * Perhaps we will also ship an installation script (TODO). * AppBundles would have the disadvantage that they cannot be directly installed into $PATH. On the other hand, this would be relatively easy to do afterwards. An AppBundle would need certain code adaptions for Mac OS, though. * Gtk+ builds are not yet supported as I cannot test them with "Darling". * All Nightly Build artifact names now mention the target architecture. * build Win32 nightly builds with windows-2019 * May improve compatibility slightly in the future as we should always build our binaries on the oldest possible system. * Does not change anything currently since windows-2019 == windows-latest. * CI still uses windows-latest and may therefore one day switch to windows-2022. * updated README
2021-10-24fixed <U> command: -Uq is equivalent to -1Uq again.Robin Haberkorn1-1/+1
* This has been broken since the C conversion (432ad24e382681f1c13b07e8486e91063dd96e2e). * Fixes getopt.tes, although no script actually checked the contents of the getopt.X numeric Q-Registers. grosciteco.tes also made use of this. It's unclear what has consequently been broken. * NOTE: TECOC does not seem to support -Uq - this is a SciTECO extension.
2021-10-15Gtk: disabled ^Z suspension on Unix for the time beingRobin Haberkorn2-13/+3
* This has always been broken as Gtk will not hide the window before suspending. * It has been deemed to complicated to implement at the moment. Even if we can catch SIGTSTP (not that trivial), it seems to be impossible - at least without some lower level Xlib interaction - to hide the program window before raising SIGTSTP. * Even if everything worked, it is unclear whether it is actually desirable to suspend a GUI application - ^Z may be pressed accidentally and it will be inconvenient to resume the job. So we would additionally have to check for the existence of an attached console.
2021-10-15Gtk: solve the key-repeat problem once and for all (or improved on it at least)Robin Haberkorn1-1/+2
* Keeping a key pressed could still result in missing graphics updates and thus visual feedback. * Now try to process all Gdk events after thawing the window. It no longer appears to happen. * On the downside, key processing is much slower now which may result in keys being queued up and processed some time even after releasing it. There may be workarounds for that as well...
2021-10-15Gtk: prevent hard to predict teco_interface_key_pressed_cb() recursionsRobin Haberkorn1-1/+5
* Due to introducing another gtk_main_iteration_do(), there could indeed be unforseen recursions of teco_interface_key_pressed_cb() that resulted in additional teco_interface_handle_key_press() calls. * This did not cause crashes, but we better prevent recursions altogether. While emptying the key event queue, we only allow other events to be queued by all possibly recursive invocations of teco_interface_key_pressed_cb().
2021-10-13GTK: Support for Xembed protocol via --xembedRobin Haberkorn1-1/+18
* This was surprisingly easy to implement as Gtk+ 3 already supports it via GtkPlug. * Allows embedding SciTECO into other Xembed-aware applications. * Unfortunately there are very few generic Xembed hosts. tabbed (https://tools.suckless.org/tabbed/) would be one of them. It could be used to add tabs to SciTECO even on non-tiling window managers: $ tabbed sciteco --xembed * Unfortunately, it does not seem to be possible to use this feature to let SciTECO replace the contents of a terminal window even though many terminal emulators provide $WINDOWID.
2021-10-13GTK: revised the key processing again to prevent crashesRobin Haberkorn1-41/+35
* Processing a queued list of key events with an idle timer turned out to be tricky. Since teco_interface_pop_key_idle_cb() would eventually drive the main loop with gtk_main_iteration_do() which may result in a recursive invocation of teco_interface_pop_key_idle_cb() which will eventually crash. * We'd have to mask the idle watcher during the execution time of teco_interface_pop_key_idle_cb(). * Therefore it has been decided to use a tight loop again to process the event queue. After thawing the window, we now manually drive the event loop with gtk_main_iteration_do() to make sure that the UI is updated. This could result in a recursive invocation of teco_interface_key_pressed_cb() of course but the callback is already secured against this.
2021-10-13improved default selection colors and made them configurable via color.tesRobin Haberkorn3-2/+9
* NOTE: Selections are currently only used to highlight search results. * The default selection colors were not always visible well with default settings (--no-profile) and they were not uniform across platforms. On Curses, the selection would be reversed, while on Gtk it had a lighter foreground color. They are now always reversed (black on white background). The default styles do not assume any color support - they use only black and white. * Since these defaults cannot possibly work on every color scheme, color.selfore and color.selback has been added to color.tes. All existing color schemes have been updated to configure selections as reversed to the default colors. This especially fixes selection colors on Gtk. * On solarized.tes, the caret style was already distinct from inversed default colors. On terminal.tes, the color of the caret is now bright white, so it stands out from the selection colors. * In Curses, the caret color is currently __not__ applied to the command line where it is continued to be drawn reversed. The command line drawing code is considered deprecated and will eventually be replaced with a Scintilla minibuffer. * In Gtk, we now apply the caret style to the commandline view as well. * Fixed the comment color in solarized.light.
2021-10-13GTK: fixed teco_view_free() (hopefully)Robin Haberkorn1-20/+7
* The old implementation could apparently result in use-after-free situations that are not related to unstopped watchers in Scintilla. This would result in frequent crashes. Possibly, this only now manifests after upgrading to Scintilla 5. * The old implementation also had the bug that freeing views (e.g. via <EF>) would not release any memory in batch mode since the main loop is not triggered. * I don't pretend to understand why we need gtk_widget_destroy() instead of g_object_unref().
2021-10-13GTK: prevent crashes when pressing keys very quicklyRobin Haberkorn1-1/+2
* teco_interface_key_pressed_cb() could be called multiple times __before__ the idle timer (teco_interface_pop_key_idle_cb()) fires. The recursion check would consequently not work and we started the idle timer multiple times. This would eventually crash. * We now process the first queued key immediately. The alternative would be to store the idle watcher id. * The idle watcher's priority has been increased. Since redrawing is guaranteed to take place at G_PRIORITY_HIGH_IDLE, it is sufficient to process keys at G_PRIORITY_DEFAULT_IDLE. * Should also reduce latency slightly. * fixes up 71bf522231d2998f1fb183f343c2b1f9dbcd3b15
2021-10-11fixed crashes when the Q-Reg stack is non-empty at exitRobin Haberkorn3-3/+3
* Test case: sciteco -e '[a' [aEX$$ in interactive mode would also crash. * No longer use a destructor - it was executed after the Q-Reg view was destroyed. * Instead, we now explicitly call teco_qreg_stack_clear() in main(). * Added a regression test case.
2021-10-11Gtk+ 3 UI: Don't use deprecated functions and make sure that the UI is ↵Robin Haberkorn1-37/+38
updated regularily when holding down a key * gdk_window_freeze_toplevel_updates_libgtk_only() is apparently no longer necessary with Scintilla 5. * When holding down a key constantly, it was not uncommon that the display would not be updated until it is released. This is now worked around by using a low priority idle timer for emptying the teco_interface.event_queue. This ensures that Gtk can call other watchers after every keypress.
2021-10-11optimized caret scrolling: this is a costly operation and is now done only ↵Robin Haberkorn9-35/+54
once per keypress * Esp. costly since Scintilla 5. * We now avoid any Scintilla message that automatically scrolls the caret (makes the caret visible) and instead call SCI_SCROLLCARET only once after every keypress in the interface implementation. * From nowon, use * SCI_SETEMPTYSELECTION instead of SCI_GOTOPOS * SCI_SETEMPTYSELECTION(SCI_POSITIONFROMLINE(...)) instead of SCI_GOTOLINE * SCI_SETSELECTIONSTART and SCI_SETSELECTIONEND instead of SCI_SETSEL * With these optimizations we are significantly faster than before the Scintilla upgrade (6e67f5a682ff46d69888fec61b94bf45cec46721). It is now even safe to execute the Gtk test suite during CI.
2021-10-11optimized character representation settingRobin Haberkorn5-33/+15
* Esp. with the new Scintilla version, the representation setting as part of every SCI_SETDOCPOINTER has turned out to be a performance bottleneck. * The new Scintilla has a custom tweak/patch that disables any automatic representation setting in Scintilla itself. It is now sufficient to initialize the SciTECO-style representations only once in the lifetime of any view.
2021-10-11upgraded to Scintilla 5.1.3 and Scinterm 3.1Robin Haberkorn9-60/+68
* Previous Scintilla version was 3.6.4 and Scinterm was 1.7 (with lots of custom patches). All of the patches are now either irrelevant or have been merged upstream. * Since Scintilla 5 requires C++17, this increases the minimum GCC version at least to 5.0. We may actually require even newer versions. * I could not upgrade the scintilla-mirror (which was imported from Mercurial), so the old sciteco-dev branch was renamed to sciteco-dev-pre-v2.0.0, master was deleted and I reimported the entire Scintilla repo using git-remote-hg. This means that scintilla-mirror now contains two entirely separate trees. But it is still possible to clone old SciTECO repos. * The strategy/workflow of maintaining hotfix branches on scintilla-mirror has been changed. Instead of having one sciteco-dev branch that is rebased onto new Scintilla upstream releases and tagging SciTECO releases in scintilla-mirror (to keep the commits referenced), we now create a branch for every Scintilla version we are based on (eg. sciteco-rel-5-1-3). This branch is never rebased or deleted. Therefore, we are guaranteed to be able to clone arbitrary SciTECO repo commits - not only releases. Releases no longer have to be tagged in scintilla-mirror. On the downside, fixup commits may accumulate in these new branches. They can only be squashed once a new branch for a new Scintilla release is created (e.g. by cherry-picking followed by rebase). * Scinterm does no longer have to reside in the Scintilla subdirectory, so we added it as a regular submodule. There are no more recursive submodules. The Scinterm build system has not been improved at all, but we use a trick based on VPATH to build Scinterm in scintilla/bin/. * Scinterm is now in Git and we reference the upstream repo for the time being. We might mirror it and apply the same branching workflow as with Scintilla if necessary. The scinterm-mirror repository still exists but has not been touched. We will also have to rewrite its master branch as it was a non-reproducible Mercurial import. * Scinterm now also comes with patches for Scintilla which we simply applied on our sciteco-rel-5-1-3 branch. * Scintilla 5 outsourced its lexers into the Lexilla project. We added it as yet another submodule. * All submodules have been moved into contrib/. * The Scintilla API for setting lexers has consequently changed. We now have to call SCI_SETILEXER(0, CreateLexer(name)). As I did not want to introduce a separate command for setting lexers, <ES> has been extended to allow setting lexers by name with the SCI_SETILEXER message which effectively replaces SCI_SETLEXERLANGUAGE. * The lexer macros (SCLEX_...) no longer serve any purpose - they weren't used in the SciTECO standard library anyway - and have consequently been removed from symbols-scilexer.c. The style macros from SciLexer.h (SCE_...) are theoretically still useful - even though they are not used by our current color schemes - and have therefore been retained. They can be specified as wParam in <ES>. * <ES> no longer allows symbolic constants for lParam. This never made any sense since all supported symbols were always wParam. * Scinterm supports new native cursor modes. They are not used for the time being and the previous CARETSTYLE_BLOCK_AFTER caret style is configured by default. It makes no sense to enable native cursor modes now since the command line should have a native cursor but is not yet a Scintilla view. * The Scintilla upgrade performed much worse than before, so some optimizations will be necessary.
2021-10-08prevent deprecation warnings in Glib >= v2.70Robin Haberkorn1-3/+14
2021-10-08Gtk: fixed message bar's background colorRobin Haberkorn1-7/+7
* Was only broken on Gtk+ 3.24 for Windows with the builtin theme engine. * The warning level was also not themed correctly because of a typo.
2021-10-08fixed hiding savepoint files on Win32Robin Haberkorn1-1/+2
* This was an ancient bug apparently broken since d503c3b07c2157658f699294c44ad5be244727a5 (year 2014) and was therefore broken even in v0.6.4.
2021-10-08revised icon loading on Windows and packaging againRobin Haberkorn1-19/+28
* We don't need the PNG icons on Windows as the compiled-in ICO should suffice * Ship the dependencies of the SVG pixbuf loader. * The PNG pixbuf loader is still distributed, as we at least need it for loading the icon theme. * Install a loaders.cache - without it, the pixbuf loaders won't be found. This file can be generated by gdk-pixbuf-query-loaders but apparently has to be modified by hand. * Regenerate the icon cache using gtk-update-icon-cache. * Icon themes are found now. Unfortunately, we have to distribute the entire Adwaita icon theme as distributing only the scalable (SVG) icons does not work for some strange reason (FIXME).
2021-06-08Gtk UI: fixed lookup of icons and fallback.css on WindowsRobin Haberkorn1-33/+39
* Since we don't have an absolute and known installation directory, we should look for these files in the same directory as sciteco.exe. * For the time being, we look for them in $SCITECOCONFIG which defaults to that directory. * Cannot be a final solution as you may tweak $SCITECOCONFIG to fit an Unix-like environment (eg. set SCITECOCONFIG=$HOME). In such configurations it may also not be suitable to always look in the directory of sciteco.exe since that may be some /bin dir. Considering that GTK+ forces us to preserve some kind of UNIX-like directory hierarchy even for portable builds, we should perhaps install the icons into the hicolor icon theme. This would also simplify Debian packaging.
2021-06-08improved PDCurses detectionRobin Haberkorn1-61/+22
* follow the current terminology: * PDCurses/Win32a is now called PDCursesMod and includes all other PDCurses ports as well. The Win32 GUI port is now called PDCurses/WinGUI. * PDCurses/Win32 is now called PDCurses/WinCon. * Since PDCursesMod supports WinCon as well, we use the PDCURSES_MOD macro only to detect PDCursesMod API extensions. GUIs (detached from system console) might be available both in classic PDCurses as well as in PDCursesMod. Only PDCursesMod allows detection of the port used *at runtime* using PDC_get_version(). We therefore introduced a --with-interface=pdcurses-gui that must be given whenever compiling for any kind of GUI port (including SDL on "classic" PDCurses). * The PDCURSES macro is used to detect all PDCurses (whether classic or PDCursesMod) API extensions. * __PDCURSES__ is used to detect PDCurses whenever API extensions are not required. * Assume that A_UNDERLINE now works even on WinCon.
2021-06-08all SciTECO scripts used during the build process now always write files ↵Robin Haberkorn1-1/+1
with Unix linebreaks * when hosted on Windows, the default is DOS linebreaks * Unix linebreaks are in many cases more consistent as all other sources use Unix linebreaks * woman pages with Unix linebreaks are slightly faster to load due to EOL conversion * especially Groff input must not contain CR as it will otherwise log lots of warnings (affects htbl.tes and tedoc.tes).
2021-06-08get rid of the GObject Builder (GOB2): converted teco-gtk-info-popup.gob and ↵Robin Haberkorn9-716/+813
teco-gtk-label.gob to plain C * Using modern GObject idioms and macros greatly reduces the necessary boilerplate code. * The plain C versions of our GObject classes are now "final" (cannot be derived) This means we can hide the instance structures from the headers and avoid using explicit private fields. * Avoids some deprecation warnings when building the Gtk UI. * GOB2 is apparently no longer maintained, so this seems like a good idea in the long run. * The most important reason however is that there is no precompiled GOB2 for Windows which prevents compilation on native Windows hosts, eg. during nightly builds. This is even more important as Gtk+3 is distributed on Windows practically exclusively via MSYS. (ArchLinux contains MinGW gtk3 packages as well, so cross-compiling from ArchLinux would have been an alternative.)
2021-06-08try G_SPAWN_LEAVE_DESCRIPTORS_OPEN when spawning processes: promises an ↵Robin Haberkorn1-1/+6
"optimized" code-path on UNIX
2021-06-08added test suite cases for memory limiting and command executionRobin Haberkorn1-0/+5
* Turned out to be useful in debugging the "Memory limiting during spawning" test case on Windows. * Use UNIX shell emulation (0,128ED) in all test cases. Should be necessary in order to run the testsuite on Windows, but it is currently broken anyway. * avoid <EG> when preprocessing files - use GNU Make's $(shell) instead * Fixes builds on MinGW where there are still problems with <EC> and <EG> at least in the virtual build environment. * Results in a another automake warning about non-POSIX Make constructs. This is not critical since we depend on GNU Make anyway.
2021-06-08Windows: normalize $COMSPECRobin Haberkorn3-4/+18
* Environment variables are case insensitive on Windows while SciTECO variables are case sensitive. We must therefore make sure that we first unset any $COMSPEC or $ComSpec from the environment before resetting it, thereby fixing its case. * Fixes command execution via <EC> on systems where the variable was not called $ComSpec.
2021-06-05teco_memory_check() now checks for addition overflows and negative searches ↵Robin Haberkorn2-1/+18
(<S>) for multiplication overflows * Since the numbers come from "outside" (SciTECO scripts) this is easily possible, resulting either in missed checks or even memory corruption. * In particular, this fixes the "Searching with large counts" test case on 32-bit builds. Perhaps at least one CI build should be 32-bit?
2021-06-05don't add -rdynamic when not replacing mallocRobin Haberkorn1-1/+4
* this flag could negatively affect optimizations * fixes builds on MinGW
2021-06-05when not replacing malloc with dlmalloc (--disable-malloc-replacement), ↵Robin Haberkorn1-1/+3
don't build an empty libdlmalloc * on some platforms (eg. Darwin/mac OS) we cannot apparently build empty convenience libraries * instead, we use conditional subdirectories and a conditional library dependency
2021-06-05use memory polling (--disable-malloc-replacement) on Mac OS XRobin Haberkorn1-3/+11
* I could not get malloc replacement via dlmalloc to work. This does not work like on Linux by overwriting weak malloc() functions. It should theoretically be possible to overwrite the default malloc zone but I could not properly debug this since I can only build for Mac OS via CI. * memory polling seems to work though - test suite runs through and it includes memory limiting test cases.
2021-06-04guard against too low arguments to <S> by checking whether the memory limit ↵Robin Haberkorn5-14/+28
would be exceeded * Checking whether the allocation succeeded may not prevent exceeding the memory limit excessively. * Even if the memory limit is not exceeded, the allocation can fail theoretically and the program would terminate abnormally. This however is true for all allocations in SciTECO (via glib). * teco_memory_check() therefore now supports checking whether an allocation would exceed the memory limit which will be useful before very large or variable allocations in addition to the regular checking in teco_machine_main_step(). * As a sideeffect, this fixes the "Searching with large counts" test case on Mac OS where too large allocations were not detected as expected (apparently Mac OS happily gives out ridiculously large chunks of memory). Now, all platforms are guaranteed to have the same behaviour.
2021-06-02avoid aliased functions, as they are not supported on Darwin (macOS)Robin Haberkorn1-1/+5
NOTE: Aliases and weak symbols must not be used for portability reasons!
2021-06-02renamed scintilla.[ch] to symbols.[ch]: fixes builds on case-insensitive ↵Robin Haberkorn6-5/+5
file systems * There is a "Scintilla.h" as well. * should fix macOS and builds on native Windows hosts * It wasn't practical to refer to the Scintilla includes using paths since the Scintilla location is configurable (--with-scintilla). So we'd have to write something like #include <include/Scintilla.h>. For Scinterm we cannot avoid collisions neither as its path is also configurable (--with-scinterm). Effectively, we must prevent name clashes across SciTECO and all of Scintilla and Scinterm.
generated by cgit v1.2.3 (git 2.25.1) at 2025-10-11 10:37:25 +0000