Dne 8.8.2011 17:52, Michal Hocko napsal(a):
On Mon, Aug 08, 2011 at 04:24:55PM +0200, Jozef Misutka wrote:
Dne 8.8.2011 10:48, Michal Hocko napsal(a):
On Mon, Aug 08, 2011 at 10:21:40AM +0200, Jozef Misutka wrote:
Dne 8.8.2011 9:38, Michal Hocko napsal(a):
On Mon, Aug 08, 2011 at 12:54:05AM +0200, Jozef Misutka wrote:
struct pdfedit_core_dev_init should be "smarter" and initialize its
members to default values
Default is - no special values. We inheritted this from xpdf code which
initializes all values from configuration file (which may not exist) or
command line parameters.


struct pdfedit_core_dev_init init;
init.fontDir = ".";

is really tempting but very wrong indeed.
Why do you consider it wrong? pdfedit_core_dev_init calls init_xpdf_core
which in turn uses init->fontDir for global parameters initialization.
because not all members of init are initialised properly
(cfgFileName) - though a crash on some platforms is inevitable.
cfgFileName is allowed to be NULL.
not initialized != NULL
Hey, common. If we get non NULL init then we expect that everything in
pdfedit_core_dev_init is initialized to an usable value (either NULL or
something that makes sense) which is perfectly reasonable expectation
IMO. What do you expect that the core library code would do?

you are talking about assembler/old c style of programming.
now we have objects which should initialize all their member variables.
so at least define a ctor so that your object is always in a defined state  (unless the programmer tries to change it)

struct pdfedit_core_dev_init {
     pdfedit_core_dev_init () : cfgFileName(NULL), fontDir(NULL) {}