bug-ocrad
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-ocrad] Some compatibility issues


From: Antonio Diaz Diaz
Subject: Re: [Bug-ocrad] Some compatibility issues
Date: Fri, 07 Oct 2005 17:52:03 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7.3) Gecko/20040913

Hello Elmar. Thanks for your interest in Ocrad.

Elmar Plischke wrote:
I've just compiled ocrad under SUN/Solaris using the native compiler.
 However, there are some minor issues to report:

configure/Makefile combo does not respect the CXX and CXXFLAGS environment variables. Maybe it's time to use some autoconf-magic.

GNU Ocrad does not use Autoconf or Automake, nor uses any environment
variable, nor defines any macro, nor uses conditional compilation. Any data necessary to build Ocrad on a non-GNU system should be passed to configure in the command line.

Ocrad is an OCR program. It is not a build system nor a package manager. I won't bloat Ocrad with configuration code. Any user unable to compile Ocrad should use a precompiled binary for his distro or system.


The lines
void ...error( const char * msg ) throw() __attribute__ ((noreturn));
in common.h, rectangle.cc and track.cc should be protected by an #ifdef _GNUC__/#endif pair

I use what I need and GCC offers. It is a problem of standards or compilers, not a problem of Ocrad.


In main.cc, note that <getopt.h>, getopt_long() are GNU, the standard
 lib offers only an interface via
int getopt(int argc, char * const *argv,  const  char  *opt- string);
 extern char *optarg; extern int optind, opterr, optopt;

Ocrad is also GNU and uses GNU features. It is not my fault if people wants to use GNU software on non-GNU systems, nor is my duty to adapt Ocrad to other systems.


One more to go: snprintf() seems to be part of C99, but (Sun) C++ has
no wrapper for it. I circumvented this problem by using a format string with a precision argument, so that the string is truncated by sprintf.

It seems that `snprintf' is not part of the C++ standard, but using `sprintf' makes the programs vulnerable to errors and attacks, so I won't use it. See this from the GLIBC manual:

     *Warning:* The `sprintf' function can be *dangerous* because it
     can potentially output more characters than can fit in the
     allocation size of the string S.  Remember that the field width
     given in a conversion specification is only a _minimum_ value.
     To avoid this problem, you can use `snprintf' or `asprintf',
     described below.


Best regards,
Antonio Diaz.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]