On Mon, Mar 28, 2011 at 10:33:19PM +1300, Andrew Turner wrote:
> On Sun, 27 Mar 2011 22:07:30 +0200
> Stefan Farfeleder wrote:
>
> > The C standard specifies that both and shall
> > define WCHAR_MIN and WCHAR_MAX. You cannot simply include
> > from because the f
On Mon, Mar 28, 2011 at 08:36:57AM +1300, Andrew Turner wrote:
> Along with this WCHAR_MIN and WCHAR_MAX are defined both in
> and . I would like to remove the copy from wchar.h
> and add an include to machine/_stdint.h.
>
> Would there be any problems with either of these or is there a better
>
On Fri, Jan 16, 2009 at 10:33:15AM -0800, Nate Eldredge wrote:
> Pop quiz: which of the following statements is correct?
>
> #include
> #include
>
> execl("/bin/sh", "/bin/sh", 0);
> execl("/bin/sh", "/bin/sh", NULL);
None, as NULL is allowed to expand to 0. You have to write
execl("/bin/sh"
On Fri, Jan 16, 2009 at 01:33:38PM +0200, Danny Braniss wrote:
> some facts:
> #include
> int
> main()
> {
> printf("%s\n", strerror(2));
> return 0;
> }
>
> 1- it works fine on i386
> 2- it bombs on amd64
> 3- with a local strerror.c (instead of the one in libc)
>
On Mon, Nov 24, 2008 at 02:12:22AM +0300, Zajcev Evgeny wrote:
>
> Hello there. I just hit into "problem" that built-in sh command type
> outputs to stdout when error occurs. I mean it returns non-0 status,
> but outputs to stdout! I think stderr has been made exactly for such
> purposes and `t
On Thu, May 29, 2008 at 12:04:41AM -0400, John Baldwin wrote:
> On Sunday 25 May 2008 11:45:37 am Stefan Farfeleder wrote:
> > On Sun, May 25, 2008 at 09:06:47AM -0600, John E Hein wrote:
> > > FWIW, it seems bash and sh report line number differently.
> > >
> &g
On Sun, May 25, 2008 at 09:06:47AM -0600, John E Hein wrote:
> FWIW, it seems bash and sh report line number differently.
>
> # grep -n ^ ~/tmp/ln
> 1:#!/bin/sh
> 2:echo f line: $LINENO
> 3:f()
> 4:{
> 5:echo f line: $LINENO
> 6:}
> 7:
> 8:f
> 9:echo main line: $LINENO
> 10:f
>
>
> # /bin/sh ~/t
On Fri, May 16, 2008 at 10:11:43AM -0400, Mike Meyer wrote:
> On Fri, 16 May 2008 09:44:33 +0200
> Stefan Farfeleder <[EMAIL PROTECTED]> wrote:
>
> > On Sun, Mar 09, 2008 at 03:27:12PM -0400, Mike Meyer wrote:
> > > I've stumbled on to an obscure problem with au
On Sun, Mar 09, 2008 at 03:27:12PM -0400, Mike Meyer wrote:
> I've stumbled on to an obscure problem with autoconf 2.61, and I'm not
> sure quite what to do with it. I've already sent mail to the autoconf
> folks, but I'd like to understand what's going on.
>
> The problem is that, on a FreeBSD sy
On Tue, Apr 03, 2007 at 08:22:15PM +0300, Andriy Gapon wrote:
>
> $ cat test_shl.c
> #include
> #include
>
> int main()
> {
> uint64_t l;
>
> l = 0;
> l--;
> printf("%.16lX\n", l);
> l <<= 64;
> printf("%.16lX\n", l);
> return 0;
> }
>
>
On Tue, Dec 12, 2006 at 05:03:24PM -0800, Kevin Sanders wrote:
> On 12/12/06, Joerg Sonnenberger <[EMAIL PROTECTED]> wrote:
> >On Tue, Dec 12, 2006 at 02:30:41PM -0800, Kevin Sanders wrote:
> >> I'm trying to use KASSERT in my own kernel module and I can't get it
> >> to assert even with a KASSERT(
On Wed, Jun 28, 2006 at 08:10:45PM +0200, Andre Albsmeier wrote:
> There is a nice extension for firefox called prefbar. However,
> newer versions of prefbar (>=3.3) make firefox die with SIGSEGV,
> see http://bugzilla.mozdev.org/show_bug.cgi?id=13809 for details.
> The crash happens in libgklayout
On Sat, Feb 18, 2006 at 06:21:52PM +0100, [EMAIL PROTECTED] wrote:
> On Sat, Feb 18, 2006 at 06:17:18PM +0100, Divacky Roman wrote:
> > execl("/bin/ls", NULL);
>
> This is wrong. You must specify arg0 != NULL (POSIX says so) and you
> must NULL-terminate the *following* list.
>
> E.g.:
>
On Fri, Jan 06, 2006 at 05:57:17PM -0800, Doug Barton wrote:
> Sam Lawrance wrote:
>
> >It's already mentioned at the end of the list of formats.
>
> Hrrm, so it is. Arguably it should be mentioned at the start, since it's
> easy to miss where it is (I certainly missed it, as did others).
If yo
On Tue, Dec 13, 2005 at 07:36:10PM +0100, Hans Petter Selasky wrote:
> Hi,
>
> What do you think about defining the following macros like this:
>
> #ifndef NOT
> #define NOT(arg) _NOT(YES arg(() NO))
> #define _NOT(args...) args
> #endif
If you're interested in standards conforming code
On Tue, Nov 22, 2005 at 08:32:10PM -0800, Daniel Rudy wrote:
>
> Ok, I'va got a little question here. In the structure
> getdirentries_args, there seems to be duplicated fields that I'm not
> entirely sure what they do. Here's the definition of a structure
> verbatim from sys/sysproto.h:
>
> st
On Tue, Jul 26, 2005 at 06:46:55PM -0400, jason henson wrote:
> To avoid this warning, the variables and/or arguments should be
> prevented from being optimized by declaring them as volatile.
>
> So I sprinkled some volatiles around, but mostly got more errors that
> said "gcc volatile discard
On Mon, May 16, 2005 at 02:11:42PM +0300, Juho Vuori wrote:
> The below included simple program reliably printfs "error 4\n" on
> 5.4-RELEASE. Am I understanding something wrong or is this a bug in
> libdevinfo?
There is indeed a bug in libdevinfo.
> To continue on this however, if you put say
On Thu, Oct 07, 2004 at 07:43:22PM +0200, Andreas Klemm wrote:
> Dear FreeBSD hackers,
>
> could somebody please help Jonathan, the dspam owner, how to code
> this best under FreeBSD ?
> s->p_getpwnam = (struct passwd) { NULL, NULL, 0, 0, NULL, NULL, NULL };
> !
> s->p_g
destroy_dev(). If it reaches zero, the major number is
released by resetting its reserved_majors entry to 0. This avoid the
"Out of major numbers" panic after about 100 make_dev() calls with
MAJOR_AUTO. Majors not assigned by MAJOR_AUTO are not affected. Does
this look reasonable?
Chee
On Thu, Jan 09, 2003 at 03:30:59PM +0100, Pawel Jakub Dawidek wrote:
> I got strange problem when trying to implement something like exceptions
> with setjmp()/longjmp() functions.
>
> [...]
> int ret;
> jmpbuf buf;
> [...]
> ret = setjmp(buf);
> KASSERT(ret !=
vm_getprocs(kd, KERN_PROC_TTY, fs->st_rdev,
232:&entries)) == 0) {
*kd is uninitialized, your have to call kvm_open() instead of malloc().
Regards,
Stefan Farfeleder
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
es
> doesn't include the later. Is this behaviour intended or has noone tried
> to do this before?
utmp(5) tells you to include before , so this
should be intended.
Regards,
Stefan Farfeleder
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
23 matches
Mail list logo
