Unified Sources

The changes to 1.5.1sec2 and 1.6b3 were tracked by unifying the sources using the mibexp format. This is in an experimental mark-up format which allows easy comparison of multiple versions of software. The format is described in more detail below, but it is similar to #if/#endif conditionals. It's use is not restricted to C language sources.

The unified sources can be found at:


Each version is marked in an mibexp conditional clause by an X-tag....

The defining property of XTAGs is that they can be used to export a complete source for whatever version the tag is for.

Each change is also marked with a descriptor tag, which is why the change was made (in my opinion. I didn't make the changes....) Descriptor tags cannot be exported to generate a complete source, they are for tagging purposes only.

The descriptor tags in use are:

INN160XS
"External String" limit overrun patches. Actual bugs, which should be patched because they operate with external data (from messages, etc.) These are fixed in 1.5.1corr, 1.5.1sec2,
and 1.6b3
In 1.5.1sec2: Yes
In 1.5.1corr: Yes
In 1.6b3: Yes

INN160DF
"Other Defect Fix" Bugs which are fixed in 1.5.1corr, and probably 1.6b3, but not very many are fixed in 1.5.1sec2. See the list INN 1.5.1sec2 Software Action Items
In 1.5.1sec2: No
In 1.5.1corr: Yes
In 1.6b3: Yes

INN160SL
"String limit" overrun patches which could theoretically overrun, but operate with internal dataSome may be impossible to trigger without truly bizarre config.data setups. (Such as path lengths > 256)

The long-term course of action is to re-engineer INN with limitless strings. Right now, the 160SL "solution" is to truncate strings. I disagree with this method, especially in functions like the new FileGlue() (innd/innd.c) which truncate strings silently. This is not the behavior you want when you are building a path to files and executables. They are not in 1.5.1corr, but are in 1.6b3 and 1.5.1sec2

In 1.5.1sec2: Yes
In 1.5.1corr: No
In 1.6b3: Yes


INN160BS
"Belt and Suspenders" patches: string limit patches which were not necessary. (The limit was already considered when sizing buffers, etc.) These are not actually "harmless" patches because these patches are where serious bugs were introduced into 1.6b3 and 1.5.1sec2 which crash INN. Patches are available. See INN 1.5.1sec2 Software Action Items and INN 1.6b3 Software Action Items

The other reason they are not harmless is that every changed line of code increases the possibility of breaking many "third-party" patches to INN. Many of these patches are quite popular, and some think necessary for running a site with full feeds.

In 1.5.1sec2: Yes
In 1.5.1corr: No
In 1.6b3: Yes

INN160SD
String limit patch attempts which are defective.
There are very few of these. All the ones I am aware of are fixed with the "crash" patches in 1.6b3 and 1.5.1sec2.
In 1.5.1sec2: Yes
In 1.5.1corr: No
In 1.6b3: Yes

INN160CC
"Change in comments". Documentation change, fix, etc with NO executable code change.

Like, INN160BS changes, every changed line of code increases the possibility of breaking many "third-party" patches to INN.

In 1.5.1sec2: Yes
In 1.5.1corr: No
In 1.6b3: Yes

INN1P6FE,
Feature enhancement, operational change
A complete list is found at INN Feature Changes: 1.5.1 to get 1.6
In 1.5.1sec2: No
In 1.5.1corr: No
In 1.6b3: Yes



Here is an example of code in the mibexp markup format, which shows how the unified format allows easy comparison. (This is from innd.c)

-- Begin Example ---
#mibexp#ifexp INN1P6BS  XINN1P6B2
    Path.Data = NEW(char, Path.Used + 1);
    (void)snprintf(Path.Data, Path.Used + 1, "%s!", path);
#mibexp#elifexp XINN151SEC
    Path.Used = strlen (path) + 1 ;
    Path.Size = Path.Used + 1 ;
    Path.Data = NEW(char, Path.Size);
    (void)snprintf(Path.Data, Path.Size, "%s!", path);
#mibexp#elseexp
    Path.Data = NEW(char, Path.Used + 1);
    (void)sprintf(Path.Data, "%s!", path);
#mibexp#endexp 770

    /* Get the Xref prefix. */
    Xref.Size = STRLEN("Xref: ") + strlen(path) + 1;
    Xref.Data = NEW(char, Xref.Size);
-- End Example ---


Further explanation of the mibexp markup format.
- - - - - - - - - - - - - - - - - - - - - - - -
1. Syntax:
	#mibexp#ifexp TAG [TAG2...]
	#mibexp#elifexp TAG [TAG2...]
	#mibexp#elseexp
	#mibexp#endexp N
Where N is the line number of the base version: in this case
the 1.5.1 version.

2. The else clause is always the base version.

3. Processing occurs BEFORE comments or other conditionals are interpreted.

4. mibexp directives may not be nested.

I have tools for creating and manipulating mibexp files, but they are still experimental. (I.e. not fully tested.) They will be available for purchase soon.


RKT Rapid-Links:[Search] [RKT Tips] Path: / Usenet RKT / For Providers / INN Patches / 0038.htm
You can find a summary and links related to this topic
as part of the Mib Software Usenet RKT.