Re: Autoconf version discrepancies

Поиск
Список
Период
Сортировка
Искать
От
Patrick Welche
Тема
Re: Autoconf version discrepancies
Дата
Msg-id
20010118153422.I29761@quartz.newn.cam.ac.uk
Ответ на
Список
Дерево обсуждения
Autoconf version discrepancies Peter Eisentraut <peter_e@gmx.net>
Re: Autoconf version discrepancies Bruce Momjian <pgman@candle.pha.pa.us>
Re: Autoconf version discrepancies Peter Eisentraut <peter_e@gmx.net>
Re: Autoconf version discrepancies Bruce Momjian <pgman@candle.pha.pa.us>
Re: Autoconf version discrepancies Vince Vielhaber <vev@michvhf.com>
Re: Autoconf version discrepancies The Hermit Hacker <scrappy@hub.org>
Re: Autoconf version discrepancies Peter Eisentraut <peter_e@gmx.net>
Re: Autoconf version discrepancies Bruce Momjian <pgman@candle.pha.pa.us>
Re: Autoconf version discrepancies Tom Lane <tgl@sss.pgh.pa.us>
Re: Autoconf version discrepancies The Hermit Hacker <scrappy@hub.org>
Re: Autoconf version discrepancies Patrick Welche <prlw1@newn.cam.ac.uk>
Re: Autoconf version discrepancies Matthew Kirkwood <matthew@hairy.beasts.org>
Re: Autoconf version discrepancies The Hermit Hacker <scrappy@hub.org>
On Mon, Oct 09, 2000 at 04:11:20PM -0300, The Hermit Hacker wrote:
> On Sun, 8 Oct 2000, Tom Lane wrote:
... 
> > Also, we not long ago went through the exercise of making sure that all
> > committers were standardized on the same version of Autoconf, ie, 2.13.
> > Now it emerges that hub.org is running a NON STANDARD version of
> > Autoconf: 2.13 + unspecified BSD-originated hacks.  So the output is
> > likely to change depending on who committed last and where they did it
> > from.
> 
... 
> If using mktemp doesn't break any platform, this is a moot point ... if it
> does, then I think it is something that *has* to be fix in the FreeBSD
> port itself so that it doesn't make us look FreeBSD-centric in our
> development efforts on any other package ...

To flog an already dead horse (then again my posts get stalled, so 8 Oct mail
isn't that late :-) (whatever happenend to pgsql-loophole) )

SECURITY CONSIDERATIONS    The use of mktemp() should generally be avoided, as a hostile process can    exploit a race condition in the time between the generation of a tempo-    rary filename by mktemp() and the invoker's use of the temporary name.  A    link-time warning will be issued advising the use of mkstemp() or    mkdtemp() instead.

Cheers,

Patrick

В списке pgsql-hackers по дате отправления
От: Rod Taylor
Дата:
Сообщение: OLD.oid issues...
От: Patrick Welche
Дата:
Сообщение: charset.htm
FAQ