Re: 5.1->5.2
On Thu, Jan 15, 2004 at 05:04:59PM -0500, Robert Watson wrote: > > IPFILTER now relies on the PFIL_HOOKS kernel option; this is something > that is somewhat poorly documented, and we should add it to the errate I > suspect. If you add "options PFIL_HOOKS" to your kernel config, it should > work. Moving to PFIL_HOOKS for all the "funky IP input/ouput" feature is > a goal for 5.3 (in fact, I believe Sam has it almost entirely done in one > of his development branches), and should both simplify the input/output > paths, and also simplify locking for the IP stack. So the change is for a > good cause :-). > That reminds me: is there a way to influence the order in which the various packages are hooked up? E.g. I can imagine a situation where you want IPfilter NATting and ipfw filtering. In such a scenario you want to be able to specify _exactly_ that ipfilter comes before ipfw when packets come in, and vice versa when packets go out. -Guido ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
few question about vfs layer
Hi List I explore vfs lookup code. and have few questions about it. what a reasone leave rootvnode as global varables, but not store it in filedesc structrure and adjust it in chroot or jail syscall ? -- With best regards, Alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Slow Console Input
On Thu, Jan 15, 2004 at 10:56:36PM -0600, Michael Cacek wrote: > I recently installed freebsd 5.2 on a local sunblade 100 system. You probably want to try on the sparc64@ list. FWIW, the last time I checked syscons improvements were still on the TO-DO list for the sparc64 port. It's never really affected me though -- my Ultra 5 is a server, so I either serial console to it or ssh/Kerberized telnet to it. -T -- > Life is once again okay, if non-standard. - Takis Skagos, on a LOSURS mailing list ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1->5.2
Now I can play with ULE, Thanks for your quick response. I should've checked release notes before posting my question, my fault. -mpf Robert Watson wrote: On Thu, 15 Jan 2004, Matt Freitag wrote: Building 5.2-RELEASE from 5.1-RELEASE-p10 w/ipf+ipfw+ipfw6+dummynet, 5.1 Compiled fine with this setup. I need ipfilter as it's doing my source routing for ipv6 (multiple transits) since ip6fw doesn't support fwd. (I just use ip6fw for filtering, and ipf for forwarding to the correct interface according to source) Am I just being stupid here somehow? IPFILTER now relies on the PFIL_HOOKS kernel option; this is something that is somewhat poorly documented, and we should add it to the errate I suspect. If you add "options PFIL_HOOKS" to your kernel config, it should work. Moving to PFIL_HOOKS for all the "funky IP input/ouput" feature is a goal for 5.3 (in fact, I believe Sam has it almost entirely done in one of his development branches), and should both simplify the input/output paths, and also simplify locking for the IP stack. So the change is for a good cause :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI interrupt allocation question..
On Tue, Jan 13, 2004 at 04:14:10PM -0800, Julian Elischer wrote: > > > On Wed, 14 Jan 2004, Stijn Hoop wrote: > > > On Tue, Jan 13, 2004 at 03:26:00PM -0800, Julian Elischer wrote: > > > The kernel includes teh ichsmb driver to try access the SMBus > > > for temperature reading reasons (yes I know I can do it other ways..) > > > > > > Any thoughts that move me towards getting th eichsmb driver working on > > > this machine are welcome. > > > > Make sure that the mainboard really does support SMBus -- it turns out that > > this is optional. The ICH docs talk about a bit that should be enabled in the > > PCI config when SMB is present. I ran into this once, it should be documented > > in the archives (of -current off the top of my head). OTOH, I didn't even > > succeed in getting an ichsmb device probed so this might be something totally > > unrelated. SMBus is absolutely not optional because it's required for SPD eeproms. > > FWIW, I had to try other ways to get the temperature (xmbmon & related). I > > don't have the box anymore or I'd show you the exact config... > > xmbmon uses the SMBus to read the temperatures but it does it from > userland using direct read and write operations > and when there are timing glitches caused by the process not getting > scheduled quite quick enough you get garbage results.. > teh theory is that the kernel driver wouldn't be susceptible to this > but it looks like unless I resort to polling I will not be able to use > it because it relies on the interrupts and they are not being delivered. ichsmb(4) does a different addressing on smbus as other smbus drivers. I'm about to validate all SMBus drivers to harmonise this point. Also software regulary forgets about different smb.h include path on 5.x > ASUS motherboards actually turn off the SMBus. (why?) A very good question - I'm in tight contact with Asus germany to get that answered, but even they doesn't seem to get a satisfying answer from taiwan. It seems that they don't want customers to tamper with SMBus :( > So you need to turn it back on before you can read the temperatures.. Use ACPI... Well - it's evil after all, because I sell add on products for SMBus for which ACPI is not an option. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Mergemaster+RCS
$B1)?6$j$NNI$/$J$C$?$+$D$F$NIt2<$KD$r5-$7$?%O%k$N2s8\O?Iw$K(B $B$O!"(B"$B#1#0!s$N9XF~A}(B"$B!"(B"$BM}2r$r5a$a$k(B"$B$O;~4V2T$.$G!"2?$+$r1#$7$F$$$k>Z5r$H(B $B2rl$ON?$2$k$H;W$C$F$$$k!"A10U$KK~$A$?(B $B$O$$$k$,7hDj8"$NA4$/$J$$7/$_$?$$$J?M$HMh$F$O!"9T$+$J$$J}$,NI$$$K7h$^$C$F$$$k!#(B (B[EMAIL PROTECTED]"6[D%$KBQ$($k5$35$b$J$/!"[EMAIL PROTECTED]"32$HB;$,A}$([EMAIL (BPROTECTED](B $B$N(BUnderstatement$B$J$i(B10 [EMAIL (BPROTECTED]&$K$O(B100%$BA}$N7W2h$,$J$1$l$P$J$k$^$$!#(B (B (B[EMAIL PROTECTED];W$&[EMAIL PROTECTED]&$,!"@[EMAIL (BPROTECTED]($k!#5nG/$b:_8K$rA}$d$7$?$N$K!"99$K(B $B#1#0!s$H$OE~Dl?.$8$i$l$J$$OC!#(BRenapur$B$rGd$C$?J}$,3f9%$,IU$/$N$G$O$J$$$+!#(B (B $BBg$$$KIe$k$,$h$m$7$$!#:#$^$G$r9M$($l$P!"EvA3$J7k2L$K$J$C$?$HG<[EMAIL (BPROTECTED]&!#(B (B $B$d$^$.$7(B (B___ (B[EMAIL PROTECTED] mailing list (Bhttp://lists.freebsd.org/mailman/listinfo/freebsd-hackers (BTo unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1->5.2
"Bruce A. Mah" <[EMAIL PROTECTED]> writes: > It's in the release notes and in UPDATING...I have the feeling that if > people won't read it in either of those two places, they won't read it > in the errata either. :-p How 'bout putting it some place folks are likely to stumble upon it, like as a comment in the GENERIC kernel file? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Bind hack for ipv6 autoconf
I was just wondering, inspired by Saku Ytti's idea of making hack to bind which would allow proper PTR and records for rtadvd or similar autoconfigured hosts, as you can know hosts that are given are quite random, and far as I know there is no smart logic with them. So, somekinda hack for bind is needed. eg. bind could be modified to do PTR and with different system than zonefiles has, though zonefiles shouldn't be ignored but if query regarding autoconfigured subnet comes in it should be handled on its own system. For example: Foo asks reverse for address xyz, bind notices that it has subnet xy defined as autoconfig hosts and calculates reverse for it like, xyz IN PTR z-xy.auto.foo.tld. And then, another day, Bar asks record for z-xy.auto.foo.tld and bind notices that its under auto.foo.tld which was defined for autoconfigured hosts and subnet was xy, answer xyz is given. And if foo asks for foo.tld bind operates normally and gives possible answer from zonefile. If ISC guys are following these lists I would like to hear their comments. Anybody interested in developing this kind of modification? Ideas? Comments? Anybody? Greets Markus Kovero ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
Mark Linimon wrote: But, in the real world of software engineering, He Who Breaketh It, Must Fixeth It. Your mileage may vary. Yes it vaires. In the real world He Who Reaketh It, will hire someone who known what he is doing to fix the problem... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[CHECKER] bugs in FreeBSD
Hi,
I'm with the Stanford Metacompilation research group. We have a suite of
checkers that find bugs at compile time and we've had quite a bit of
success checking the Linux kernel code for errors. Since our checkers can
emit false alarms we filter the reports before we give them to the kernel
developers. While some false alarms slip past us to the developers, our
limited knowledge of the kernel allows us to recognize most of them.
We are currently trying to extend our checker to automatically find
functions which allocate resources and to make sure those resources are
properly disposed of.
Enclosed is a list of potential bugs in FreeBSD where a value is returned
from a function (like malloc) that should be owned by the caller and the
caller does not properly dispose of the value with the appropriate
disposal routine (like free).
Confirmation of these reports would be appreciated.
Thanks
Paul Twohey
-
[BUG] they do error checking at the end, so lose config.
/u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/ata/ata-raid.c:1222:ar_highpoint_write_conf:ERROR:LEAK:1222:1222:
pointer=config from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0]
[success=6]
microtime(×tamp);
rdp->magic_0 = timestamp.tv_sec + 2;
rdp->magic_1 = timestamp.tv_sec;
for (disk = 0; disk < rdp->total_disks; disk++) {
Error --->
if (!(config = (struct highpoint_raid_conf *)
malloc(sizeof(struct highpoint_raid_conf),
M_AR, M_NOWAIT | M_ZERO))) {
printf("ar%d: Highpoint write conf failed\n", rdp->lun);
-
[BUG]
/u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/ppbus/vpo.c:187:vpo_cam_rescan:ERROR:LEAK:187:192:
pointer=ccb from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0]
[success=4]
static void
vpo_cam_rescan(struct vpo_data *vpo)
{
struct cam_path *path;
Start --->
union ccb *ccb = malloc(sizeof(union ccb), M_TEMP, M_WAITOK | M_ZERO);
if (xpt_create_path(&path, xpt_periph, cam_sim_path(vpo->sim), 0, 0)
!= CAM_REQ_CMP) {
/* A failure is benign as the user can do a manual rescan */
Error --->
return;
}
xpt_setup_ccb(&ccb->ccb_h, path, 5/*priority (low)*/);
-
[BUG] though we should demote things that are not locals.
/u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/ips/ips.c:148:ips_add_waiting_command:ERROR:LEAK:148:154:
pointer=waiter from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0]
[success=5]
ips_command_t *command;
ips_wait_list_t *waiter;
unsigned long memflags = 0;
if(IPS_NOWAIT_FLAG & flags)
memflags = M_NOWAIT;
Start --->
waiter = malloc(sizeof(ips_wait_list_t), M_DEVBUF, memflags);
if(!waiter)
return ENOMEM;
mask = splbio();
if(sc->state & IPS_OFFLINE){
splx(mask);
Error --->
return EIO;
}
command = SLIST_FIRST(&sc->free_cmd_list);
if(command && !(sc->state & IPS_TIMEOUT)){
-
[BUG]
/u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/sio/sio.c:497:sioprobe:ERROR:LEAK:497:504:
pointer=port from RO=bus_alloc_resource(-1) [s=65,pop=65,pr=1.00] [rank=med] leaked!
[z=1.0] [success=3]
u_int flags = device_get_flags(dev);
int rid;
struct resource *port;
rid = xrid;
Start --->
port = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid,
0, ~0, IO_COMSIZE, RF_ACTIVE);
if (!port)
return (ENXIO);
com = malloc(sizeof(*com), M_DEVBUF, M_NOWAIT | M_ZERO);
if (com == NULL)
Error --->
return (ENOMEM);
device_set_softc(dev, com);
com->bst = rman_get_bustag(port);
com->bsh = rman_get_bushandle(port);
-
[BUG]
/u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/mly/mly.c:2023:mly_cam_rescan_btl:ERROR:LEAK:2023:2031:
pointer=ccb from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0]
[success=4]
{
union ccb *ccb;
debug_called(1);
Start --->
if ((ccb = malloc(sizeof(union ccb), M_TEMP, M_WAITOK | M_ZERO)) == NULL) {
mly_printf(sc, "rescan failed (can't allocate CCB)\n");
return;
}
if (xpt_create_path(&sc->mly_cam_path, xpt_periph,
cam_sim_path(sc->mly_cam_sim[bus]), target, 0) != CAM_REQ_CMP)
{
mly_printf(sc, "rescan failed (can't create path)\n");
Error --->
return;
}
xpt_setup_ccb(&ccb->ccb_h, sc->mly_cam_path, 5/*priority (low)*/);
ccb->ccb_h.func_code = XPT_SC
[CHECKER] bugs in FreeBSD
Hi,
I'm with the Stanford Metacompilation research group. We have a suite of
checkers that find bugs at compile time and we've had quite a bit of
success checking the Linux kernel code for errors. Since our checkers can
emit false alarms we filter the reports before we give them to the kernel
developers. While some false alarms slip past us to the developers, our
limited knowledge of the kernel allows us to recognize most of them.
We are currently trying to extend our checker to automatically find
functions which allocate resources and to make sure those resources are
properly disposed of.
Enclosed is a list of potential bugs in FreeBSD where a value is returned
from a function (like malloc) that should be owned by the caller and the
caller does not properly dispose of the value with the appropriate
disposal routine (like free).
Confirmation of these reports would be appreciated.
Thanks
Paul Twohey
-
[BUG] they do error checking at the end, so lose config.
/u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/ata/ata-raid.c:1222:ar_highpoint_write_conf:ERROR:LEAK:1222:1222:
pointer=config from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0]
[success=6]
microtime(×tamp);
rdp->magic_0 = timestamp.tv_sec + 2;
rdp->magic_1 = timestamp.tv_sec;
for (disk = 0; disk < rdp->total_disks; disk++) {
Error --->
if (!(config = (struct highpoint_raid_conf *)
malloc(sizeof(struct highpoint_raid_conf),
M_AR, M_NOWAIT | M_ZERO))) {
printf("ar%d: Highpoint write conf failed\n", rdp->lun);
-
[BUG]
/u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/ppbus/vpo.c:187:vpo_cam_rescan:ERROR:LEAK:187:192:
pointer=ccb from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0]
[success=4]
static void
vpo_cam_rescan(struct vpo_data *vpo)
{
struct cam_path *path;
Start --->
union ccb *ccb = malloc(sizeof(union ccb), M_TEMP, M_WAITOK | M_ZERO);
if (xpt_create_path(&path, xpt_periph, cam_sim_path(vpo->sim), 0, 0)
!= CAM_REQ_CMP) {
/* A failure is benign as the user can do a manual rescan */
Error --->
return;
}
xpt_setup_ccb(&ccb->ccb_h, path, 5/*priority (low)*/);
-
[BUG] though we should demote things that are not locals.
/u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/ips/ips.c:148:ips_add_waiting_command:ERROR:LEAK:148:154:
pointer=waiter from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0]
[success=5]
ips_command_t *command;
ips_wait_list_t *waiter;
unsigned long memflags = 0;
if(IPS_NOWAIT_FLAG & flags)
memflags = M_NOWAIT;
Start --->
waiter = malloc(sizeof(ips_wait_list_t), M_DEVBUF, memflags);
if(!waiter)
return ENOMEM;
mask = splbio();
if(sc->state & IPS_OFFLINE){
splx(mask);
Error --->
return EIO;
}
command = SLIST_FIRST(&sc->free_cmd_list);
if(command && !(sc->state & IPS_TIMEOUT)){
-
[BUG]
/u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/sio/sio.c:497:sioprobe:ERROR:LEAK:497:504:
pointer=port from RO=bus_alloc_resource(-1) [s=65,pop=65,pr=1.00] [rank=med] leaked!
[z=1.0] [success=3]
u_int flags = device_get_flags(dev);
int rid;
struct resource *port;
rid = xrid;
Start --->
port = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid,
0, ~0, IO_COMSIZE, RF_ACTIVE);
if (!port)
return (ENXIO);
com = malloc(sizeof(*com), M_DEVBUF, M_NOWAIT | M_ZERO);
if (com == NULL)
Error --->
return (ENOMEM);
device_set_softc(dev, com);
com->bst = rman_get_bustag(port);
com->bsh = rman_get_bushandle(port);
-
[BUG]
/u2/engler/mc/freebsd/sys/i386/compile/GENERIC/../../../dev/mly/mly.c:2023:mly_cam_rescan_btl:ERROR:LEAK:2023:2031:
pointer=ccb from RO=malloc(-1) [s=550,pop=551,pr=1.00] [rank=med] leaked! [z=1.0]
[success=4]
{
union ccb *ccb;
debug_called(1);
Start --->
if ((ccb = malloc(sizeof(union ccb), M_TEMP, M_WAITOK | M_ZERO)) == NULL) {
mly_printf(sc, "rescan failed (can't allocate CCB)\n");
return;
}
if (xpt_create_path(&sc->mly_cam_path, xpt_periph,
cam_sim_path(sc->mly_cam_sim[bus]), target, 0) != CAM_REQ_CMP)
{
mly_printf(sc, "rescan failed (can't create path)\n");
Error --->
return;
}
xpt_setup_ccb(&ccb->ccb_h, sc->mly_cam_path, 5/*priority (low)*/);
ccb->ccb_h.func_code = XPT_SC
__restrict__ vs __restrict ?
I've been enabling a LOT of gcc warnings recently in the process of linting some code I'm writing. In the process, I stumbled across the following curiosity: > cat test.c #include > gcc -std=c99 -ansi test.c In file included from test.c:1: /usr/include/stdio.h:220: conflicting types for `restrict' /usr/include/stdio.h:220: previous declaration of `restrict' /usr/include/stdio.h:221: conflicting types for `restrict' /usr/include/stdio.h:221: previous declaration of `restrict' /usr/include/stdio.h:222: redefinition of `restrict' /usr/include/stdio.h:222: `restrict' previously declared here /usr/include/stdio.h:223: conflicting types for `restrict' [ many similar lines omitted ] If I change all "__restrict" in stdio.h to "__restrict__", these warnings disappear. Question: Does anyone know the difference between __restrict and __restrict__? Should we be using the latter in our system headers? Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: __restrict__ vs __restrict ?
On Fri, Jan 16, 2004 at 05:23:01PM -0800, Tim Kientzle wrote: > I've been enabling a LOT of gcc warnings recently > in the process of linting some code I'm writing. > In the process, I stumbled across the following > curiosity: > > > cat test.c > #include > > gcc -std=c99 -ansi test.c > In file included from test.c:1: > /usr/include/stdio.h:220: conflicting types for `restrict' > /usr/include/stdio.h:220: previous declaration of `restrict' > /usr/include/stdio.h:221: conflicting types for `restrict' > /usr/include/stdio.h:221: previous declaration of `restrict' > /usr/include/stdio.h:222: redefinition of `restrict' > /usr/include/stdio.h:222: `restrict' previously declared here > /usr/include/stdio.h:223: conflicting types for `restrict' > [ many similar lines omitted ] > > If I change all "__restrict" in stdio.h to "__restrict__", > these warnings disappear. > > Question: Does anyone know the difference between > __restrict and __restrict__? > __restrict__ is the gcc(1)-only feature. From gcc.info: : `-std=' : Determine the language standard. This option is currently only : supported when compiling C or C++. A value for this option must be : provided; possible values are : [...] : Even when this option is not specified, you can still use some of : the features of newer standards in so far as they do not conflict : with previous C standards. For example, you may use : `__restrict__' even when `-std=c99' is not specified. : [...] : As with gcc, g++ understands the C99 feature of restricted pointers, : specified with the `__restrict__', or `__restrict' type qualifier. : Because you cannot compile C++ by specifying the `-std=c99' language : flag, `restrict' is not a keyword in C++. __restrict is defined in , it's the FreeBSD feature. > Should we be using the latter in our system headers? > No, we should be using the __restrict as coded. But I wonder why we can't just use "restrict", please see below. Note that __restrict is a no-op these days because we don't compile our C code by default with -std=c99. I'm not sure why we can't replace #if !(__GNUC__ == 2 && __GNUC_MINOR__ == 95) #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 199901 #define __restrict #else #define __restrict restrict #endif #endif with #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 199901 #define restrict #endif and just use "restrict" everywhere. Also similarly I'm not aware of the status of the CSTD feature for share/mk that was backed out. (8 makefiles in src/ still have CSTD.) Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
ip_input - chksum - why is it done so early in ip_input?
Apologies for the cross-post, i wasnt sure if this was hackers or net material. I've often wondered why ip checksumming is done on every incoming packet and not only on the packets that need to be delivered locally. It looks like a very expensive way of doing it, especially on high PPS. Basically all hosts do checksumming so why not just pass the bad packet on, making the forward process alot cheaper (cpu wise)? I ran some tests (unable to disclose results) by removing it completely and it seems to make a noticable impact on the performance. Especially on for example gaming services where there is a high PPS versus actual data. Besides that i'd like to add that FreeBSD has the fastest forwarding engine i've seen on any free OS. It's in my opinion a very suitable OS for routing/forwarding. _// Sten ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: __restrict__ vs __restrict ?
Ruslan Ermilov wrote: On Fri, Jan 16, 2004 at 05:23:01PM -0800, Tim Kientzle wrote: Question: Does anyone know the difference between __restrict and __restrict__? __restrict__ is the gcc(1)-only feature. __restrict is defined in , it's the FreeBSD feature. A-ha! That's the part I had missed. After a few experiments with gcc -dM -E, I've convinced myself that this is just another GCC bug. Basically, -std=c99 -ansi seems to be a very bad compination, as -std=c99 defines __STDC_VERSION__ to be 199901L and -ansi then turns off compiler support for c99 features. Ugh. Should we be using the latter in our system headers? No, we should be using the __restrict as coded. But I wonder why we can't just use "restrict"... Because that would really mess up any user program that used 'restrict' as a variable or function name. I think the current approach is the best. Thanks for the clarification. I'll go crawl back under my nice, comfortable rock now. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [CHECKER] bugs in FreeBSD
Hello, The tool is amazing :) I am very interested in how does it work, is there any paper published on this topic? Thanks in advance! Xin LI, Beijing University of Technology - Original Message - From: "Paul Twohey" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, January 17, 2004 8:01 AM Subject: [CHECKER] bugs in FreeBSD > Hi, > > I'm with the Stanford Metacompilation research group. We have a suite of > checkers that find bugs at compile time and we've had quite a bit of > success checking the Linux kernel code for errors. Since our checkers can > emit false alarms we filter the reports before we give them to the kernel > developers. While some false alarms slip past us to the developers, our > limited knowledge of the kernel allows us to recognize most of them. > > We are currently trying to extend our checker to automatically find > functions which allocate resources and to make sure those resources are > properly disposed of. > > Enclosed is a list of potential bugs in FreeBSD where a value is returned > from a function (like malloc) that should be owned by the caller and the > caller does not properly dispose of the value with the appropriate > disposal routine (like free). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [CHECKER] bugs in FreeBSD
Dawson is the man. http://www.stanford.edu/~engler/ If I have not seen as far as others, it is because I have been standing in the footprints of giants. -- from Usenet On Fri, 16 Jan 2004, Xin LI wrote: > Hello, > > The tool is amazing :) > > I am very interested in how does it work, is there any paper published on > this topic? > Thanks in advance! > > Xin LI, > Beijing University of Technology > > - Original Message - > From: "Paul Twohey" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, January 17, 2004 8:01 AM > Subject: [CHECKER] bugs in FreeBSD > > > > Hi, > > > > I'm with the Stanford Metacompilation research group. We have a suite of > > checkers that find bugs at compile time and we've had quite a bit of > > success checking the Linux kernel code for errors. Since our checkers can > > emit false alarms we filter the reports before we give them to the kernel > > developers. While some false alarms slip past us to the developers, our > > limited knowledge of the kernel allows us to recognize most of them. > > > > We are currently trying to extend our checker to automatically find > > functions which allocate resources and to make sure those resources are > > properly disposed of. > > > > Enclosed is a list of potential bugs in FreeBSD where a value is returned > > from a function (like malloc) that should be owned by the caller and the > > caller does not properly dispose of the value with the appropriate > > disposal routine (like free). > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
