C99: Suggestions for style(9)
Hi hackers@,
as some of you may have noticed, several years ago a new millenium
started and a decade ago there was a new C standard. HEAD recently
switched to C99 as default (actually gnu99, but that's rather close). So
it's finally time to re-examine wether style(9) needs to be accomodated.
The diff with the proposed changes is attached. Below are the changes
with some further explanations. They are in the order as they appear in
style(9).
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.
-Do not put declarations
-inside blocks unless the routine is unusually complicated.
+Prefer declaring loop iterators in the for-statement to limit their scope.
.Bd -literal
- for (; cnt 15; cnt++) {
+ for (int cnt = 0; cnt 15; cnt++) {
[...]
-When declaring variables in functions declare them sorted by size,
-then in alphabetical order; multiple ones per line are okay.
+When declaring variables in functions declare them sorted in alphabetical
order;
+prefer one declaration per line, especially when pointer declarators or
+initializations are involved.
If a line overflows reuse the type keyword.
.Pp
-Be careful to not obfuscate the code by initializing variables in
-the declarations.
-Use this feature only thoughtfully.
-DO NOT use function calls in initializers.
+Prefer initializing variables right at their declaration.
+When the value is not supposed to change in the function, make the variable
+const.
+This makes it easier for a reader to identify the where the value of a variable
+originates.
+Do not reuse the same variable in a different context, declare a new variable.
.Bd -literal
- struct foo one, *two;
- double three;
- int *four, five;
- char *six, seven, eight, nine, ten, eleven, twelve;
+ struct foo *bar;
+ struct foo baz = { 42, qux };
- four = myfunction();
+ FILE *const f = fopen(name, r);
+ if (f == NULL)
+ err(Failed to open file);
+ /* We can safely assume that f is not changed anymore, even if the
+* function is a hundred lines long */
This change is to reduce the scope of local variables. For reasons why
this does not cost anything in terms of stack space, please see the last
change, which adds explanations about local variables.
Smaller scopes and distinct variables for distinct contexts make it
easier for readers of the code to identify the def-use-chains of
variables, because there are less places with assignments to a variable
and the scope is smaller. Also, when a variable is initialised right at
its declaration and is not supposed to change, you can emphasize this by
making it const.
I looked at older discussions regarding this topic and identified
several concerns, which were raised. I'll address them below:
- It does not add anything to the language.
Well, yes, just like if, do, for, goto, the comma operator, compound
assignment (+=, ...), ++/-- and many other things. All you need to be
Turing complete is lambda calculus - there hardly can be less syntax.
But, like all mentioned constructs, it makes the code more concise.
- It leads to sloppy code. You could reuse another variable or should
think again whether you really need this variable.
Reusing variables in different contexts is error prone and bad for
maintainability. You could reuse a variable, which is not as dead as you
thought. More local variables cost nothing, especially no stack space,
see the last proposed changed below. It is good to use more local
variables, because it gives the reader a name, which carries
information. Also it makes it easier for a reader (and the compiler!) to
identify, which expressions are the same. You could repeat
foo-long_name-even_longer_name[2 * i + 1] five times or just declare a
local variable and cache the value to make it easier to read.
It also enables the compiler to produce better warnings: If you declare
a new variable, it is not initialised and if you do not initialise it on
all paths before a use, the compiler will warn you. But if you reuse an
older variable, it is already initialised by its former uses and so you
get no warning, but operate on garbage values (the old value from the
previous use).
So it does not lead to slopyy code, but better code, which is easier to
comprehend, the compiler can better help you to prevent bugs, and as a
side effect the compiler can produce better code (aliasing is a major
problem for common subexpression elimination).
- You can determine the stack usage with all the variable declarations
at the top.
This is not true. There is no relation between the declared variables
and the stack used. Especially, more stack than suggested by the
declarations can be used due to various optimisations - less space can
be used, too, of course.
- It is harder to find
Re: SoC2009: libpkg, pkg tools rewrite
On Sat, Apr 25, 2009 at 9:20 PM, David Forsythe dfors...@freebsd.org wrote: Hi, I'm David Forsythe, 3rd year student at the University of Maryland, College Park. For SoC2008 I worked on added parallel build support and database locks to ports. I've been using FreeBSD for a while, and have taken particular interest in ports and packages. 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 atleast 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. Here's the wiki page: http://wiki.freebsd.org/SoC2009DavidForsythe Dave Hi, It'll be nice if libpkg can deal with all the infos in the INDEX with an elegant API. You have to read the packages names in the INDEX for `pkg_version -I` but maybe other tools will enjoy to get other infos (especially the one line description, the categories and the run time dependencies). So basically, an API which understand give me all the packages names you have in the INDEX, give me the description for _this_ package, give me all the names plus the categories, give me... Regards, Julien Laffaye ___ 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
GSoC - SeND
Hi all, I am Ana Kukec, a research assistant and a PhD student at University of Zagreb. I will be working on the IPv6 Secure Neighbor Discovery (SeND - rfc3971, rfc4861) - the implementation of native kernel APIs for FreeBSD, within GSoC, with my mentor Bjoern Zeeb. More informations will be provided on http://wiki.freebsd.org/SOC2009AnaKukec. Regards, Ana ___ 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
Ext2fs DVD+RW
Improved Ext2fs: What a great idea. I like trying different Unix flavours, and Ext2fs is the only filesystem they all understand. I put all my data on a separate Partition formatted Ext2, and every so often I'm glad: Like the recent occasion when the NetBSD Boot Selector altered something and prevented FreeBSD from starting, leaving me with no alternative but to reinstall. Also, under Linux, you can use Ext2fs on DVD+RW. Plain DVD-RW is unsuitable because it uses Superblocks of 16*2048 bytes, but CD-RW should be okay. Currently you can't do this under FreeBSD, probably because CD and DVD use 2048-byte Sectors, and FreeBSD wants 512-byte. Somebody said you can put UFS on DVD+RW, but I couldn't get that to work. So possibly Ext2fs would be a viable alternative to UDF, though I don't know enough about Filesystems myself to tell whether this idea has some enormous drawback. Yours truly: Frank Mitchell From: Aditya Sarawgi sarawgi.adi...@gmail.com I'm Aditya Sarawgi from India. I will be working on FreeBSD's ext2fs as a part of this year's summer of code program. I will be improving the current implementation and I will also rewrite parts of ext2fs under GPL. My mentor is Ulf Lilleengen. For more details you can visit http://wiki.freebsd.org/SOC2009AdityaSarawgi Cheers, Aditya Sarawgi ___ 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
cd9660 Lowercasing
I've developed a CD/DVD Backup Utility using the Enhanced Volume Descriptor
specified in ISO9660:1999. It doesn't have Rock Ridge yet, so the first thing
you notice on mounting is the automatic Lowercase, which interferes with
Backup Verification using diff -qr. There's a simple solution using
the gens mount option, which has Case Preservation as a side-effect, but
it's still annoying.
There must be some reason behind it, because NetBSD and Linux have a similar
feature, with options to disable it like: nomaplcase and map=off. But
their manpages make it look like a throwback to MS-DOS, and a time when all
filenames were accessed from the Primary Volume Descriptor. By default you
can't have filenames in ASCII using the Supplementary or Enhanced Volume
Descriptors either.
I think I tracked this feature down to cd9660_util.c, in Function isofntrans,
around Line 200:
for (; infn != infnend; ) {
infn += isochar(infn, infnend, joliet_level, c, clen, flags, handle);
if (!original !joliet_level c = 'A' c = 'Z')
c += ('a' - 'A');
else if (!original c == ';') {
outp -= (d == '.');
break;
}
d = c;
while(clen--)
*outp++ = c (clen 3);
}
This only alters ASCII characters. Accented uppercase letters from the top
half of ISO8859-1 are unaffected. And it doesn't apply to Joliet either. I
don't see the point. Why not just zap it away?
Yours Truly: Frank Mitchell
___
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
SoC 2009: Redesign the callout API
Hello, I am Prashant Vaibhav, a 22 year old Indian guy (undergrad from Germany) and I'm a Google Summer of Code participant for 2009. My work will be focused on improving the callout/timeout API in the kernel. It was inspired by the tickless kernel feature present in XNU and Linux (since recent releases), and discussions made on the mailing lists a few years back about problems with the current implementation. Basically, the callout API will be redesigned to use opaque 'ticks' instead of explicitly x/HZ, and provide for certain additional features (like specifying a time range while arming). Beneath the hood, the implementation will be completely redesigned to use more efficient method of storing the callout list, and using any available timer in a hardware-independent way. It will then be extended to support deadline mode on capable systems (ie. dynamic HZ). This means for machines having an HPET or similar deadline-capable timer with a long range, the kernel will be completely tickless. On other machines with only a PIT, the 'ticks' could be as infrequent as a few times a second to once every 2 seconds, instead of 100 Hz. The major advantages are that the usage of hardware-dependent ticks and abstracting out timer hardware will make higher-resolution callouts possible, and in turn, making the kernel tickless will allow for better power savings, more efficient usage of CPU clock cycles, and better performance in virtual machines. More details can be found at the wiki page: http://wiki.freebsd.org/SOC2009PrashantVaibhav Best regards, Prashant Vaibhav ___ 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
SoC 2009: Application-Specific Audit Trails
Hi people, my name is Ilias Marinos and I am an undergraduate student at Computer Engineering Informatics Department at University of Patras, Greece. I was accepted to work this summer with my mentor Robert Watson, on designing and impelementing an application-specific audit system, as part of the TrustedBSD project. More information about me and my project can be found at: http://wiki.freebsd.org/IliasMarinos Regards, Ilias Marinos -- echo Sysadmin know better bash than english. | sed s/min/mins/ \ | sed 's/better bash/bash better/' ___ 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
ACPI-fast default timecounter, but HPET 83% faster
Dear hackers,
While fiddling with the sysctl kern.timecounter.hardware, I found out that on
my system HPET is significantly faster than ACPI-fast. Using the program
below I measured the number of clock_gettime() calls the system can execute
per second. I ran the program 10 times for each configuration and here are
the results:
x ACPI-fast
+ HPET
+-+
|x +|
|x +|
|x ++|
|x ++|
|x ++|
|x ++|
|A |A|
+-+
N Min MaxMedian AvgStddev
x 10822032823752823551 823397.8 509.43254
+ 10 1498348 1506862 1502830 1503267.4 2842.9779
Difference at 95.0% confidence
679870 +/- 1918.94
82.5688% +/- 0.233052%
(Student's t, pooled s = 2042.31)
System details: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz (3200.02-MHz
686-class CPU), Gigabyte P35-DS3R motherboard running i386 -CURRENT updated
today.
Unfortunately I only have one system with a HPET timecounter, so I cannot
verify these results on another system. If similar results are obtained on
other machines, I think the HPET timecounter quality needs to be increased
beyond that of ACPI-fast.
Regards,
Pieter de Goeje
- 8 - clock_gettime.c - 8 --
#include sys/time.h
#include stdio.h
#include time.h
#define COUNT 100
int main() {
struct timespec ts_start, ts_stop, ts_read;
double time;
int i;
clock_gettime(CLOCK_MONOTONIC, ts_start);
for(i = 0; i COUNT; i++) {
clock_gettime(CLOCK_MONOTONIC, ts_read);
}
clock_gettime(CLOCK_MONOTONIC, ts_stop);
time = (ts_stop.tv_sec - ts_start.tv_sec) + (ts_stop.tv_nsec -
ts_start.tv_nsec) * 1E-9;
printf(%.0f\n, COUNT / time);
}
___
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 Sun, Apr 26, 2009 at 4:50 PM, Pieter de Goeje pie...@degoeje.nl wrote:
Dear hackers,
While fiddling with the sysctl kern.timecounter.hardware, I found out that on
my system HPET is significantly faster than ACPI-fast. Using the program
below I measured the number of clock_gettime() calls the system can execute
per second. I ran the program 10 times for each configuration and here are
the results:
x ACPI-fast
+ HPET
+-+
|x +|
|x +|
|x ++|
|x ++|
|x ++|
|x ++|
|A |A|
+-+
N Min Max Median Avg Stddev
x 10 822032 823752 823551 823397.8 509.43254
+ 10 1498348 1506862 1502830 1503267.4 2842.9779
Difference at 95.0% confidence
679870 +/- 1918.94
82.5688% +/- 0.233052%
(Student's t, pooled s = 2042.31)
System details: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz (3200.02-MHz
686-class CPU), Gigabyte P35-DS3R motherboard running i386 -CURRENT updated
today.
Unfortunately I only have one system with a HPET timecounter, so I cannot
verify these results on another system. If similar results are obtained on
other machines, I think the HPET timecounter quality needs to be increased
beyond that of ACPI-fast.
Regards,
Pieter de Goeje
- 8 - clock_gettime.c - 8 --
#include sys/time.h
#include stdio.h
#include time.h
#define COUNT 100
int main() {
struct timespec ts_start, ts_stop, ts_read;
double time;
int i;
clock_gettime(CLOCK_MONOTONIC, ts_start);
for(i = 0; i COUNT; i++) {
clock_gettime(CLOCK_MONOTONIC, ts_read);
}
clock_gettime(CLOCK_MONOTONIC, ts_stop);
time = (ts_stop.tv_sec - ts_start.tv_sec) + (ts_stop.tv_nsec -
ts_start.tv_nsec) * 1E-9;
printf(%.0f\n, COUNT / time);
}
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 =])?
Thanks,
-Garrett
___
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: Design and Implementation of Subsystem Support Libraries for Monitoring and Management
On Fri, Apr 24, 2009 at 6:01 PM, Gabor PALI p...@freebsd.org wrote: Hi there, I am Gabor Pali from Hungary, a PhD student at Eotvos Lorand University, Budapest and Babes-Bolyai University, Cluj-Napoca. Offically, I have been working on FreeBSD for a year, and I got a doc commit bit for my Hungarian translations and documentation work, and now I also received a ports commit bit for my further contributions to the ports tree. I have been using FreeBSD for almost eight years now, and I am interested in development of operating systems. During Summer of Code 2009, I will be working on wrapper libraries for the network and process functions to support monitoring and management applications to avoid direct use of the FreeBSD kernel memory interface. This approach would allow the kernel implementation to change and monitoring applications to be extended without breaking applications and requiring them to be recompiled. For this project, my mentor will be Oleksandr Tymoshenko (gonzo@). A more detailed version of my Summer of Code 2009 proposal can be found on the FreeBSD Wiki: http://wiki.freebsd.org/PGJSoC2009 Feel free to review and comment on it. Cheers, :g Sounds like good work to do Gabor. Good luck on the project :). Cheers, -Garrett ___ 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
GSoC - FIFO Optimizations
Hi there, My name is Zhao Shuai and I am a postgraduate from China. This summer I will work on FIFO optimization project with my mentor John Baldwin. More details on my project, visit the wiki page: http://wiki.freebsd.org/SOC2009ZhaoShuai -- Regards, Zhao ___ 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
