search for: fildes

While building FSF gcc 5.1 against Apple's public Xcode 7 beta's new clang-based assembler, I ran into rejected assembly instructions during the -m32 multilb build of libjava. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66509 With assembler errors of the form... natArray.s:1110:2: error: ambiguous instructions require an explicit suffix (could be 'filds', or 'fildl')

...; if ((uintptr_t) o->pr_vaddr >= vaddr + size) j = m; else if ((uintptr_t) o->pr_vaddr + o->pr_size <= vaddr) i = m + 1; else return 1; } return 0; } static void *safe_mmap (void *addr, size_t len, int prot, int flags, int fildes, off_t off) { if (flags & MAP_FIXED) return mmap (addr, len, prot, flags, fildes, off); else { int stat = 0; pid_t pid; int fd; struct stat sb; prmap_t *asmap; void *actual_addr; assert ((fd = open ("/proc/self/rmap", O_RDONLY)) != -1); if ((...

...buf argument is a pointer to a char or unsigned char (or any other element for that matter) if we specify the size_t of the object anyway (so there can't be any doubt about its size). My proposal is to use 'void *buf', in the same way as the read() and write() prototypes do: read(int fildes, void *buf, size_t nbyte); write(int fildes, const void *buf, size_t nbyte); Where typecasting is unavoidable (for instance, if we need to read/write the buffer one character at a time) this can be done in the respective ser_* functions. Bottomline is, as long as you pass these functions the leng...

...if (TYPEOF(what) != RAWSXP) (gdb) n 688 R_xlen_t len = XLENGTH(what); (gdb) n 689 unsigned char *b = RAW(what); (gdb) n 693 if (writerep(master_fd, &len, sizeof(len)) != sizeof(len)) { (gdb) info locals len = 538 b = <optimized out> n = <optimized out> (gdb) s writerep (fildes=6, buf=buf at entry=0x7ffdd6da7db0, nbyte=nbyte at entry=8) at fork.c:653 653 { (gdb) info args fildes = 6 buf = 0x7ffdd6da7db0 nbyte = 8 (gdb) n 654 size_t wbyte = 0; (gdb) n 653 { (gdb) n 657 ssize_t w = write(fildes, ptr + wbyte, nbyte - wbyte); (gdb) n 658 if (w == -1) { (gdb) n 657...

...n_t len = XLENGTH(what); > (gdb) n > 689 unsigned char *b = RAW(what); > (gdb) n > 693 if (writerep(master_fd, &len, sizeof(len)) != sizeof(len)) { > (gdb) info locals > len = 538 > b = <optimized out> > n = <optimized out> > (gdb) s > writerep (fildes=6, buf=buf at entry=0x7ffdd6da7db0, nbyte=nbyte at entry=8) > at fork.c:653 > 653 { > (gdb) info args > fildes = 6 > buf = 0x7ffdd6da7db0 > nbyte = 8 > (gdb) n > 654 size_t wbyte = 0; > (gdb) n > 653 { > (gdb) n > 657 ssize_t w = write(fildes, ptr + wby...

Hi, in the last weeks I've unsuccessfully tried to get Samba (2.0.5a) - Unix (Suse 6.2) password sync working. Maybe somebody can give me a hint, what's wrong. Enclosed you'll find additional information. Thank you for helping, Johannes -------- smb.conf: passwd chat = *password* %n\n *password* %n\n *Password* -------- password chat (manually): homer:~ # /bin/passwd web New

...W(what); >>> (gdb) n >>> 693 if (writerep(master_fd, &len, sizeof(len)) !=3D sizeof(len)) { >>> (gdb) info locals >>> len =3D 538 >>> b =3D <optimized out> >>> n =3D <optimized out> >>> (gdb) s >>> writerep (fildes=3D6, buf=3Dbuf at entry=3D0x7ffdd6da7db0, nbyte=3Dnbyte at e= >> ntry=3D8) >>> at fork.c:653 >>> 653 { >>> (gdb) info args >>> fildes =3D 6 >>> buf =3D 0x7ffdd6da7db0 >>> nbyte =3D 8 >>> (gdb) n >>> 654 size_t wb...

...W(what); >>> (gdb) n >>> 693 if (writerep(master_fd, &len, sizeof(len)) !=3D sizeof(len)) { >>> (gdb) info locals >>> len =3D 538 >>> b =3D <optimized out> >>> n =3D <optimized out> >>> (gdb) s >>> writerep (fildes=3D6, buf=3Dbuf at entry=3D0x7ffdd6da7db0, nbyte=3Dnbyte at e= >> ntry=3D8) >>> at fork.c:653 >>> 653 { >>> (gdb) info args >>> fildes =3D 6 >>> buf =3D 0x7ffdd6da7db0 >>> nbyte =3D 8 >>> (gdb) n >>> 654 size_t wb...

Hi Andreas, the error is reported when some child process cannot send results to the master process, which originates from an error returned by write() - when write() returns -1 or 0. The logic around the writing has not changed since R 3.5.2. It should not be related to the printing in the child, only to returning the value. The problem may be originating from the execution environment,

I've just updated from 1.0.14 to 1.1.1 (Maildirs). According to <URL:http://wiki.dovecot.org/Upgrading/1.1>, "dovecot-uidlist file is in a new format. The old format is automatically converted to new one." When I try to delete a message (which moves it to the IMAP Trash folder), I get the following looping sequence of errors until I cancel the delete operation in the mail

...r revoking any open file descriptors, when the session process is alive or dead at the time that the master is closed. This can be determined experimentally. Ideally closing the pty master after the pty slave's session leader has exited will cause the pty slave driver to revoke open fildes referring to it *and* to send HUP/CONT to remaining process groups with that pty slave association. My tests indicate that closing the master pty, on Solaris, does not cause the slave pty open fildeses to be revoked and not signal is sent, so orphaned background process groups continue...

This is version 4 of the following sub-series: [libnbd PATCH v3 06/29] lib/utils: introduce xwrite() as a more robust write() [libnbd PATCH v3 07/29] lib/utils: add async-signal-safe assert() [libnbd PATCH v3 08/29] lib/utils: add unit test for async-signal-safe assert() http://mid.mail-archive.com/20230215141158.2426855-7-lersek at redhat.com

The hang on exit has become quite an issue in my organization(Sun and HP hosts). I see this note in the changelog which indicates that there will not be a fix for this problem: 20001129 - (djm) Back out all the serverloop.c hacks. sshd will now hang again if there are background children with open fds. Also, I am aware of the workaround as noted in the FAQ. However this workaround is not

Hey Guys, I want to transition from Merak to Postfix/Dovecot. I am not sure how to begin. I have been reading the different Howtos - cocktail of services to Postfix like ClamAV, Spamassissin, Greylisting, Jamm, SquirrelMail. The thing is that I want stable IMAP mail. Here is what I want to do: a. Stand alone linux box for email only - 25 users b. provide IMAP and web c. provide SSL

...on: fcntl_lock(shared_fd,SMB_F_SETLKW,0,1,F_WRLCK) fcntl_lock calls: fcntl(8191, F_SETLKW) which sets errno = 22 (EINVAL). The only thing I could find about this error number on this command is: "cmd is F_GETLK, F_SETLK, or F_SETLKW, and arg.lockdes or the data it points to is not valid,or fildes refers to a file that does not support locking." Does anyone know how I can fix this (or some more hints on how to debug it)? Thanks, Christian _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.c...

Hi everyone, We are trying to port our own windows application to SUSE linux.Our application uses SetFilePerm() api defined in commondll.dll.We would like to know whether there is a linux equivalent of windows commondll.dll in wine... If not then what could be the possible alternative to make this api function exactly as it does in windows. Waiting for an early reply, Thanks and Regards,

Hmm, maybe sse isn't being enabled so its falling back to emulating sqrt? On Thu, Jul 18, 2013 at 10:45 PM, Peter Newman <peter at uformia.com> wrote: > In the disassembly, I'm seeing three cases of > call 76719BA1 > > I am assuming this is the sqrt function as this is the only function > called in the LLVM IR. > > The code at 76719BA1 is: > >

In the disassembly, I'm seeing three cases of call 76719BA1 I am assuming this is the sqrt function as this is the only function called in the LLVM IR. The code at 76719BA1 is: 76719BA1 push ebp 76719BA2 mov ebp,esp 76719BA4 sub esp,20h 76719BA7 and esp,0FFFFFFF0h 76719BAA fld st(0) 76719BAC fst dword ptr [esp+18h] 76719BB0 fistp

Can someone find an OS where the attached program doesn't work? It should print "success". So far tested for success: Linux 2.6, Solaris 10, FreeBSD 7.2, OpenBSD 4.2. -------------- next part -------------- A non-text attachment was scrubbed... Name: test.c Type: text/x-csrc Size: 1100 bytes Desc: not available URL:

G''Day Folks, I''ve found another use of dtrace, this makes your console keyboard sound like a typewriter. http://www.brendangregg.com/DTrace/typewriter-0.70.tar.gz I''ve only tested it on an UltraSPARC 5 and a Pentium laptop so far, more to follow. Ok, sorry, not actually a practical use of DTrace. :) Enjoy! Brendan [Sydney, Australia]