[PATCH] Fix FilenameTruncated check in ExpandFilenames

[CyberShadow]

The mailing list seems to be dead, so posting this here.

Code: Select all

This patch fixes a check that would otherwise always have evaluated to
"false". Since ConcatenateMagickString will never create a string the
strlen of which to be greater or equal than the specified maximum length
(due to the null terminator), ExpandFilenames always truncated filenames 
silently.
---
 magick/utility.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/magick/utility.c b/magick/utility.c
index 62c8006..58a9bbb 100644
--- a/magick/utility.c
+++ b/magick/utility.c
@@ -810,31 +810,31 @@ MagickExport MagickBooleanType ExpandFilenames(int *number_arguments,
     /*
       Transfer file list to argument vector.
     */
     vector=(char **) ResizeQuantumMemory(vector,(size_t) *number_arguments+
       count+number_files+1,sizeof(*vector));
     if (vector == (char **) NULL)
       return(MagickFalse);
     for (j=0; j < (long) number_files; j++)
     {
       (void) CopyMagickString(filename,path,MaxTextExtent);
       if (*path != '\0')
         (void) ConcatenateMagickString(filename,DirectorySeparator,
           MaxTextExtent);
       (void) ConcatenateMagickString(filename,filelist[j],MaxTextExtent);
       filelist[j]=DestroyString(filelist[j]);
-      if (strlen(filename) >= MaxTextExtent)
+      if (strlen(filename) >= MaxTextExtent-1)
         ThrowFatalException(OptionFatalError,"FilenameTruncated");
       if (IsPathDirectory(filename) <= 0)
         {
           char
             path[MaxTextExtent];
 
           *path='\0';
           if (*magick != '\0')
             {
               (void) ConcatenateMagickString(path,magick,MaxTextExtent);
               (void) ConcatenateMagickString(path,":",MaxTextExtent);
             }
           (void) ConcatenateMagickString(path,filename,MaxTextExtent);
           if (*subimage != '\0')
             {
-- 
1.7.0.2.msysgit.1.891.gee59bc

On topic: I found the @filelist.txt feature useful for getting around the command-line length limitation on Windows (8191 characters). However, the "filename length" limitation (directly related to the patch above) means that I can't put a very long -draw command in a file. Of course, the simple workaround is to break up the long -draw command into multiple -draw commands. It'd be nice getting rid of that limitation, anyway (it doesn't exist for command-line parameters on systems where the total command-line length isn't an issue, after all).

Edit: looks like the workaround wasn't as simple as splitting up the -draw command-strings - draw settings are lost from one -draw to another.

[magick]

Can you post a context diff so we can see your patch in context of the surrounding source? Thanks.

[CyberShadow]

There are three lines of context in the diff I posted. Should I make a new patch with more context?

[magick]

Yes please.

[CyberShadow]

OK, first post updated.

[Kerun]

I've had the same problem with a too long convert command. I need many (100-300) draw commands. So this solution seems to be the correct one.
@CyberShadow:
may u post an example code snippet?
and i need to recompile magick/utility.c with your diff?

or is there meanwhile an version of imagmagick available, where this feature is integrated?

thx

[CyberShadow]

The patch I posted doesn't allow you to use long commands with the @filename feature. A more complex patch which deals with an expanding buffer is needed for that.

[anthony]

Also related to this is reading a @filename to generate an array of floating point values (used for distort and sparse colors).

The current methods read in the file as a string (with limits) and then do the conversion.

What is really needed is set of functions to read in files and convert them into either an expanding buffer (for string), or an expanding array (for floats). Appropriate -limit settings can also be provided to prevent infinite reads (say with a 'infinite' default setting).