Hi Stefan, thank you for noting that and for your suggestions. Actually this is only an afternoon hack started by Jens and extended by myself. It was never meant to be published. Currently I'm busy to clean the code and until I've done that, I try to fix the compiler errors I get by the Testweb.

Btw, since ssize_t has different definitions on different platforms, which format-string should be used for this.

Regards, Manuel

Stefan Manegold wrote:

On Sun, Sep 09, 2007 at 08:27:41AM +0000, Manuel Mayr wrote:

...

Update of /cvsroot/monetdb/pathfinder/src/sqlhelpers/xmlshred In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv17315

Modified Files: xmlshred.c Log Message:

Fixing compiler errors.

Index: xmlshred.c

RCS file: /cvsroot/monetdb/pathfinder/src/sqlhelpers/xmlshred/xmlshred.c,v retrieving revision 1.1 retrieving revision 1.2 diff -u -d -r1.1 -r1.2 --- xmlshred.c 8 Sep 2007 08:39:59 -0000 1.1 +++ xmlshred.c 9 Sep 2007 08:27:39 -0000 1.2 @@ -51,7 +51,8 @@

#define NAME_ID 0

-typedef long int nat; +typedef long unsigned int nat; +typedef int pre_t;

What's the reason for introducing yet another type, here? Should "nat" be 32-bit on 32-bit systems and 64-bit on 64-bit systems?

Well, that won't work for Windows: x64 Windows uses the P64 model, i.e., "int" and "long int" are 32 bits long, but pointers are 64 bits long. x86-64 Linux uses the LP64 model, when "long int" is also 64 bits while "int" remains 32 bits. In contrast, 32-bit Windows and Linux are both ILP32, meaning that "int", "long int" and pointers are all 32 bits.

Hence, "long int" is a considered "evil" and a "portability killer".

Why not use standard types "size_t" (unsigned) and "ssize_t" (signed) if you need a system word-size integer?

In fact, "*pre*" and "*post*" --- assuming the names suggest that they represent pre- & post-orders --- are actually of type "oid" in the remainder of the pathfinder (MonetDB/XQUuery) code base (enabling 32-bit space-saving pre/post storage also on 64-bit systems); likiwise, "size" is "int" and "level" is "chr". Is there any reason not to use the same, here?

Stefan

...

enum kind_t { elem @@ -133,17 +134,17 @@ void free_hash(bucket_t **hash_table);

/* return a brand new name_id */ -int new_nameid(); +int new_nameid(void);

typedef struct node_t node_t; struct node_t {

• nat pre;
• nat apre;

• pre_t pre;
• pre_t apre; nat post; nat pre_stretched; nat post_stretched; nat size;

• int level;

• unsigned int level; int name_id; node_t *parent; kind_t kind;