Re: [PATCH 03/19] write: stop using MAXHOSTNAMELEN

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: Text/Plain, Size: 3108 bytes --]

On Thursday 18 October 2012 16:06:28 Sami Kerola wrote:
> On Mon, Oct 15, 2012 at 3:14 AM, Mike Frysinger wrote:
> > On Sunday 14 October 2012 16:20:59 Sami Kerola wrote:
> >> POSIX.1-2001 declares usleep is obsolete.
> > 
> > this is true, but it seems like a better answer would be to add a
> > usleep test to configure and provide a local fallback using nanosleep
> > if it doesn't exist.
> 
> Is that necessary?  There has been for example in old mount since March
> 2007[1] nanosleep() call, and I cannot remember anyone complaining it
> causing problems.
> 
> [1] commit dc8fdc57cd3ba0658cf4ab05031695c2d2965f93

i think you misinterpreted my objection.  i don't have a problem with calling 
nanosleep() -- when it makes sense.  replacing a simple call to a function 
that, while no longer part of the latest standard, was mandated for many many 
years, and will most likely never be removed from C libraries that have 
already been providing it (since it'd be an ABI break), with a more 
complicated call for no real reason is pointless imo.  further, you'd be 
fighting a losing battle: developers will most likely be working & testing on a 
glibc system where usleep does exist and works fine, so they won't notice if it 
were added again.

hence i suggested a trivial middle ground that is future proof and doesn't 
penalize systems that do include usleep (i.e. glibc i.e. what the majority of 
people run): if you actually have a system that lacks usleep, then add usleep 
to the AC_CHECK_FUNCS tests in configure.ac, and then add the simple 
replacement to include/c.h:
#ifndef HAVE_USLEEP
static inline int usleep(useconds_t usec)
{
	struct timespec waittime;
	waittime.tv_sec = usec / 1000000L;
	waittime.tv_nsec =  (usec % 1000000L) * 1000;
	return nanosleep(&waittime, NULL);
}
#endif

now everything should "just work".

> On Mon, Oct 15, 2012 at 6:39 PM, Mike Frysinger wrote:
> > On Monday 15 October 2012 04:36:43 Sami Kerola wrote:
> >> On Mon, Oct 15, 2012 at 3:17 AM, Mike Frysinger wrote:
> >> > On Sunday 14 October 2012 16:21:10 Sami Kerola wrote:
> >> >> +     if (utimensat(path, &epoch, 0) < 0)
> >> > 
> >> > err, did you test this at all ?  utimensat() takes 4 args one of
> >> > which is
> >> > a reference file descriptor.
> >> 
> >> I thought I did, but what ever I did where partly unsuccessful.
> > 
> > cramfs isn't built by default, so you'll need to pass the right
> > configure flag
> 
> *sigh* I see.  And I dropped the patch.
> 
> I wonder if anyone is ever reaching code that requires INCLUDE_FS_TESTS
> defined.  Should there be a configure --enable-fs-crams-tests switch?  If
> that sort of switch is added it should perhaps be included when
> --enable-most-builds is set.  Comments, opinions?

i would add a new check target to disk-utils/Makemodule.am

check_PROGRAMS += test_mkfs.cramfs
test_mkfs_cramfs_SOURCES = $(mkfs_cramfs_SOURCES)
test_mkfs_cramfs_LDADD = $(mkfs_cramfs_LDADD)
test_mkfs_cramfs_CFLAGS = -DINCLUDE_FS_TESTS

then see what happens when you run `make check` ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]