C code convergence

[Chaubert Jérôme]

Hi,
I have been using Clips (via JNI) for many years with great pleasure and I thank you very much for it!
Over time we have made some modifications to the C code for various needs. However, this is not at all practical when it comes to upgrading a version. During the process of switching to Clips6.4.1, I've now taken the time to try to remove all our modifications to make future upgrading easier.

I managed to get rid of all our modifications except for the two following ones that remain necessary for our application to continue to work as expected :
1. In the “textpro.c” file, the NAMESIZE variable at 80 is not sufficient for our needs. We've set it to 200. (furthermore, leaving it at 80 sometimes causes unexpected behavior: the JVM crashes when the Clips environment is destroyed).
2. We have external files (which we read with Clips) whose line feeds are not necessarily correct or uniform. In other words, files under Linux that contain “\r”. As a result, we had to modify the “FillBuffer” code in the “iofun.c” file so that these files could be read correctly. Here's the part of the code concerned:

…
/*==================================*/
/* Grab characters until cr or eof. */
/*==================================*/
//ACORMODIF : CHB : CRLF = \r\n, ligne qui commence par un carriage return (CR)
if (c == '\r')
{
  c = ReadRouter(theEnv,logicalName);
}
while ((c != '\n') && (c != '\r') && (c != EOF) &&
       (! GetHaltExecution(theEnv)))
  {
   buf = ExpandStringWithChar(theEnv,c,buf,currentPosition,maximumSize,*maximumSize+80);
   c = ReadRouter(theEnv,logicalName);
   //ACORMODIF : CHB : Si carriage return (CR) on récupère le line feed (LF)
   if (c == '\r')
   {
     c = ReadRouter(theEnv,logicalName);
   }
  }
…

I was wondering if you would agree to integrate them so that I would no longer have any custom C code left.

[Gary Riley]

I checked in an update for #2. I did it slightly differently so that it would handle these three cases of line endings: cr/crlf/lf.

For #1 I'm going to check to see how difficult it would be to just dynamically allocate the storage for the textpro strings rather than have an arbitary limit.

[Chaubert Jérôme]

Yes, it's clearly better this way for #2, and it works well. Thank you.
I look forward to hearing from you on point #1.

[Gary Riley]

I checked in the changes for textpro that you can try out to see if they resolve the issue you were seeing.

[Chaubert Jérôme]

Everything works perfectly. This way I no longer have any differences in the C code. This is a major breakthrough for me! Many thanks.