re: CVS commit: src/usr.bin/make
> Not much point writing an error is you'vejust failed to write to stderr! i disagree -- ktrace sees it and thus it is not entirely lost :)
Re: CVS commit: src/lib/libc/arch/arm/softfloat
"Matt Thomas" writes: > Module Name: src > Committed By: matt > Date: Sat Jan 26 07:08:14 UTC 2013 > > Modified Files: > src/lib/libc/arch/arm/softfloat: arm-gcc.h > > Log Message: > Appease clang by making 64-bit literals use ULL > > > To generate a diff of this commit: > cvs rdiff -u -r1.3 -r1.4 src/lib/libc/arch/arm/softfloat/arm-gcc.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > > > Modified files: > > > Index: src/lib/libc/arch/arm/softfloat/arm-gcc.h > diff -u src/lib/libc/arch/arm/softfloat/arm-gcc.h:1.3 > src/lib/libc/arch/arm/softfloat/arm-gcc.h:1.4 > --- src/lib/libc/arch/arm/softfloat/arm-gcc.h:1.3 Sat Dec 24 21:11:16 2005 > +++ src/lib/libc/arch/arm/softfloat/arm-gcc.h Sat Jan 26 07:08:14 2013 > @@ -1,4 +1,4 @@ > -/* $NetBSD: arm-gcc.h,v 1.3 2005/12/24 21:11:16 perry Exp $ */ > +/* $NetBSD: arm-gcc.h,v 1.4 2013/01/26 07:08:14 matt Exp $ */ > > /* > > --- > @@ -71,7 +71,7 @@ name for the 64-bit integer type. Some > defined as the identity macro: `#define LIT64( a ) a'. > > --- > */ > -#define LIT64( a ) a##LL > +#define LIT64( a ) a##ULL > #endif That's a bit strange. Don't we have UINT64_C for this? Or is too early for UINT64_C to be defined? -- HE CE3OH...
Re: CVS commit: src/usr.bin/make
In article <20130126205325.gd28...@snowdrop.l8s.co.uk>,
David Laight wrote:
>I'd have been tempted to do:
>
>int stupid_glibc_wont_let_us_ignore_the_result_of_write(int fd, const
>void *buf, size_t len)
>{
> return write(fd, buf, len);
>}
It is the linux headers :-)
>I'm not sure, but I think that read/write can only return EAGAIN if they
>are blocking, have transferred no data, and take a signal that is
>restartable.
The other way around O_NONBLOCK reads and writes can return EAGAIN on
non-files.
>If they have transferred some data they they have to return a partial count.
But if they are empty(read) or full(write) and non-blocking they have to
return EAGAIN (or the old EWOULDBLOCK).
>So if you care about the result you have to do far more than loop
>for EAGAIN - adding such a loop is a bogus fix.
If they are non blocking it is correct; if they are blocking it is a noop.
>Not much point writing an error is you'vejust failed to write to stderr!
correct.
christos
Re: CVS commit: src/usr.bin/make
On Sat, Jan 26, 2013 at 10:53:00AM -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sat Jan 26 15:53:00 UTC 2013
>
> Modified Files:
> src/usr.bin/make: job.c main.c
>
> Log Message:
> Check read and write errors to avoid warnings from linux.
> XXX: Should we print an error and exit instead?
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.164 -r1.165 src/usr.bin/make/job.c
> cvs rdiff -u -r1.204 -r1.205 src/usr.bin/make/main.c
I'd have been tempted to do:
int stupid_glibc_wont_let_us_ignore_the_result_of_write(int fd, const void
*buf, size_t len)
{
return write(fd, buf, len);
}
#define write(fd, buf,len)
stupid_glibc_wont_let_us_ignore_the_result_of_write(fd, buf, len)
Certainly the accesses to the pipes are very boring.
The read(childExitJob.inPipe, ...) definitely doesn't need checking at all.
The writes to it are NON_BLOCK (I think) - it is only used to wake from
poll() - the read is there to clear POLLIN.
The job token pipe is slightly more interesting - but it will only be full
if you try to do more jobs than the pipe size - and then you need to discard
a job token, not block.
I'm not sure, but I think that read/write can only return EAGAIN if they
are blocking, have transferred no data, and take a signal that is
restartable.
If they have transferred some data they they have to return a partial count.
So if you care about the result you have to do far more than loop
for EAGAIN - adding such a loop is a bogus fix.
Not much point writing an error is you'vejust failed to write to stderr!
David
--
David Laight: da...@l8s.co.uk
Re: CVS commit: src/lib/libterminfo
On Fri, Jan 25, 2013 at 04:06:09PM -0700, Warner Losh wrote: > > On Jan 25, 2013, at 4:05 PM, David Laight wrote: > > >> Log Message: > >> For platforms where we cannot fit a char * into a long, return NULL > >> and set errno to ENOTSUPP. > > > > Could the 'char *' pointers be replaced with indexes into an array? > > How many platforms is this actually the case on? 64bit windows :-) David -- David Laight: da...@l8s.co.uk
