Kevin Day [Tue, 19 Jan 2021 03:24:07 +0000 (21:24 -0600)]
Update: f_thread_create() fixes.
The f_thread_create() function should allow for attribute and argument to be optional.
The pthread_create() allows for attribute to be NULL and I am now also assuming that the passed arguments can also be NULL.
Kevin Day [Sun, 17 Jan 2021 03:24:47 +0000 (21:24 -0600)]
Update: synchronize f_utf (and fl_utf) with f_string (and fl_string), update f_string and fl_string, and fix some bugs.
Get the UTF related code more up to date and in sync with all of the string changes.
This brings the UTF string types in line with the normal string types.
Much of the code is moved out of fl_utf and fl_string and into f_utf and f_string.
This is only the first pass at updating the UTF code.
The function comments need a cleanup pass.
The pre-existing incomplete UTF code remains incomplete.
There were some minor bugs and typos that needed fixing that I happened across while working on this.
The UTF string types should just use the same length types as the string types.
Rename the *_non_graph() functions to *_graph_non().
There will need to be another follow up commit to cleanup the code that as of this commit now contains duplicate code.
The FSS processing code is a likely case for this.
Kevin Day [Sat, 16 Jan 2021 04:28:28 +0000 (22:28 -0600)]
Update: fix regressions due to recent mass structural changes and apply some updates.
Fix typo in documentation 'object' should be 'name'.
Remove *_quote_delete() and *_quote_destroy() functions.
When I fixed the logic in some of the macros and the recently added functions, I failed to do so for some of the memory structure functions.
This caused failures during the Featureless Make "make" compilation.
I decided to go ahead and expand the macros, which was necessary for exposing the bug but I decided to keep them expanded.
These are private functions and the macros are there for helpers not so much as a rule.
The expansions directly call the f_memory_delete() and f_memory_destroy() functions (good thing I decided to keep those!).
In some cases, use *_increase() functions where possible.
Get rid of moe of the old FSS private functions that are now functional duplicates of functionality now provided by the f_type_aray, f_string, and f_memory.
This will be an ongoing thing.
Remove stale comments referencing "f_memory_out".
A bug was discovered (not a regression) where I used incorrect logic and was acting on potentially unallocated memory when passing the contents_quoted to another function.
Call the appropriate *_increase() function before getting the memory address to a content quote.
This bug is also causing problems with the Featureless Make "make" process.
Kevin Day [Fri, 15 Jan 2021 02:22:52 +0000 (20:22 -0600)]
Cleanup: update f_memory function structure to follow more recent practices.
The more recent practices being followed are having constants on the left and pointers on the right.
The f_memory functions appear to be well followed and the update to this turned out pretty easy.
Despite how many things depend on memory operations in this project, there is actually very little to change.
I consider this a small victory in how my project is designed and intended to be used.
Kevin Day [Thu, 14 Jan 2021 04:14:45 +0000 (22:14 -0600)]
Update: more FLL cleanup and consistency.
Finish the previous cleanup and consistency changes.
There is likely more to do, but I believe this is enough for now, at least in regards to this set of changes.
Much of the code is refreshed in terms the memory structure.
I don't like doing this but after some consideration, I have decided to break out the array types from f_type into a new project, f_type_array.
This is an exception cases of the exception cases (unfortunately).
This acts as an extension to f_type, except that it depends on f_memory.
This will provide common functions for array types.
Parts of this remain defined in f_type because f_memory also depends on these arrays.
By handling code this way I can avoid circular dependencies in both f_type and f_memory.
One major change is now that I am implementing more functions in place of the memory-related macros (to save space, overall), I find it easier and simpler to only use resize and adjust in place of delete and destroy.
This significantly reduces the amount of code needed in regards to trying to achieve completeness.
I was also considering removing f_memory_delete() and f_memory_destroy(), but decided to roll that back.
The f_memory_delete() and f_memory_destroy() are low level and should still exist for completeness even if I am re-using adjust and resize for many of the other parts.
For example, there are cases where I may need to call free() on types not defined by this project, these functions will be helpful.
Furthermore, to help hackers implement their own variations of things, providing these may be a boon.
This is such a massive change that I am concerned of regressions.
I have done some quick compile and run tests using the programs so I believe that this is reasonably done without regressions.
I plan on doing a refresh the UTF-8 string processing code (which will be a complete refresh to be just like the recent f_string changes).
There may be other changes needed to prep the state of the code before I do this.
Kevin Day [Sat, 9 Jan 2021 21:00:23 +0000 (15:00 -0600)]
Update: Remove *_decrease() and *_decimate() macros and functions.
My general design goal is "completeness".
I originally looked at the *_decrease() or *_decimate() macros and functions as a completeness compliment of the increase() macros and functions.
There *incease_by() macros and functions as well as their compliments can already resize by 1 (or any given amount).
This means that the *_increase() (and similar) are not needed.
This puts the *_increase() in the position of an "exception" case.
As an exception case, I believe it does not necessarily need a completeness compliment.
Unlike the *_increase_by() macros and functions, the *_increase() increases by 1 or more (depending on the definition of the macro f_memory_default_allocation_step).
There is no logical compliment of this behavior for a decrease() macro/function.
Therefore, I believe it is more appropriate to remove all *_decrease() and *_decimate() macros and functions.
Kevin Day [Fri, 8 Jan 2021 05:12:53 +0000 (23:12 -0600)]
Progress: restructure string project and eventially utf project.
This collapses much of the code from fl_string into f_string.
I have originally wanted to keep f_string source file free to help reduce recursion but the design kept leading me to deciding to do this.
The final straw was the extern const strings.
This moves all of the string related functionality that does not strictly depend on f_utf into f_string.
I expect that the fl_utf and fl_string will be merged together into fl_string.
I also expect that following these changes and the related cleanups then I will be at a good point to update and get the UTF-8 processing code in sync with the current string processing code.
That is, the f_utf_string needs to work similar to f_string types as well as have the same functions.
This collapsing of the level 1 code into level 0 code will also require an update on all appropriate dependencies (header files being included, etc..).
I also strived for more completeness in this and added many missing functions and macros.
I did not get as far as I would like, resulting in this being a Progress commit instead of an Update commit.
Kevin Day [Wed, 6 Jan 2021 04:58:51 +0000 (22:58 -0600)]
Update: consistency issues in code design, better utilize global constants, and other related changes or cleanups.
Over time the code gets out of sync and less consistent.
Update the source code structure to be a bit more consisten.
There are more commits like this to come.
Some of the consistency improvements involve:
- Utilizing the XXX-common.h (and now XXX-common.c) sources.
- Utilize the private-XXX.h and private-XXX.c sources.
- More consistent declaration of allocation-related macros.
- This updates mostly the array related structures.
- This does not include the matrix related structures (an array of an array) to keep this commit from being too massive.
- Re-order how I declae the allocation macros.
- Add more of the increase(..), decrease(..) and similar macros (there will be further work on this in the future).
- Use keyword "register" for the resize, delete, and similar macros.
- If there are any sources, the main source for a project will exist even if it is empty.
- Start a practice of using "_s", even in the define declarations for the "_di_XXX_" blocks.
- Add semicolons at the end of macro functions.
- In the past, I decided to not have these but now I have decided the semicolons probably should be there as a practice (even if their presence could be redundant).
- Any exception cases where a macro function is meant to be used inline will not have semicolon.
- I only spent so much time on this an there are likely several more macros to cleanup in this regard.
I have been using "const static" for global strings.
I seem to have forgotten that the C keyword "static" does not operate like "static" would natural do so in the global scope.
The solution is to remove the static and make these "extern".
Then those "extern" must be added to a source file and compiled in.
Use these newly defined global constants strings more consistently.
This adds a source file to f_string project.
I tried avoiding this in the past but now that I am, I should move much of the fl_string code into f_string.
This will simplify the project in many ways, but the changeset will be huge.
To avoid mixing too much more in this commit, I will address this aspect at a later date.
Simplify the allocation error, reducing memory related statuc codes to just F_memory and F_memory_not.
The recent changes where thread (pthread) support being added caused problems (and revealed problems) in my package helper script.
Fix the revealed problems in the package helper script.
Update the package helper script to better handle the special situations in regards to thread support.
Update all of these settings files based on the dependency changes and the packager helper script changes.
Fix a bug in the memory resize/adjust logic where I failed to consistenty memset newly allocated space.
This is the result of checking to see if the pointe has changed.
I no longer no why I was doing that and it seems plainly wrong.
I also never consistently performed memset() after calloc() (Inside the adjust/resize, memset() is not being called).
Newly allocated memory should be guaranteed zeroed according to the designs of this project and this should now be true.
Minor cleanup in the filesystem paths.
I renamed "filesystem" to "tree" in this regard and relocated that code to the path-common.h, dropping the path_filesystem.h file.
Add ascii characters.
If I am going to use hardcoded strings, use the global constant strings to reduce the code size (even if only by small margins).
More work is needed here, I only did what I needed to do.
I would note that this is intended for ASCII only and is not intended to be locale/language aware.
Any error message during testing lead me to noticing a problem in the private_fll_error_print() in regards to the text being printed.
Add the access denied error message while I am at it.
Kevin Day [Wed, 6 Jan 2021 01:23:35 +0000 (19:23 -0600)]
Bugfix: conversion scale maximums are too short and rename scale to digits.
The "scale" max is not consistently correct.
In some cases I have the signed one number less than the unsigned version (which should only be true for the binary representation).
In other cases, I should have a larger number because it doesn't fully represent all digits.
This is likely a mistake resulting from my misuse of the term "scale".
The way I am using "scale" is not exactly correct with the meaning of the word.
Rename "scale" to "digits" to better represent what this variable its related defines are for.
Kevin Day [Tue, 5 Jan 2021 06:01:57 +0000 (00:01 -0600)]
Update: memory changes, macro changes, and return type changes.
The practice of having an increase(), increase_by(), etc.. has become standard.
Redesign the code to better follow this, simplifying the code base some.
There is more work to do in this regard, but this focuses on just changing the existing code.
While I prefer to always return "const" where I can, simplify the design to always return "f_status_t" instead of using the wrapping macro "f_return_status".
This will make things between C and C++ more consistent.
Kevin Day [Mon, 4 Jan 2021 03:20:05 +0000 (21:20 -0600)]
Progress: controller program and other minor tweaks.
Add support for "affinity" and "limit" to the controller program (and the execute functions from the execute projects).
The "affinity" allows settings specific CPUs to run the process on.
The "limit" allows for customizing the resource limits (ie: ulimit) in the process.
The resource names are used as-is, such as defined in /etc/security/limits.conf on some Linux systems.
Only the well known resource types are supported.
(For example, debian systems has 'chroot', which is not supported by this implementation at this time.)
New projects are added to address these features.
A project f_schedule is suggested by the comments added in this commit and may be introduced on a later date.
Minor tweaks includes using a global static variable for the space as a string " ".
Kevin Day [Sun, 3 Jan 2021 03:11:02 +0000 (21:11 -0600)]
Update: thread support.
Finish wrapping the pthread functions using f_thread.
I have observed some problems under GLIBC where static linking and -pthreads do not appear to work.
This is a problem with GLIBC as far as I can tell and I must ignore it to the extend that I can.
That said, because of the problems I decided to disable static compiling by default.
Either a better libc should be used or the static libraries should be compiled with thread support disabled.
I have not yet decided whether or not I intend to have thread suppot enabled or disabled by default.
The current default as of this commit is enabled.
There are some tweaks to the build settings to make things slightly easier when building with threads disabled vs threads enabled.
Completely separate f_signal from f_thread (where previously f_signal has conditional thread support).
Add a threadsafe option to fl_execute_parameter_t to conditionally use a threadsafe signal handler or not.
Kevin Day [Thu, 31 Dec 2020 22:21:04 +0000 (16:21 -0600)]
Progress: controller program, restructure some of f*_execute functionality, and add or update documentation.
For the controller program:
- add "freeze", "thaw", "pause", and "resume".
- improve simulation to actually perform an execute, but with a stub execution (an empty bash script).
- print more information when performing the stubbed simulation.
- simulation should not stop on errors when simulating, there are a number of cases where stopping is still happening.
- add a microsleep during the stubbed execution to better simulate synchronous vs asynchronous behavior.
- The F_schedule is no longer being returned from the child process, do not treat it as a child exit state.
- add more documentation.
Kevin Day [Wed, 30 Dec 2020 21:13:29 +0000 (15:13 -0600)]
Progress: control program, adding numerous FLL projects as needed.
This focuses primarily on getting control groups working.
There are also some f_account changes, but nothing in the control program used the f_account changes.
Kevin Day [Sat, 26 Dec 2020 03:39:17 +0000 (21:39 -0600)]
Progress: controller program and other changes.
Lots of changes with the most notable described below.
This adds support for capabilities, which depends on the external libcap (-lcap).
This introduces a problem because it is POSIX complaint in the sense of a draft and Linux has adopted it.
The end result is that instead of being in libc, the functions are defined in libcap.
To address this complication, a new project f_capability, is added to conditional compile in support and otherwise provide stubs.
This allows the rest of the projects to just call the f_capability functions without needing as many macros.
A define macro is still needed and the appropriate libary (-lcap) is still needed (or not if disabled).
I have further observed that when adding -lcap, the ar progam's ficklness on the order becomes a problem.
As a temporary work around, I am appending the "build_libraries" after all libaries introduced by a mode.
Kevin Day [Sun, 20 Dec 2020 04:04:04 +0000 (22:04 -0600)]
Progress: controller program and execute function improvements.
Get rid f fl_execute_parameter_option_fixated.
A better approach is just to allow a 0 to be passed instead of the string (aka: NULL).
The execute functions can then detect whether or not full fixation is needed.
An additional parameter check is now needed as if the program is 0 then there must be at least 1 argument defined.
Due to design changes the 'method' property for individual rule actions no longer needs to be on the rule action structure.
In fact, it is now confusing as each action represents only a single action (itself).
Add support for the "script" rule setting to designate the script program to run for scripts.
Kevin Day [Sun, 20 Dec 2020 00:05:49 +0000 (18:05 -0600)]
Progress: controller program and related changes, such a adding fll_environment.
The environment loading functionality is likely to be very common.
Create fll_environment (because it depends on fl_string) and provide the environment variable loading functionality.
Replace the related code from Featureless Make to use the code from fll_environment.
Instead of using two string arrays, use an array of string maps for the environment.
Make the appropriate changes in all affected projects.
Add the fll_execute_as() function to perform an execution without a fork() operation.
This will become important once I write the f_asynchronous and related projects.
A new execute parameter option fl_execute_parameter_option_fixated is introduced to allow for execution without automatically prepending the program name at index 0.
There are existing projects that have to reconstruct an array to meet the structure of the execute functions (which then reconstructs the array again...essentially back to how it started).
This is a bit ridiculous and an artifact of the previous design.
With this new execute parameter option, the array is not reconstructed and assumed to be correct.
The controller program now sets the environment variables on the executed process (which currently only script execution is written).
Kevin Day [Sat, 19 Dec 2020 04:55:00 +0000 (22:55 -0600)]
Update: rewrite the execute functions to accept a parameter structure.
This changes the programs so that the execute function that handles piping data to the child in a separate function to normal execute function.
This happens via a private function and is therefore transparent to the caller.
The caller can select options to pass to tweak the operation of the execute function.
While I do not like using structures in this way as it complicate the code in one respect, in another respect it simplifies things.
There are also fewer parameters passed which is easier on the registers.
The f_execute_asynchronous_t structure is not needed with this design.
Future changes will include a new project (likely called f_asynchronous) to assist in performing asynchronous tasks.
Note: this go around I am trying constant pointers.
This makes it compatible when passing constants through.
Kevin Day [Fri, 18 Dec 2020 04:18:00 +0000 (22:18 -0600)]
Progress: controller program, working on execute script logic.
I have been tossing around how exactly I want to implement the execute with piped data.
I have decided that I should clean up the parameters and redesign it to accept a few specialized structures.
Before I do that, I wanted to confirm that the pipe to shell (such as bash) works as I expect it to.
This tweaks the code to a temporary state where I can automatically execute some bash script with some string piped to it.
This seems to work as expected and errors out as expected.
I also need to write some asynchronous functions to help with managing asynchronous processes.
This might require a new series of projects (f_asynchronous, fl_asynchronous, etc..).
Note: "bash" was used as the default script, but I really need to provide some sort of configuration to change this.
Kevin Day [Thu, 17 Dec 2020 05:40:42 +0000 (23:40 -0600)]
Progress: controller program, featureless make tweaks, and execute cleanup.
I am going to be using controller program to codestorm how I want the execute functions to handle forking with child.
I may simplify the "pipe" arguments to only accept an input pipe and then write a execute fork functions that perform the fork and return to the caller so that the caller fully handles everything.
This would allow for the "non-fork" (as in "fork" is not in the function names) functions to only focus on simple executions.
This could then make way for the asynchronous behavior that is planned.
Kevin Day [Tue, 15 Dec 2020 17:47:00 +0000 (11:47 -0600)]
Update: wrap some macros in functions and minor cleanups.
The macro design has its uses but to save compiled size provide functions that are essentially wrappers to the macros.
Macros can also be flakey and sensitive while being harder to debug.
The delete functions that wrap the macros use the delete_simple macro.
Make the fss_macro.h and its contents private.
When decreasing, instead of using "if (X - 1 > 0)..." use "if (X > 1)...".
This avoids performing a math operation when it could otherwise be avoided.
Kevin Day [Mon, 14 Dec 2020 01:46:11 +0000 (19:46 -0600)]
Update: f_memory tweaks, always call memset() on new allocations.
This is already done with reallocations.
Be consistent and also do this for allocations.
The size parameters represent the size of the memory structure, which should always be non-zero and positive.
The length parameter, on the other hand, is just the amount of time the structure is to be allocation, which should always be non-negative.
The length parameter, therefore, can be 0 and if it is then do nothing (this relaxes the parameter restrictions).
Kevin Day [Sun, 13 Dec 2020 21:47:18 +0000 (15:47 -0600)]
Feature: the execute functions now support custom pipes.
This is necessary for the parent process to directly pipe date to/from a child process.
One of the intended goals is for something like the controller program to directly execute a bash script from a string generated by the parent (where this is no file).
The standard input can be used by the child process as pipe data.
When a pipe is passed then the execute functions are asynchronous instead of blocking.
The caller must properly handling all blocking operations as appropriate.
Kevin Day [Sun, 13 Dec 2020 21:01:33 +0000 (15:01 -0600)]
Update: always ensure standard file descriptors are closed on program exit.
Explicitly close file descritpros on exit.
This is especially important now that the program could be a child process and the file descriptor could be open between a parent process.
Kevin Day [Sun, 13 Dec 2020 19:01:48 +0000 (13:01 -0600)]
Security: A child process of an execv() family of functions may leak memory if script is called.
When calling a bash script, the exit() call gets triggered but memory is never cleared.
I am suspecting that this is happening because the script is run in the current process space whereas when calling a binary the process changes for the child.
There are new status codes: F_child, F_child_not, F_parent, F_parent_not.
The execute functions do not know what type of file is being executed.
Return F_child for the child process and allow the caller to handle the exit behavior of the child process.
This required significant changes to the Featureless Make, but the Featureless Make now always clears memory even for scripts.
The firewall program also had to be changed.
Instead of solving the potentially issues there, I decided to (for the time being) just mimic the previous behavior and call exit for the child process.
The firewall program needs a rewrite anyway, so I am holding off on major changes.
Refactor, cleanup, and improve the execute family of functions.
This was my original commit plans but when I observed the memory leak the refactor and cleanup became this security related commit.
As per cleanup plans:
- Moved common code into shared private functions.
- Change parameter checking granularity.
- Allow for 0 length strings as arguments.
- Avoid memory allocation inside execute functions.
- Consistently check WIFEXITED() on child process result.
- Update the documentation to follow more recent practices.
Kevin Day [Sun, 13 Dec 2020 04:09:40 +0000 (22:09 -0600)]
Progress: contoller program.
This focuses on getting the simulation code working as desired.
While --test is what triggers simulation mode, if --validate is specified, then additional information on rules are provided.
Break apart the default pid file name to operate on a per entry basis.
This will allow for multiple controllers to co-exist with different pid files (and likewise eventually socket files).
This fixes a lot of bugs/mistakes that cropped up during the previous codestorming as well as restructures some of the data types.
Kevin Day [Thu, 10 Dec 2020 04:14:45 +0000 (22:14 -0600)]
Progress: controller program.
This includes changes using static variables that was introduced in a previous commit at the entire fll project level.
Begin implementing the simulation execution.
There is much to do here and the simulation is already showing problems that need to be resolved (such as in the rule loading process).
Kevin Day [Thu, 10 Dec 2020 01:39:57 +0000 (19:39 -0600)]
Cleanup: use const more, but in a way that works with pointers.
The standard practice is to specify const first.
In the case of pointers, anything to the left of such a declaration represents what is being pointed to.
This means const cannot be used in this case unless the pointer is intending to point to a constant.
The const qualifier may instead be put after the pointer symbol '*' to designate that the pointer and not what is being pointed to is to be a constant.
It seems that I tend to forget this behavior.
This makes a pass at existing uses of such pointers, adding const in the appropriate way.
Kevin Day [Sun, 6 Dec 2020 04:48:43 +0000 (22:48 -0600)]
Progress: controller program.
Change "timeout" property to the more generic "number".
This can then be used for types "timeout" and "item", whereas the "item" number represents the location within the items list.
This is not known until all entry items are loaded and is therefore updated during the pre-process phase.
This implements the pre-process phase after the load phase.
The pre-process will perform additional checks, such as determining if "ready" is set somewhere in the active chain.
This makes sure recursion to an item already on the stack is not allowed.
Do some cleanups, reducing the if/then nesting by adding "do nothing" comment and letting the "else" condition handle the case appropriately.
Internally, line counting starts at 0, but when dealing with presenting the lines to users, the lines start at 1.
Change the behavior to increase the line number appropriately for entries.
The same will likely need to be done for rules.
Kevin Day [Fri, 4 Dec 2020 05:08:59 +0000 (23:08 -0600)]
Cleanup: _F_types_h should be _F_type_h and some macros have misplaces the "s".
The f_type project is singular, so do not use an "s" in the name.
Some of the macros in the type_array.h file were not converted from having the "s" after the _t to more accurately matching the type name.
For example uint8s_t should have macros using uint8s_t instead of uint8_ts.
Kevin Day [Thu, 3 Dec 2020 02:55:54 +0000 (20:55 -0600)]
Cleanup: move "macro_" prefix to after program name.
With the macro_ being defined after f_, fl_, and fll_, it makes more sense to follow the same logic with programs.
For example, macro_iki_read_X() is now iki_read_macro_X().
This more accurately associates the macro with the program via styling practices.
Kevin Day [Thu, 3 Dec 2020 01:01:29 +0000 (19:01 -0600)]
Update: memory changes, memory bugfixes, and minor controller program fixes.
Do some minor cleanup with the allocation functions.
The *_delete_simple() and *_destroy_simple() macros need to always set size to 0, because they are always ignoring the return status.
Also move the relating check outside of the for loop for performance reasons.
Minor cleanups in memory functions.
Add additional parameter checks to the memory create functions.
Add additional size and length checks in the memory delete and destroy functions.
Fix bug in f_macro_memory_structure_macro_increment() where if condition is obviously wrong (two '>' checks are used against each other!).
Change behavior to increment against "used" instead of "size", more consistently.
Rewrite the *_increase() and *_increase_by() functions due to bugs and inconsistencies.
Only use variables when needed for performance and resource reasons.
Get rid of the F_array_too_large on success behavior as the current design doesn't handle the cases where both F_array_too_large and an error occurs afterwards.
Fix mistake in controller program where I forgot to actually set the allocated sizes.
Use counter instead of pointer for entry item in controller program.
In some cases, use fl_string_dynamic_terminate_after() instead of fl_string_dynamic_terminate() (there will likely be more of these changes).
Kevin Day [Tue, 1 Dec 2020 03:48:15 +0000 (21:48 -0600)]
Update: provide file mode macros in f_file.
I would rather provide static constant strings, but the Posix file string functions that use this expect a non-constant string.
This is unsafe, so just stick with macros.
Kevin Day [Tue, 1 Dec 2020 02:21:57 +0000 (20:21 -0600)]
Update: status code changes, adding "_not" in more places.
I am not a fan of having so many "_not".
I believe I even made efforts to reduce its usage in the past.
Having said that, there ended up being too many different cases where "_not" makes sense.
I want things to be consistent, so this commit introduces "_not" more thoroughly unless it makes sense not to.
There are also cases where I have prefixes, such as "un" in unknown.
Change this to be consistent with the "_not" logic.
This results in changes like F_unknown -> F_known_not.
Other minor cleanups exist, such as F_interrupted -> F_interrupt.
I expect down the road there will be changes where these "_not" are used in functions where the "_not" is not used.
(Example: it may be that a function returns F_number (with error bit set) on invalid number, but it may be better to now use F_number_not.)
Kevin Day [Mon, 30 Nov 2020 03:38:36 +0000 (21:38 -0600)]
Bugfix: provide static variable "fll_error_string_null_s".
When using the fl_color_print functions, the context before and after pointers may safely be NULL.
When using the printf functions, the context before and after pointers cannot safely be NULL.
In the second case, a global static is now provided that is essentially a NULL string of a compatible type.
Kevin Day [Sun, 29 Nov 2020 06:58:58 +0000 (00:58 -0600)]
Bugfix: featureless make is not copying settings directory.
The contents of the directory are being copied instead of the directory itself.
Change the behavior to instead copy the entire directory and not just its contents.
Also move the directory check into its own line instead of inline inside of an if condition.
The signal check is moved with it.
Kevin Day [Mon, 23 Nov 2020 03:56:11 +0000 (21:56 -0600)]
Progress: controller program.
Wrap up some of the existing rules code.
Begin writing the entry code.
This seems like a good time to start using and referencing my unit of time called "Time".
Use MegaTime (aka: milliseconds) to handle the time, which will be stored in a 64bit unsigned integer as units of Time.
Kevin Day [Mon, 23 Nov 2020 03:54:32 +0000 (21:54 -0600)]
Cleanup: fix comment in featureless make program.
Add a @fixme for UTF-8 because I noticed that I was not using UTF-8 character support.
If environment variables should only be ASCII, update the documentation to better reflect this.
Kevin Day [Thu, 19 Nov 2020 04:30:45 +0000 (22:30 -0600)]
Progress: controller program.
Wrap up the current implementation of the rule read functions.
Utilize a (private) cache, reducing the parameters and reducing the amount of allocations.
How I am using the cache changed as I went and I need to come back and review it again before completing this program.
Kevin Day [Sun, 15 Nov 2020 23:36:55 +0000 (17:36 -0600)]
Bugfix: Embedded List is not properly handling delimits on write.
This is hard to observe because of how bash handles newlines.
For example:
echo "$(echo -e " To {\n World\n \\\\\\\\\\\\\\{\n")"
Would produce a string where the slashes after world actually represent a total of 4 slashes.
The problem with bash is that it "guesses" the number of slashes.
Another concern is that there are two quotes, so a slash has to be escaped twice for such a string in bash.
As a more complex example, see:
# echo "$(echo -e "\\\\\\\\\\\\\\")" | byte_dump -tcw 5
Once past the confusing behavior of backslash escaping in Bash, one can then observe that this project is incorrectly escaping backslashes.
In the case of Embedded List close character (the close brace '}') only the first backslash needs to be escaped.
In the case of Embedded List open character (the open brace '{') every even backslash must be escaped (and there should only be a single unescaped odd backslash).
The problem is that the code is treating the close brace as an open brace, resulting in too many backslashes.
There is also an ends of EOL boolean that appears to be being incorrectly set.
The EOL is detected at range->start position, but the position is being reset to the saved "start" position.