Re: Unsigned wchar_t
On Mon, Mar 28, 2011 at 10:33:19PM +1300, Andrew Turner wrote: On Sun, 27 Mar 2011 22:07:30 +0200 Stefan Farfeleder ste...@fafoe.narf.at wrote: The C standard specifies that both wchar.h and stdint.h shall define WCHAR_MIN and WCHAR_MAX. You cannot simply include machine/_stdint.h from wchar.h because the former contains a lot of other macros. I thought that might be the case. I could create machine/_wchar.h for the defines unless there is a better place for them. Yes, a new header would be a possibility. Stefan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Unsigned wchar_t
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 wchar.h and machine/_stdint.h. 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 place to put the __wchar_t typedef and define WCHAR_MIN and WCHAR_MAX? The C standard specifies that both wchar.h and stdint.h shall define WCHAR_MIN and WCHAR_MAX. You cannot simply include machine/_stdint.h from wchar.h because the former contains a lot of other macros. Stefan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's
On Fri, Jan 16, 2009 at 01:33:38PM +0200, Danny Braniss wrote:
some facts:
#include stdio.h
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)
works fine
so, there is something realy wrong going on here!
(and it gows back to at least 7.0-stable)
The compiler thinks strerror returns an int. Include string.h.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's
On Fri, Jan 16, 2009 at 10:33:15AM -0800, Nate Eldredge wrote: Pop quiz: which of the following statements is correct? #include stdlib.h #include unistd.h 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, /bin/sh, (char *)0); ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: `type' built-in command in /bin/sh
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 `type' should use it in case of error .. what do you think? You're right. I will fix it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why doesn't autoconf like our /bin/sh?
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.
# 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 ~/tmp/ln
f line: 2
f line: 3
main line: 9
f line: 3
# bash ~/tmp/ln
f line: 2
f line: 5
main line: 9
f line: 5
Yes, I know. I think it is a bug in bash as SUSv3 states:
Set by the shell to a decimal number representing the current
sequential line number (numbered starting with 1) within a script or
function before it executes each command.
Actually, the bash way seems more intuitive. And it does say the current
sequentional line number within a ... function before it executes each
command
The within a function implies that this property goes inside of functions
instead of forcing all commands in a function to use the starting line of the
function which is what you are saying?
I've started a thread about that on [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why doesn't autoconf like our /bin/sh?
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 ~/tmp/ln
f line: 2
f line: 3
main line: 9
f line: 3
# bash ~/tmp/ln
f line: 2
f line: 5
main line: 9
f line: 5
Yes, I know. I think it is a bug in bash as SUSv3 states:
Set by the shell to a decimal number representing the current
sequential line number (numbered starting with 1) within a script or
function before it executes each command.
Stefan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why doesn't autoconf like our /bin/sh?
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 system with only /bin/sh and the ports zsh as installed shells, if you have SHELL set to zsh when invoking the autoconf-generated configure script, the script produces a broken Makefile. It doesn't generate an error, it just complains that: Can you please retry? /bin/sh now supports expanding $LINENO which was often the reason for configure not liking it. Stefan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why doesn't autoconf like our /bin/sh?
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 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 system with only /bin/sh and the ports zsh as installed shells, if you have SHELL set to zsh when invoking the autoconf-generated configure script, the script produces a broken Makefile. It doesn't generate an error, it just complains that: Can you please retry? /bin/sh now supports expanding $LINENO which was often the reason for configure not liking it. Which branch, and how recently? HEAD and yesterday. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange bit-shifting
On Tue, Apr 03, 2007 at 08:22:15PM +0300, Andriy Gapon wrote:
$ cat test_shl.c
#include stdint.h
#include stdio.h
int main()
{
uint64_t l;
l = 0;
l--;
printf(%.16lX\n, l);
l = 64;
printf(%.16lX\n, l);
return 0;
}
$ cc test_shl.c -o test_shl
test_shl.c: In function `main':
test_shl.c:11: warning: left shift count = width of type
$ ./test_shl
$ uname -srm
FreeBSD 6.2-RELEASE-p2 amd64
$ gcc -v
Using built-in specs.
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 3.4.6 [FreeBSD] 20060305
What gives ? It looks like shift is actually done not by specified
number of bits but by that number modulo 64.
Please also mind that the same thing happens if I use a variable instead
of a constant in that expression.
The behaviour is undefined and you even got a warning from GCC.
C99 6.5.7:
# The integer promotions are performed on each of the operands. The type
# of the result is that of the promoted left operand. If the value of
# the right operand is negative or is greater than or equal to the width
# of the promoted left operand, the behavior is undefined.
Stefan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: KASSERT in kernel module outside src/sys
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(0, test panic). Is there something else I need to do besides add options INVARIANTS to my kernel config file. Any clues would be appreciated. Tried CFLAGS+=-DINVARIANTS in the Makefile of the module? Thanks all. That almost works, I'm getting a syntax error before string constant. You need a pair of parentheses around the message: KASSERT(0, (test panic)) Stefan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
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.so: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 100116)] 0x29a9599b in nsGlobalWindow::RunTimeout (this=0x8393500, aTimeout=0x8935000) at nsGlobalWindow.cpp:6378 6378 timeout-mArgv[timeout-mArgc] = Current language: auto; currently c++ (gdb) p timeout-mArgc $1 = 0 (gdb) p timeout-mArgv $2 = (jsval *) 0x800 (gdb) p timeout-mArgv[timeout-mArgc] Error accessing memory address 0x800: Bad address. The 0x800 are the result of an earlier malloc(0). When looking at the MALLOC(3) manpage, we can read (near the description of the flags): ... VAttempting to allocate zero bytes will return a NULL pointer instead of a valid pointer. (The default behavior is to make a minimal allocation and return a pointer to it.) This option is provided for System V compatibility. This option is incompatible with the ``X'' option. ... So I gave it a try by running MALLOC_OPTIONS=V firefox and firefox didn't crash anymore and prefbar was running :-). (Now malloc returns NULL and firefox doesn't interpret the result as a pointer to some allocated memory and therefore doesn't use it). The manpage makes me think that when malloc is called with 0 as argument (and no V-flag had been set) the pointer it returns can actually be used (as a pointer to the so-called minimal allocation). It seems, that firefox thinks the same way :-). However, it is calculated in malloc.c as a constant and is always 0x800 (on my architecture). Any access to this area results in a SIGSEV. I assume the behaviour is meant to show up programming errors: If you use malloc(0) and are crazy enough to access the 'allocated' memory we give you a SIGSEV to show you how dumb you are :-). In this case the manpage is wrong (or, at least, mis-leading) and should be fixed (I could give it a try if someone actually is willing to commit it). Apart from that, I suggest, we should run firefox (and maybe other mozilla apps) with MALLOC_OPTIONS=V. Another position could be that firefox is wrong because it NEVER may use ANY return value of a malloc(0), regardless of its content. Opinions, please... The C Standard says the following about malloc(0): If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object. So our default behaviour to crash if a pointer returned by malloc(0) is dereferenced is legal and a good one because it catches errors like the above one. I agree that the wording in the man page should be improved. Probably it should say that malloc(0) returns a non-NULL pointer which must not be dereferenced without mentioning a minimal allocation. Stefan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: different behaviour on fbsd and linux
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.: execl(/bin/ls, /bin/ls, NULL); is what you want to do. execl(/bin/ls, /bin/ls, (char *)NULL); as NULL might expand to an integer 0. Stefan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Small patch to sh.1
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 you think that, please feel free to move it up. Stefan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Standard C-macro scripting
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 (as you seem to imply in the subject), use this instead: #define _NOT(...) __VA_ARGS__ Stefan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: getdirentries_args and other kernel syscall structures
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:
struct getdirentries_args {
char fd_l_[PADL_(int)]; int fd; char fd_r_[PADR_(int)];
char buf_l_[PADL_(char *)]; char * buf; char buf_r_[PADR_(char *)];
char count_l_[PADL_(u_int)]; u_int count; char
count_r_[PADR_(u_int)];
char basep_l_[PADL_(long *)]; long * basep; char
basep_r_[PADR_(long *)];
};
Now my question is what does the l and r variables do? It seems that
they do something with padding the data based on the endian of the
machine? I look through this header file, and I see all the structures
have similar constructs. Is it something that can be safely ignored?
This file is automatically generated by makesyscalls.sh. The l and r
variables are a hack to correctly the member between them. One of PADL_
or PADR_ always evalutes to 0, the other one to the needed padding,
depending on the passed type. This is unfortunate because it relies on
the GCC extension to accept 0-sized arrays. I'd love to fix that but
couldn't come up with something that isn't very involved.
Stefan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: using -ftracer stops buildworld at shutdown.c
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 discards qualifiers from pointer target type in the
fprintf functions.
Replacing line 276 with 'FILE *volatile pf;' fixes the warning. But the
usage of {long,set}jmp() is wrong anyway since timeout() can jump back
into timewarn() while that isn't executed at all.
Stefan
Index: shutdown.c
===
RCS file: /home/ncvs/src/sbin/shutdown/shutdown.c,v
retrieving revision 1.28
diff -I.svn -u -r1.28 shutdown.c
--- shutdown.c 25 Jan 2005 08:40:51 - 1.28
+++ shutdown.c 27 Jul 2005 13:24:29 -
@@ -273,7 +273,7 @@
{
static int first;
static char hostname[MAXHOSTNAMELEN + 1];
- FILE *pf;
+ FILE *volatile pf;
char wcmd[MAXPATHLEN + 4];
if (!first++)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in devinfo or something wrong with me?
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 sleep(5) between
devinfo_free() and the second devinfo_init() and manage to change the
device configuration during the sleep (tested with pluggin in/out a USB
memory), the program terminates with no errors. I've run into other
oddities with devinfo as well, but in much more complex situations so
they might just as well be variations of this simple example.
if (devinfo_init()) {
devinfo_init() initialises the devinfo_dev tailq, devinfo_generation and
sets devinfo_initted to 1.
devinfo_free();
devinfo_free() clears devinfo_dev and sets devinfo_initted to 0 but
devinfo_generation keeps its value.
if (devinfo_init()) {
Now devinfo_dev doesn't get filled because ubus.ub_generation ==
devinfo_generation.
Here is a patch that resets devinfo_generation to 0 in devinfo_free().
The whole file can probably be simplified a bit due to this bug.
Stefan
Index: devinfo.c
===
RCS file: /home/ncvs/src/lib/libdevinfo/devinfo.c,v
retrieving revision 1.6
diff -I.svn -u -r1.6 devinfo.c
--- devinfo.c 1 Mar 2005 20:32:05 - 1.6
+++ devinfo.c 16 May 2005 12:40:24 -
@@ -367,6 +370,7 @@
free(dr);
}
devinfo_initted = 0;
+ devinfo_generation = 0;
}
/*
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: please help with: warning: initialization makes integer from pointer
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_getpwuid = (struct passwd) { NULL, NULL, 0, 0, NULL, NULL, NULL };
!
This works but might cause (harmless) warnings about missing
initialisers:
s-p_getpwnam = (struct passwd) { 0 };
s-p_getpwuid = (struct passwd) { 0 };
Alternatively:
static struct passwd zero_pwd;
s-p_getpwnam = zero_pwd;
s-p_getpwuid = zero_pwd;
Cheers,
Stefan
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Major numbers reclaiming for make_dev/MAJOR_AUTO
Hi,
attached is a patch that tries to keep track of the major numbers that
were assigned automatically by make_dev() if you use MAJOR_AUTO.
The number of times make_dev() was called with this major number is
stored in the reserved_majors_refcnt array, the entry is decreased again
if you call 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?
Cheers,
Stefan Farfeleder
Index: src/sys/kern/kern_conf.c
===
RCS file: /usr/home/ncvs/src/sys/kern/kern_conf.c,v
retrieving revision 1.134
diff -u -r1.134 kern_conf.c
--- src/sys/kern/kern_conf.c11 Jun 2003 00:56:55 - 1.134
+++ src/sys/kern/kern_conf.c17 Sep 2003 15:40:12 -
@@ -46,6 +46,8 @@
/* Built at compile time from sys/conf/majors */
extern unsigned char reserved_majors[256];
+/* Only used for MAJOR_AUTO, 0 otherwise */
+static unsigned int reserved_majors_refcnt[256];
/*
* This is the number of hash-buckets. Experiements with 'real-life'
@@ -294,6 +296,7 @@
KASSERT(i 0, (Out of major numbers (%s), devsw-d_name));
devsw-d_maj = i;
reserved_majors[i] = i;
+ reserved_majors_refcnt[i] = 1;
} else {
if (devsw-d_maj == 256)/* XXX: tty_cons.c is magic */
devsw-d_maj = 0;
@@ -305,6 +308,8 @@
devsw-d_maj);
reserved_majors[devsw-d_maj] = devsw-d_maj;
}
+ if (reserved_majors_refcnt[devsw-d_maj] 0)
+ reserved_majors_refcnt[devsw-d_maj]++;
}
if (!ready_for_devs) {
@@ -397,6 +402,7 @@
void
destroy_dev(dev_t dev)
{
+ struct cdevsw *d;
if (!(dev-si_flags SI_NAMED)) {
printf( WARNING: Driver mistake: destroy_dev on %d/%d\n,
@@ -404,6 +410,11 @@
panic(don't do that);
}
+ d = devsw(dev);
+ if (reserved_majors_refcnt[d-d_maj] 0)
+ if (--reserved_majors_refcnt[d-d_maj] == 0)
+ reserved_majors[d-d_maj] = 0;
+
devfs_destroy(dev);
if (dev-si_flags SI_CHILD) {
LIST_REMOVE(dev, si_siblings);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Exceptions via setjmp/longjmp in kernel.
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 != 1, (I never return 1 with longjmp().)); [...] longjmp(buf, value_diffrent_than_1); [...] And setjmp() returns only 0 or 1 (when longjmp() is called), but never returns value that I've put in longjmp() call. There could be some other problems in using setjmp()/longjmp() in kernel? I'm paying attention on memory leaks and locks that are done before longjmp(). The usage of the setjmp macro in an assignment is not defined by ISO C, which might or might not be your problem. 7.13.1.1 The setjmp macro An invocation of the setjmp macro shall appear only in one of the following contexts: -- the entire controlling expression of a selection or iteration statement; -- one operand of a relational or equality operator with the other operand an integer constant expression, with the resulting expression being the entire controlling expression of a selection or iteration statement; -- the operand of a unary ! operator with the resulting expression being the entire controlling expression of a selection or iteration statement; or -- the entire expression of an expression statement (possibly cast to void). OTOH, vinum and ficl use setjmp in the same way. Stefan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Broken utmp.h
On Thu, Dec 12, 2002 at 02:46:03PM +0100, Jörg Sonnenberger wrote: Hi all, I am porting terminal emulator from Linux to (Free-)BSD and got a nice error message from #include utmp.h. I am using FreeBSD-current. This file uses int32_t without including stdint.h, so it fails if my sources doesn't include the later. Is this behaviour intended or has noone tried to do this before? utmp(5) tells you to include sys/types.h before utmp.h, 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
Re: libkvm breakage?
On Thu, Dec 12, 2002 at 01:32:36PM +0300, Fred Souza wrote:
snip
Can anyone else reproduce this? Or better yet, does anyone know what's
the problem and how to fix it? :-)
161:free(ep);
ep points to some character of optarg if -g, -m or -o ist used...
231:if ((kp = kvm_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
