Re: Autoconf version discrepancies
От
Patrick Welche
Тема
Re: Autoconf version discrepancies
Дата
Msg-id
20010118153422.I29761@quartz.newn.cam.ac.uk
Ответ на
Re: Autoconf version discrepancies (The Hermit Hacker)
Список
Дерево обсуждения
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 по дате отправления