Re: [xml] Error in the Tutorial

[Igor Zlatkovic <igor zlatkovic com>]

On 27.05.2004 13:17, Raymond Wiker wrote:

>         I think you'd need a combination of high(ish) warning level
> and compiler/system that treats chars as signed to get problems. In
> any case, the correct solution is (as you say) to cast to xmlChar *. I
> have definitely had to add such casts to placate the compiler on one
> or more platforms.

I have a platform where chars are signed per default and I have used the 
highest possible warning level. But I have been too fast with my 
judgement, I was wrong.

That line 37 is assigning a pointer to a pointer. One side points to an 
unsigned char, the other to a first element of a constant char array. 
Types pointed to are not the same, but an implicit cast should fit into 
the type strength of the C language because
sizeof(unsigned char) == sizeof(const signed char).

But then it came to me that Michael could have used a C++ compiler. In 
C++ the line 37 should emit an error. C++ is more strongly typed and has 
less implicit casts than C. Indeed, if I tell these compilers to treat 
the code as C++,

Microsoft's Visual C++ compiler doesn't let this pass:

  C:\Temp>cl -Ic:\opt\fsw\include -TP -W4 -c xpathex.c
  xpathex.c
  xpathex.c(37) : error C2440: 'initializing' : cannot convert from
   'const char [10]' to 'xmlChar *' Types pointed to are unrelated;
   conversion requires reinterpret_cast, C-style cast or
   function-style cast

GNU C++ compiler thinks the same about it (this now looks like Michael's 
output):

  C:\Temp>gcc -Ic:\opt\fsw\include -xc++ -Wall -c xpathex.c
  xpathex.c: In function `int main(int, char**)':
  xpathex.c:37: invalid conversion from `const char*' to `xmlChar*'

Intel's C++ compiler allows an implicit cast, but it clearly states what 
it thinks about it:

  C:\Temp>icl -Ic:\opt\fsw\include -TP -W4 -c xpathex.c
   xpathex.c
   xpathex.c(37): warning #144: a value of type "const char *" cannot
    be used to initialize an entity of type "xmlChar={unsigned char}*"
    xmlChar *xpath = ("//keyword");
                      ^

So I take it back, John, this should be fixed and not left the way it 
is. Of course fixed by casting, not by duplicating the string.

Ciao,
Igor