Re: warnings important?



"Koen D'Hondt" <ripley@xs4all.nl> writes:
> Michael Harnois wrote:
> >     Raja R Harinath wrote:
> >     > I'm not sure about this.  I expect `XmHTMLfuncs.h' to define an
> >     > useful `strdup', but why does it define it in the first place?
> >     > I don't think this warning needs alarm us too much, though.
> > 
> > Here is the relevant code from the include file:
> > 
> I guess this was coming from the string2.h include. XmHTML (motif
> version) can redefine strdup in three different ways, all depending on
> the compilation flags. I don't know exactly what's the case in
> gtk-xmhtml, but's here what's being done for the motif version:
> 
> clean build: define strdup to XtNewString (strdup with error checking);
> debug build: define strdup to some internal function, with error
> checking;
> dmalloc build: dmalloc provides it's own macro.
[snip]
> In the end, what you loose is the inlined function, and what you get
> back is a program checks *every* strdup and tells you what went wrong
> before exiting instead of trashing everything without a warning when
> strdup fails. If you don't like this, you can simply remove the strdup
> define(s), but be warned that XmHTML assumes that when strdup returns,
> it always assumes that the returned memory is valid.

This is, IMHO, going against the principle of least surprise.  It would
have been nicer if you used something like XmStrDup or some other name
for the error-checked strdup.

Currently, you can get into trouble if you included headers in the wrong
order.  The right order is

	#include <string.h>
	#include <XmHTMLfuncs.h>

But, this'll cause warnings as above.  The other order could cause
strange errors inside <string.h> where strdup may be subsequently
declared, since the #define in XmHTMLfuncs.h could screw up that
declaration.  Even worse, the compile could succeed but use a
non-checking `strdup' -- occassionally causing unexplained SIGSEGVs &c.

My thoughts are:

	1. Use a wrapper, like XmStrDup.  You are changing the semantics
           of strdup -- so change the name too.

	2. At least prevent dependencies on order, and avoid warnings in
           the case above.

	   XmHTMLfuncs.h could look something like:

		/* Preempt ordering problems, by turning subsequent
		   occurances of `#include <string.h>' into no-ops.  */
		#include <string.h>
		...
		#undef strdup       /* <string.h> may #define this.  */
		#define strdup ...
	  
	   This'll work for both orders of inclusion of <string.h> and
	   XmHTMLfuncs.h.  Also, it'll prevent warnings.

I prefer (1), but (2) should be much better than the current situation.

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash



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