Continued from Patch for variable arguments bug in Tinyfugue (screen corruption)

I was looking at Tinyfugue's source code in order to see what exactly is currently being used from the ncurses library.  I was curious about whether Tinyfugue was currently using any of the main ncurses code for display purposes, or if ncurses was just being used for the termcap information.  That's when I noticed that the ./configure output from the RHEL 3 machine was different from my Ubuntu machine.

RHEL 3:
checking for library containing tgetent... -lncurses

Ubuntu:
checking for library containing tgetent... no
configure: WARNING: Hardcoding terminal codes.

Quite simply, I didn't have the ncurses development libraries installed.  Not a huge deal since getting them from the apt repositories is pretty easy.

The surprise came when I ran a new configure on the original Tinyfugue source (without the va_list patch).  Once I ran Tinyfugue, there was no screen corruption.  I was pretty shocked.  I thought maybe I was running on an unclean directory.  So I started from scratch and after compiling, Tinyfugue was running with no screen corruption.  I went ahead and uninstalled the ncurses development library, cleaned and compiled Tinyfugue, and once again there was screen corruption.

My conclusion is that something with ncurses (either ncurses itself or with how Tinyfugue builds the code in the first place) that prevents the issue with the va_list I experienced.  I'm not going to look to0 much in to this because with my va_list patch, the issue is resolved in both ncurses and non-ncurses builds.

Most of the modifications that I have made to Tinyfugue's source code have been through a shell account on an old machine running 32-bit RHEL 3.  I've never had a problem compiling and using Tinyfugue unless the changes that I've made have broken the build.  Just today I decided to move everything over to my own computer.  I'm currently running a 64bit build of Ubuntu.  As I was switching over, I decided to run builds of the various branches that I work on (dotnotation, C style block comments, Top status area, Telnet option negotiation, etc).  Everything compiled smoothly, with some additional warnings that weren't present on the older compiler available in RHEL 3.  The big surprise was when I attempted to run the latest build of Tinyfugue that includes my telnet option negotiation patch.  I was shocked that the screen was garbled with input, status, and output areas all overlapping.  Even after exiting Tinyfuge, my Konsole session was not working correctly.

Of course, the first that I did was fall back to the unaltered tf-50b8 source code and ran a build.  When the compilation finished, I ran Tinyfugue and saw that the same screen errors were occuring.  I then started debugging Tinyfugue to find out the exact cause of the issue.  After too much time, I finally narrowed it down to the vSprintf function in tfio.c file.  The vSprintf function is passed a va_list.  The va_list is correctly intialized using va_start and torn down using va_end in the function calling vSprintf, so the basic code logic is sound.  The issue is that vSprintf tries to use the va_list after it's been passed to the vsprintf function.  According to the C99 documentation ([ISO/IEC 9899:1999], Section 7.15), the va_list actually is actually in an indeterminate state after returning from the vsprintf function.  So once Tinyfugue tries to use the va_list a second time, it fails (but relatively gracefully).  The failure in this case is just enough to throw the screen functions off, but not enough to crash Tinyfugue.  The solution is to modify vSprintf to use the va_copy macro to make a copy of the va_list, then pass the copy off to the vsprintf function and keep the original copy for internal use.  When work is done on the copied va_list, va_end is called on it.

After getting that patch in place, Tinyfugue now works on my 64 bit Ubuntu machine.  I need to patch all of my branches, but I'm also including the patch here seperately so that anyone who wants to can use it.  I'm unsure if this is an issue with new GCC builds or if it is because of the switch from 32bit to 64bit linux.  In either case, the updated code compiles correctly and shows no signs of screen corruption on either system.

Continued at Patch for variable arguments bug in Tinyfugue (screen-corruption) (Cont)

fix64bit_va.patch (1.43 kb)

When naming variables or macros (that are to be used as functions), Tinyfugue only allows the use of AlphaNumeric characters and underscores.  This patch enables the dot, ".", as a valid character in variable and function names.  Even though Tinyfugue doesn't recognize scripts as classes, enabling "dot notation" allows for a style of coding that reflects an object oriented approach to script organization.

Instructions for compiling

1. Download the Tinyfugue source (http://tinyfugue.sourceforge.net/#source)
2. Download the dotnotation.patch file into the newly created tf-50b8/src directory.  A directory listing of this directory should show multiple files ending in .h and .c
3. Open a command prompt and "cd" into the tf-50b8/src directory.
4. Run "patch < dotnotation.patch" without the quotes.
5. Run "cd .." to go up to the parent folder
6. Run "./configure" to run the configuration program
7. Run "make" to compile the program
8. Assuming you are an admin (either by group membership or through sudo), run "make install" to install the newly created "tf" executable

Instructions for testing

Once the executable has been compiled, the following script should test the "dot notation" functionality.

/def dotnotation.test=/return Testing dot notation: %*

/eval /echo -aCred - $[dotnotation.test("Hello World")]

If the patch is working, then this should print "Testing dot notation: Hello World" out to the screen in red.  If the patch isn't working, then you'll get a message stating "% EVAL: expression syntax error: expected operator or ']', found '.'."

Caveats

With this patch, Tinyfugue doesn't see any difference between the dot and any other valid characters.  This means that it is possible to use dots in such a way that they are valid in a Tinyfugue sript, but would be invalid in most object oriented languages.

These are all perfectly legal: like  is perfectly legal.  Other items that are perfectly legal are:

• /def ...=/return "All dots for a function name and would be called as ...()"
• /def a.b.=/return "function name ends in a dot and would be called as a.b.()"
• /def .a.b=/return "function name begins with a dot and would be called as .a.b()"
• /def a..b=/return "function name has two consecutive dots and would be called as a..b()"
• /set ..a.b=1
• /set ...=1
• /set ..=1
• /set a..=1

The addition of the dot as a valid charact for variables also makes the behavior of some current scripts change.

For example, "/set myname=David%;/eval /echo My name is %myname." would not work as expected and would instead print out "My name is".

From Tinyfugue's (new) view, the variable starts at % and continues until it hits an invalid character for a variable name.  In this case, the dot is a valid character, so Tinyfugue sees the variable name as "myname.", looks it up, doesn't find it and puts a blank in its space.  This is actually already covered by "/help substitution" with the text "The brackets are recommended for clarity, but may be omitted if there is no default and the text following it can not be misinterpreted as part of the selector.".

In this case, the dot could be misinterpreted as part of the variable name and thus brackets should be used.  The fix for this is to use proper variable enclosures.  A working copy of the above example would be "/eval /echo My name is %{myname}."  This unambiguously tells Tinyfugue that the variable name is "myname" and not "myname.".

Comparison to currently available naming options

As this patch does not provide any enforcement of commonly used dot notation restrictions, the patch is only useful in helping make scripts more readable.  It provides for a less ambiguous method of providing object oriented-like naming schemes in Tinyfugue.

The only non-AlphaNumeric character currently available is the underscore.  The underscore can be used as a way to organize scripts, but its meaning can be ambiguous as the underscore is also commonly used to specify a space character.  It is not always easy to tell whether an underscore's logical meaning is to specify a space in a proper name or if its meaning is to specify a member value or function.

By providing two special characters, the dot and the underscore, function and variable names can be formulated in such a way that the logical meaning of the name is clearer.  For example, with /def a_b.c_d it is easy to that this function represents a logical member of the a_b object called c_d whereas with /def a_b_c_d that same logical meaning is not readily apparent.

dotnotation.patch (2.77 kb)