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;
>>
>
>
--
Manuel Mayr, Dipl. Inf.
Institut fuer Informatik, TU Muenchen
Tel.: +49 89 289-17259
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Monetdb-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-developers
