Thread: contrib/intarray/_int_gist.c
In "g_int_compress" : int *dr; ...memmove((void *) &dr[cand - 1], (void *) &dr[cand + 1], (len - cand - 1) * sizeof(int)); Should be int32 *dr; ...memmove((void *) &dr[cand - 1], (void *) &dr[cand + 1], (len - cand - 1) * sizeof(int32));
<jw.pgsql@sduept.com> wrote > In "g_int_compress" : > > > int *dr; > ... > memmove((void *) &dr[cand - 1], (void *) &dr[cand + 1], (len - cand - > 1) * sizeof(int)); > > Should be > > int32 *dr; > ... > memmove((void *) &dr[cand - 1], (void *) &dr[cand + 1], (len - cand - > 1) * sizeof(int32)); > AFAICS, int32 and int are exactly the same thing in PostgreSQL. For the machine int is not 32 bits long, PostgreSQL won't even run. Regards, Qingqing
"Qingqing Zhou" <zhouqq@cs.toronto.edu> writes: > AFAICS, int32 and int are exactly the same thing in PostgreSQL. For the > machine int is not 32 bits long, PostgreSQL won't even run. Ideally we should operate correctly if "int" is 64 bits. In practice I agree that making contrib work would be mighty far down the list of things to fix... It appears to me that the current de-facto standard for C on 64-bit machines is char 8 bits short 16 bits int 32 bits long 64 bits Promoting "int" to 64 bits has a big problem: you have to drop one of the widths entirely, because there is no other basic type allowed by C. (int16_t and the others are only typedefs not new basic types.) So I'm not really expecting to see int = 64 bits any time soon. As for the other direction (int = 16 bits), there's no real hope of running Postgres on a 16-bit machine anyway :-( regards, tom lane
Tom Lane wrote: > "Qingqing Zhou" <zhouqq@cs.toronto.edu> writes: > > AFAICS, int32 and int are exactly the same thing in PostgreSQL. For the > > machine int is not 32 bits long, PostgreSQL won't even run. > > Ideally we should operate correctly if "int" is 64 bits. In practice > I agree that making contrib work would be mighty far down the list of > things to fix... > > It appears to me that the current de-facto standard for C on 64-bit > machines is > char 8 bits > short 16 bits > int 32 bits > long 64 bits > Promoting "int" to 64 bits has a big problem: you have to drop one of > the widths entirely, because there is no other basic type allowed by > C. (int16_t and the others are only typedefs not new basic types.) > So I'm not really expecting to see int = 64 bits any time soon. > > As for the other direction (int = 16 bits), there's no real hope of > running Postgres on a 16-bit machine anyway :-( Agreed. CVS change made for clarity, int->int32. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +