Re: patch: contrib/pgcrypto sanity - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: patch: contrib/pgcrypto sanity
Date
Msg-id 20010108040608.A5917@l-t.ee
Whole thread Raw
In response to Re: patch: contrib/pgcrypto sanity  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: patch: contrib/pgcrypto sanity
List pgsql-hackers
On Sun, Jan 07, 2001 at 08:09:07PM -0500, Tom Lane wrote:
> Marko Kreen <marko@l-t.ee> writes:
> > date: 2000/12/04 01:20:38;  author: tgl;  state: Exp;  lines: +18 -18
> > Eliminate some of the more blatant platform-dependencies ... it
> > builds here now, anyway ...
> 
> > Which basically changes u_int*_t -> uint*_t, so now it does not
> > compile neither under Debian 2.2 nor under NetBSD 1.5 which
> > is platform independent¸ all right.
> 
> Well, that's annoying.  I guess those platforms are out of step with the
> C99 standard, which specifies uint*_t not u_int*_t (cf. C99 7.4.1.1).
> I agree with your solution of switching to Postgres-supplied typenames.

Well, actually they do.  glibc in <stdint.h> and NetBSD in
<sys/inttypes.h> which is a mess, all rigth.  Problem is that
postgres.h does not know about this.  I guess that C99 forgot
to specify _where_ they should be defined.

But the point is, what are the standard types in PostgreSQL?  C99
ones are not, because there would be lots of noise raised
already.  If you think that the C99 should be standard someday,
then postgres.h should also provide them, because older
platforms definitely do not provide them.

> > Also it replaces $KAME$ with $Id$ which is Bad Thing. PostgreSQL Id
> > should be added as a separate line so the file history could be seen.
> 
> I didn't know what $KAME$ was, and took it for some national-language
> variant of $Id$ that our CVS server didn't know about.  Who/what is
> KAME anyway?

KAME is the project that provides IPv6 to all the free BSD's.
(www.kame.net)

> > * adds back KAME Id, because KAME is the master repository
> 
> Is that a good idea?  If we are deliberately deviating from whatever
> "master repository" this is, I'm not sure that we should continue to
> label the code with their revision ID.

I think it is.  I think they are more competent on maintaining
crypto than PostgreSQL team (at least they devote more time on
it).  This makes tracking changes easier.  This (special Id's)
are widely used practice in BSD's, this makes clear whether a
file is 'original' or 'imported'; and from where.


-- 
marko



pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: ALL, ANY bug?
Next
From: Tom Lane
Date:
Subject: Re: ALL, ANY bug?