|
From: Rich C. <rc...@wi...> - 2012-12-13 04:31:57
|
This patch worked.
Rich
On Wed, 12 Dec 2012 13:28:32 +0100
Mark Wielaard <mj...@re...> wrote:
> On Wed, 2012-12-12 at 20:31 +0900, Dave Goodell wrote:
> > On Dec 12, 2012, at 6:56 PM GMT+09:00, Mark Wielaard wrote:
> > > Makes sense. New patch attached. Obviously all variants work fine on my
> > > setup. If someone could test on a problematic one that would be
> > > appreciated.
> >
> > I don't have easy access to a 10.6 or earlier machine with which to check this, sorry.
>
> Hopefully someone else can, otherwise we should just move things under
> memcheck/tests/linux and be done with it I guess.
>
> > I don't feel strongly on this issue, but it's a great way to get
> > burned in the future when the autoconf maintainers start using this
> > variable for some random reason. You have correct m4 quoting in your
> > patch, which is better than most cargo-cult autoconf fragments, so I
> > assumed that you might be interested in following other best practices
> > in this regard.
>
> I certainly do see your point. But I don't feel my auto* foo is strong
> enough to fix all these issues in configure.in with this patch. And I do
> think it is better to have all test be as similar as possible to each
> other for now. But yeah, one day there will be problems :{ If just
> because valgrind still has a configure.in, which will soon be dropped
> because it has been deprecated for so long in favor of configure.ac:
> https://lists.gnu.org/archive/html/autotools-announce/2012-11/msg00000.html
> So if there is someone with strong auto* foo I am sure some cleanups
> here will be appreciated.
>
> > >> You may also wish to include a note that this HAVE_STPNCPY is
> > >> only valid in conjunction with "#define _GNU_SOURCE".
> > >
> > > But that turned out not to be true. The original didn't have it, and
> > > apparently different "non-GNU" systems do have strpncpy.
> >
> > But your configure test explicitly defines "_GNU_SOURCE" in the test.
> > So clients of HAVE_STPNCPY can only rely on its accuracy if they also
> > define _GNU_SOURCE. I am not referring to any particular system
> > having or not having the routine, nor directly the influence of
> > _GNU_SOURCE on any particular system. Only that the test only checks
> > for strncpy's existence in the presence of _GNU_SOURCE.
> >
> > This usually does not matter now, but 4 years down the road when
> > someone else wants to gate on this #define and does not realize the
> > subtle _GNU_SOURCE requirement. HAVE_X always seems like such a
> > simple truth that it's easy to trust too much unless caveats are
> > present in the name or the comments :)
>
> So, new version of the patch. This time with comment and tweaked HAVE_
> to make thing totally clear attached.
>
> Cheers,
>
> Mark
--
Rich Coe rc...@wi...
|