killing process from interrupt
Hello, I have in my interrupt function the pointer to structure of some process. What is the safe way to kill the process? psignal (p, 9); ? Thanx Alexej ___ 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: C99: Suggestions for style(9)
In message: 20090428114754.gb89...@server.vk2pj.dyndns.org Peter Jeremy peterjer...@optushome.com.au writes: : Maybe using all of these changes is a bit too big change at once, but : I'd like some of them applied to style(9). So, please consider the : proposed changes individually and not a as a all-or-nothing package. : : One area you do not address is code consistency. Currently, the : FreeBSD kernel (and, to a lesser extent, userland) are mostly style(9) : compliant - ie the entire codebase is mostly written in the same : style. Whilst you may not like it (and I don't know that anyone : completely agrees with everything in style(9)), it does mean that : the code is consistent. : : Changing style(9) in a way that is not consistent with current code : means that either existing code must be brought into line with the : new standard - which incurs a one-off cost - or the code base becomes : split into old and new style - incurring an ongoing maintenance : cost as maintainers switch between styles. Both approaches incur a : risk of introducing new bugs. : : Note that I'm not saying that style(9) can never be changed, I'm just : saying that any change _will_ incur a cost and the cost as well as : the potential benefits need to be considered. This is my biggest worry about changing style(9) quickly. We don't want needless churn in the tree for just style changes since it makes it harder to track bug fixes into the past. : [Reduce declaration scope as far as possible, initialise variables where : they are declared, sort by name] : : Whilst my personal preference is for the style suggested by Christoph : (and I generally agree with the points he makes), this is also the : change that incurs the biggest stylistic change. This is not a change : that can be practically retrofitted to existing code and therefore its : implementation would result in a mixture of code styles - increasing : the risk of bugs due to confusion as to which style was being used. I : am not yet sure whether the benefits outweigh the costs, This is the biggest one, and I think it may be too soon. Also, we need to be careful on the initialization side of things because we currently have a lot of code that looks like: struct foo *fp; struct bar *bp; fp = get_foo(); if (!fp) return; bp = fp-bp; this can't easily be translated to the more natural: struct foo *fp = get_foo(); struct bar *bp = fp-bp; since really you'd want to write: struct foo *fp = get_foo(); if (!fp) return; struct bar *bp = fp-bp; which isn't legal in 'C'. However, we have enough where this isn't the case that it should be allowed. We should separate the initialization part of this from the scope part of this too. The initialization part is already leaking into the code, while instances of the scope restriction is rarer. : [Don't parenthesize return values] : Removed, because it does not improve maintainability in any way. : : This change could be made and tested mechanically. But there is : no justification for making it - stating that the existing rule : is no better than the proposed rule is no reason to change. I'm fine with this. : [No KR declarations] : Removed, because there is no need to use them anymore. : : Whilst this is a change that could be performed mechanically, there : are some gotchas relating to type promotion (as you point out). : The kernel already contains a mixture of ANSI KR declarations and : style(9) recommends using ANSI. IMHO, there is no need to make this : change until all KR code is removed from FreeBSD. I'm fine with this change. : [ Don't insert an empty line if the function has no local variables.] : : This change could be made and tested mechanically. IMHO, this change : has neglible risk and could be safely implemented. I'm fine with this change. : +.Sh LOCAL VARIABLES : : Last, but definitely not least, I added this paragraph about the use of : local variables. This is to clarify, how today's compilers handle : unaliased local variables. : : Every version of gcc that FreeBSD has ever used would do this for : primitive types when optimisation was enabled. This approach can : become expensive in stack (and this is an issue for kernel code) when : using non-primitive types or when optimisation is not enabled (though : I'm not sure if this is supported). Assuming that gcc (and icc and : clang) behaves as stated in all supported optimisation modes, this : change would appear to be quite safe to make. Agreed, in general. We don't want to optimize our code style based on what one compiler does, perhaps on x86. Warner ___ 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
NetBSD 5.0 statistics
Is the FreeBSD's FS management so slow? http://www.netbsd.org/~ad/50/img15.html Or so big is the difference between the two cpu scheduler? http://www.netbsd.org/~ad/50/img0.html ___ 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: NetBSD 5.0 statistics
On Thu, Apr 30, 2009 at 7:50 AM, Oliver Pinter oliver.p...@gmail.com wrote: Is the FreeBSD's FS management so slow? http://www.netbsd.org/~ad/50/img15.html Or so big is the difference between the two cpu scheduler? http://www.netbsd.org/~ad/50/img0.html We would need more information about the disk hardware, amount of memory etc. to really provide an answer. We've had a lot of difficulties testing against NetBSD in the past because NetBSD wouldn't boot on recent hardware (ACPI issues IIRC). Looking at the processor he is using it would appear that that has probably been fixed. -Kip ___ 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: NetBSD 5.0 statistics
On Thu, 30 Apr 2009, Oliver Pinter wrote: Is the FreeBSD's FS management so slow? http://www.netbsd.org/~ad/50/img15.html Or so big is the difference between the two cpu scheduler? Also, there's a known and serious performance regression in CAM relating to tgged queueing, and the generic disk sort routine, introduced 7.1, which will be fixed in 7.2. I can't speak more generally to the benchmarks -- we'll need to run them in a controlled environment and see if we can reproduce the results. Robert N M Watson Computer Laboratory University of Cambridge ___ 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: ACPI-fast default timecounter, but HPET 83% faster
On Sunday 26 April 2009 10:27:42 pm Garrett Cooper wrote: I'm seeing similar results. [r...@orangebox /usr/home/gcooper]# dmesg | grep 'Timecounter ' Timecounter i8254 frequency 1193182 Hz quality 0 Timecounter ACPI-fast frequency 3579545 Hz quality 1000 Timecounter HPET frequency 14318180 Hz quality 900 [r...@orangebox /usr/home/gcooper]# ./cgt 1369355 [r...@orangebox /usr/home/gcooper]# sysctl kern.timecounter.hardware=ACPI-fast kern.timecounter.hardware: HPET - ACPI-fast [r...@orangebox /usr/home/gcooper]# ./cgt 772289 Why's the default ACPI-fast? For power-saving functionality or because of the `quality' factor? What is the criteria that determines the `quality' of a clock as what's being reported above (I know what determines the quality of a clock visually from a oscilloscope =])? I suspect that the quality of the HPET driver is lower simply because no one had measured it previously and HPET is newer and less proven. -- John Baldwin ___ 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: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation
On Tuesday 28 April 2009 7:58:57 pm Julian Elischer wrote: Robert Noland wrote: On Tue, 2009-04-28 at 16:48 -0500, Kevin Day wrote: On Apr 28, 2009, at 3:19 PM, Julian Bangert wrote: Hello, I am currently trying to work a bit on the remaining missing feature that NVIDIA requires ( http://wiki.freebsd.org/NvidiaFeatureRequests or a back post in this ML) - the improved mmap system call. you might check with jhb (john Baldwin) as I think (from his p4 work) that he may be doing something in this area in p4. After some promptings from Robert and his needs for Xorg recently I did start hacking on this again. However, I haven't tested it yet. What I have done so far is in //depot/user/jhb/pat/... and it does the following: 1) Adds a vm_cache_mode_t. Each arch defines the valid values for this (I've only done the MD portions of this work for amd64 so far). Every arch must at least define a value for VM_CACHE_DEFAULT. 2) Stores a cache mode in each vm_map_entry struct. This cache mode is then passed down to a few pmap functions: pmap_object_init_pt(), pmap_enter_object(), and pmap_enter_quick(). Several vm_map routines such as vm_map_insert() and vm_map_find() now take a cache mode to use when adding a new mapping. 3) Each VM object stores a cache mode as well (defaults to VM_CACHE_DEFAULT). When a VM_CACHE_DEFAULT mapping is made of an object, the cache mode of the object is used. 4) A new VM object type: OBJT_SG. This object type has its own pager that is sort of like the device pager. However, instead of invoking d_mmap() to determine the physaddr for a given page, it consults a pre-created scatter/gather list (an ADT from my branch for working on unmapped buffer I/O) to determine the backing physical address for a given virtual address. 5) A new callback for device mmap: d_mmap_single(). One of the features of this is that it can return a vm_object_t to be used to satisfy the mmap() request instead of using the device's device pager VM object. 6) A new mcache() system call similar to mprotect(), except that it changes the cache mode of an address range rather than the protection. This may not be all that useful really. Given all this, a driver could do the following to map a thing as WC in both userland and the kernel: 1) When it learns about a thing it creates a SG list to describe it. If the thing consists of userland pages, it has to wire the pages first. The driver can use vm_allocate_pager() to create a OBJT_SG VM object. It sets the object's cache mode to VM_CACHE_WC (if the arch supports that). 2) When userland wants to map the thing it does a device mmap() with a proper length and a file offset that is a cookie for the thing. The device driver's d_mmap_single() recognizes the magic file offset and returns the thing's VM object. Since the mapping info is now part of a normal object mapping, it will go away via munmap(), etc. The driver no longer has to do weird gymnastics to invalidate mappings from its device pager as transient mappings are no longer stored in the device pager. 3) When the driver wants to map the thing into the kernel, it can use vm_map_find() to insert the thing's VM object into kernel map. And I think that is all there is to it. I need to test this somehow to make sure though, and make sure this meets the needs of Robert and Nvidia. -- John Baldwin ___ 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: Question about adding flags to mmap system call / NVIDIA amd64 driver implementation
On Thu, 2009-04-30 at 17:36 -0400, John Baldwin wrote: On Tuesday 28 April 2009 7:58:57 pm Julian Elischer wrote: Robert Noland wrote: On Tue, 2009-04-28 at 16:48 -0500, Kevin Day wrote: On Apr 28, 2009, at 3:19 PM, Julian Bangert wrote: Hello, I am currently trying to work a bit on the remaining missing feature that NVIDIA requires ( http://wiki.freebsd.org/NvidiaFeatureRequests or a back post in this ML) - the improved mmap system call. you might check with jhb (john Baldwin) as I think (from his p4 work) that he may be doing something in this area in p4. After some promptings from Robert and his needs for Xorg recently I did start hacking on this again. However, I haven't tested it yet. What I have done so far is in //depot/user/jhb/pat/... and it does the following: 1) Adds a vm_cache_mode_t. Each arch defines the valid values for this (I've only done the MD portions of this work for amd64 so far). Every arch must at least define a value for VM_CACHE_DEFAULT. 2) Stores a cache mode in each vm_map_entry struct. This cache mode is then passed down to a few pmap functions: pmap_object_init_pt(), pmap_enter_object(), and pmap_enter_quick(). Several vm_map routines such as vm_map_insert() and vm_map_find() now take a cache mode to use when adding a new mapping. 3) Each VM object stores a cache mode as well (defaults to VM_CACHE_DEFAULT). When a VM_CACHE_DEFAULT mapping is made of an object, the cache mode of the object is used. 4) A new VM object type: OBJT_SG. This object type has its own pager that is sort of like the device pager. However, instead of invoking d_mmap() to determine the physaddr for a given page, it consults a pre-created scatter/gather list (an ADT from my branch for working on unmapped buffer I/O) to determine the backing physical address for a given virtual address. 5) A new callback for device mmap: d_mmap_single(). One of the features of this is that it can return a vm_object_t to be used to satisfy the mmap() request instead of using the device's device pager VM object. 6) A new mcache() system call similar to mprotect(), except that it changes the cache mode of an address range rather than the protection. This may not be all that useful really. Given all this, a driver could do the following to map a thing as WC in both userland and the kernel: 1) When it learns about a thing it creates a SG list to describe it. If the thing consists of userland pages, it has to wire the pages first. The driver can use vm_allocate_pager() to create a OBJT_SG VM object. It sets the object's cache mode to VM_CACHE_WC (if the arch supports that). 2) When userland wants to map the thing it does a device mmap() with a proper length and a file offset that is a cookie for the thing. The device driver's d_mmap_single() recognizes the magic file offset and returns the thing's VM object. Since the mapping info is now part of a normal object mapping, it will go away via munmap(), etc. The driver no longer has to do weird gymnastics to invalidate mappings from its device pager as transient mappings are no longer stored in the device pager. 3) When the driver wants to map the thing into the kernel, it can use vm_map_find() to insert the thing's VM object into kernel map. And I think that is all there is to it. I need to test this somehow to make sure though, and make sure this meets the needs of Robert and Nvidia. I think this sounds pretty good... I need to get my perforce foo up to speed so I can try it out... robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: ACPI-fast default timecounter, but HPET 83% faster
On Thu, 30 Apr 2009 08:46:41 -0400 John Baldwin j...@freebsd.org wrote: On Sunday 26 April 2009 10:27:42 pm Garrett Cooper wrote: Why's the default ACPI-fast? For power-saving functionality or because of the `quality' factor? What is the criteria that determines the `quality' of a clock as what's being reported above (I know what determines the quality of a clock visually from a oscilloscope =])? I suspect that the quality of the HPET driver is lower simply because no one had measured it previously and HPET is newer and less proven. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/acpica/acpi_hpet.c shows some of the history behind the decision. Apparently it used to be slower but it was hoped it would get faster as systems supported it better. I guess that's happening now. -- Bruce Cran ___ 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: SoC2009: libpkg, pkg tools rewrite
Hi, On Sat, Apr 25, 2009 at 03:20:59PM -0400, David Forsythe wrote: This summer I'll be working on creating a package library and using that library to rewrite the pkg tools. A package library has been discussed and even started before, but FreeBSD still does not have one. This summer I'd like to get enough of the library done to atle ast have a new set of pkg tools completed with the current features, but ideally I'd like to get far enough to splice in some of the ideas I have for new features. Since I've already done most of the work on this already, please, please, please, don't ignore what I have done. I know that it is not perfect, and that it is now five plus years out of date. But I have covered half of the bullet points on your to-do list already. The code is at http://sourceforge.net/projects/fpkg and some README stuff is at http://fpkg.sourceforge.net/ Some things which I think are critical: 1. The library needs a global package manager. This needs to perform all of the tasks, and it should ideally do this through a task queue (which I didn't implement). See the lib/lib.h header in FreePKG. 2. The package manager must be able to separate out a structure of variables which can be determined without opening the +CONTENTS file. This must also include a package state, and the package manager must move these package headers from state to state. 3. There needs to be proper depends handling in the packages, so that we can maintain the correct dependency graph. This is vital for upgrading. This means adding @libdep and @filedep types to the package file. 4. bsd.port.mk should do everything through the tools. It should have no knowledge of the contents of /var/db/pkg. These are all done, to some degree in the code. The mistakes I made: 1. I made the file-pkg database to sensitive. If there is a miss it rebuilds the database for scratch - it should do a search through the +CONTENTS files and only rebuild it if there was a hit (meaning the database was wrong). 2. There needs to be a pkgname and origin database, which can be loaded at startup to prime the package manager. The dependency graph should also be stored in a database. These should be rebuilt if any directory in /var/db/pkg has a mtime later than the database (so could the file database). 3. There needs to be a set of flags which indicate how a package got installed (as a dependency or by the user), and if it has been upgraded in-place and might have old leftover libraries. These could go in +CONTENTS. In addition I also began the design of a new on disk package format. This was back when there was a group called openpackages which was trying to standardize ports/packages between the BSDs. In particular it has some ideas on package signing, which is an often requested feature. http://people.freebsd.org/~reg/opdesign.html Regards, -Jeremy -- FreeBSD - Because the best things in life are free... http://www.freebsd.org/ ___ 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: NetBSD 5.0 statistics
On Apr 30, 2009, at 12:32 PM, Robert Watson wrote: On Thu, 30 Apr 2009, Oliver Pinter wrote: Is the FreeBSD's FS management so slow? http://www.netbsd.org/~ad/50/img15.html Or so big is the difference between the two cpu scheduler? Also, there's a known and serious performance regression in CAM relating to tgged queueing, and the generic disk sort routine, introduced 7.1, which will be fixed in 7.2. I can't speak more generally to the benchmarks -- we'll need to run them in a controlled environment and see if we can reproduce the results. Also :-) I recall that our make -j X actually limits the number of make processes/jobs to X. I don't know anything about build.sh, so I don't know if our make is at all being involved, but it would be good to know how the load varies per OS. We may simply have less parallelism in the build. -- Marcel Moolenaar xcl...@mac.com ___ 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: C99: Suggestions for style(9)
In message: 20090430233648.ga95...@keira.kiwi-computer.com Rick C. Petty rick-freebsd2...@kiwi-computer.com writes: : On Thu, Apr 30, 2009 at 09:02:26AM -0600, M. Warner Losh wrote: : : This is the biggest one, and I think it may be too soon. Also, we : need to be careful on the initialization side of things because we : currently have a lot of code that looks like: : : : struct foo *fp; : struct bar *bp; : : fp = get_foo(); : if (!fp) return; : bp = fp-bp; : : this can't easily be translated to the more natural: : : struct foo *fp = get_foo(); : struct bar *bp = fp-bp; : : since really you'd want to write: : : struct foo *fp = get_foo(); : if (!fp) return; : struct bar *bp = fp-bp; : : which isn't legal in 'C'. : : I thought we were talking about C99, in which case this is perfectly legal. : I certainly use it all the time in my C99 code. Hmmm, looks like that was added. That's ugly as C++... : And I thought this was the point of this discussion, to be able to declare : variables when you first use them. That's one of the proposed changes, which I think is a mistake and would cause the most code churn. And it isn't one of the items that's being discussed: only moving variables into inner scopes is on the table... Warner ___ 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: C99: Suggestions for style(9)
M. Warner Losh schrieb: In message: 20090428114754.gb89...@server.vk2pj.dyndns.org Peter Jeremy peterjer...@optushome.com.au writes: : Maybe using all of these changes is a bit too big change at once, but : I'd like some of them applied to style(9). So, please consider the : proposed changes individually and not a as a all-or-nothing package. : : One area you do not address is code consistency. Currently, the : FreeBSD kernel (and, to a lesser extent, userland) are mostly style(9) : compliant - ie the entire codebase is mostly written in the same : style. Whilst you may not like it (and I don't know that anyone : completely agrees with everything in style(9)), it does mean that : the code is consistent. : : Changing style(9) in a way that is not consistent with current code : means that either existing code must be brought into line with the : new standard - which incurs a one-off cost - or the code base becomes : split into old and new style - incurring an ongoing maintenance : cost as maintainers switch between styles. Both approaches incur a : risk of introducing new bugs. : : Note that I'm not saying that style(9) can never be changed, I'm just : saying that any change _will_ incur a cost and the cost as well as : the potential benefits need to be considered. This is my biggest worry about changing style(9) quickly. We don't want needless churn in the tree for just style changes since it makes it harder to track bug fixes into the past. I'm not saying that all the code has to be changed at once, but no new code of the old style should be added. E.g. you should never use KR declarations when adding a new function. And if you are going to make a big change somewhere, then it is sensible to use the new style. : [Reduce declaration scope as far as possible, initialise variables where : they are declared, sort by name] : : Whilst my personal preference is for the style suggested by Christoph : (and I generally agree with the points he makes), this is also the : change that incurs the biggest stylistic change. This is not a change : that can be practically retrofitted to existing code and therefore its : implementation would result in a mixture of code styles - increasing : the risk of bugs due to confusion as to which style was being used. I : am not yet sure whether the benefits outweigh the costs, This is the biggest one, and I think it may be too soon. Also, we This is the reason, why I explicitly mentioned, that the proposed changes should be examined independently. need to be careful on the initialization side of things because we currently have a lot of code that looks like: struct foo *fp; struct bar *bp; fp = get_foo(); if (!fp) return; bp = fp-bp; this can't easily be translated to the more natural: struct foo *fp = get_foo(); struct bar *bp = fp-bp; since really you'd want to write: struct foo *fp = get_foo(); if (!fp) return; struct bar *bp = fp-bp; which isn't legal in 'C'. However, we have enough where this isn't You're mistaken, this is perfectly legal C. See ISO/IEC 9899:1999 (E) ยง6.8.2:1. In short: you can mix statements and declarations. the case that it should be allowed. We should separate the initialization part of this from the scope part of this too. The initialization part is already leaking into the code, while instances of the scope restriction is rarer. Sorry, I do not understand these sentences. : [Don't parenthesize return values] : Removed, because it does not improve maintainability in any way. : : This change could be made and tested mechanically. But there is : no justification for making it - stating that the existing rule : is no better than the proposed rule is no reason to change. I'm fine with this. : [No KR declarations] : Removed, because there is no need to use them anymore. : : Whilst this is a change that could be performed mechanically, there : are some gotchas relating to type promotion (as you point out). : The kernel already contains a mixture of ANSI KR declarations and : style(9) recommends using ANSI. IMHO, there is no need to make this : change until all KR code is removed from FreeBSD. I'm fine with this change. : [ Don't insert an empty line if the function has no local variables.] : : This change could be made and tested mechanically. IMHO, this change : has neglible risk and could be safely implemented. I'm fine with this change. Would you commit these three proposals? : +.Sh LOCAL VARIABLES : : Last, but definitely not least, I added this paragraph about the use of : local variables. This is to clarify, how today's compilers handle : unaliased local variables. : : Every version of gcc that FreeBSD has ever used would do this for : primitive types when optimisation was enabled. This approach can : become expensive in stack (and this is an issue for kernel code) when : using
Re: C99: Suggestions for style(9)
M. Warner Losh schrieb: In message: 20090430233648.ga95...@keira.kiwi-computer.com Rick C. Petty rick-freebsd2...@kiwi-computer.com writes: : On Thu, Apr 30, 2009 at 09:02:26AM -0600, M. Warner Losh wrote: : : This is the biggest one, and I think it may be too soon. Also, we : need to be careful on the initialization side of things because we : currently have a lot of code that looks like: : : : struct foo *fp; : struct bar *bp; : : fp = get_foo(); : if (!fp) return; : bp = fp-bp; : : this can't easily be translated to the more natural: : : struct foo *fp = get_foo(); : struct bar *bp = fp-bp; : : since really you'd want to write: : : struct foo *fp = get_foo(); : if (!fp) return; : struct bar *bp = fp-bp; : : which isn't legal in 'C'. : : I thought we were talking about C99, in which case this is perfectly legal. : I certainly use it all the time in my C99 code. Hmmm, looks like that was added. That's ugly as C++... I do not think, this is ugly. On the contrary, it aids maintainability, because it reduces the scope of variables. Also quite some variables are only initialised and not changed afterwards, so it's nice to have the declaration and the only assignment in a single place. IMO this is a quite natural style, because you don't have anything in the code, before it is needed: Get the first pointer; if something is wrong, bail out; get the second pointer - the second pointer does not (textually) exist before it is needed. : And I thought this was the point of this discussion, to be able to declare : variables when you first use them. That's one of the proposed changes, which I think is a mistake and would cause the most code churn. And it isn't one of the items that's being discussed: only moving variables into inner scopes is on the table... No, this is not what I intended. The idea is to limit the scope of local variables as much as is sensible. Maybe I should have been more explicit. On the other hand, I also did not mention that it is just about moving to the start of inner block statements. Christoph ___ 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
