Problem integrating Crafty with Windows GUI

[ignacioalex]

To be on the safe side I would change these too in data.c (haven't yet tested it):

char book_path[255] = { BOOKDIR };
char log_path[255] = { LOGDIR };
char tb_path[255] = { TBDIR };
char rc_path[255] = { RCDIR };

I think that defining a LONGEST_PATH_LENGTH=255 constant and checking against it in various parts of the code would make it a lot more robust against Java programmers.

Although I'm a very unskilled C programmer and don't have any knowledge of computer chess programming I found navigating through Crafty's code easy. It's not only a competitive chess engine, but its code base is a great learning tool to the business of computer chess.

[plattyaj]

What about using MAX_PATH / PATH_MAX (can't remember off the top of my head which one is Windows and which is Unix).

Andy.

[bob]

What about using MAX_PATH / PATH_MAX (can't remember off the top of my head which one is Windows and which is Unix).

Andy.

There is no "MAX_PATH" concept in unix. I have had directories hundreds of levels deep...

[Dann Corbit]

What about using MAX_PATH / PATH_MAX (can't remember off the top of my head which one is Windows and which is Unix).

Andy.

There is no "MAX_PATH" concept in unix. I have had directories hundreds of levels deep...

Every C compiler must include a macro called FILENAME_MAX in stdio.h and this symbol must be the maximum length of a legal file name for that operating system.

ISO/IEC 9899:TC3 Committee Draft — Septermber 7, 2007 WG14/N1256
7.19 Input/output <stdio.h>
FILENAME_MAX
which expands to an integer constant expression that is the size needed for an array of char large enough to hold the longest file name string that the implementation guarantees can be opened; (see footnote 231)

footnote 231) If the implementation imposes no practical limit on the length of file name strings, the value of FILENAME_MAX should instead be the recommended size of an array intended to hold a file name string. Of course, file name string contents are subject to other system-specific constraints; therefore all possible strings of length FILENAME_MAX cannot be expected to be opened successfully.

[plattyaj]

What about using MAX_PATH / PATH_MAX (can't remember off the top of my head which one is Windows and which is Unix).

Andy.

There is no "MAX_PATH" concept in unix. I have had directories hundreds of levels deep...

True to a point. The O/S will let you build a directory structure that deep but it won't let you open it (at least not in one go):

Try this little snippet - it will stop at some point:

Code: Select all

#!/usr/bin/ksh

let COUNT=0

THE_PATH=.

while [ $COUNT -lt 1100 ]; do
   THE_PATH=$THE_PATH/testp
   mkdir $THE_PATH
   if [ $? -eq 1 ]; then
      echo "Stopped at $COUNT"
      exit 0
   fi
   let COUNT=${COUNT}+1
done

On the Linux system I tested that on, MAX_PATH was 4096 and this stopped where COUNT was 682 right where you would expect. But I could cd into that directory and run it again, etc.

Andy.

[bob]

What about using MAX_PATH / PATH_MAX (can't remember off the top of my head which one is Windows and which is Unix).

Andy.

There is no "MAX_PATH" concept in unix. I have had directories hundreds of levels deep...

True to a point. The O/S will let you build a directory structure that deep but it won't let you open it (at least not in one go):

Try this little snippet - it will stop at some point:

Code: Select all

#!/usr/bin/ksh

let COUNT=0

THE_PATH=.

while [ $COUNT -lt 1100 ]; do
   THE_PATH=$THE_PATH/testp
   mkdir $THE_PATH
   if [ $? -eq 1 ]; then
      echo "Stopped at $COUNT"
      exit 0
   fi
   let COUNT=${COUNT}+1
done

On the Linux system I tested that on, MAX_PATH was 4096 and this stopped where COUNT was 682 right where you would expect. But I could cd into that directory and run it again, etc.

Andy.

The question is, is that a korn shell limit, since it is building the path/filename internally? There must be a limit, but I have not run across one in actual practice... But then no sane person has directories 20 levels deep in the first place, that is simply a good way to lose files by forgetting where they are.