Alexander Best schrieb:
i'm running something similar to this pseudo-code in an app of mine:
for (i=0 )
fprintf(stdout,"TEXT %d\r", int);
what's really strange is that if i print to stdout the output isn't very
clean. the cursor jumps randomly within the output (being 1 line). if i prin
Stanislav Sedov schrieb:
On Sun, 17 May 2009 14:36:03 +0200
Christoph Mallon mentioned:
Aliasing behavior is stritcly described in
ISO C99 standard, so there's a good point to enforcing strict-aliasing clear
code in our kernel.
If you like this addition because of this reason, I ha
Stanislav Sedov schrieb:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 01 May 2009 14:02:50 +0200
Christoph Mallon mentioned:
[Don't parenthesize return values]
Removed, because it does not improve maintainability in any way.
This change could be made and tested mechanically.
Stanislav Sedov schrieb:
On Fri, 01 May 2009 08:20:20 -0600 (MDT)
"M. Warner Losh" mentioned:
It is a debugging aid, but one of dubious value for a far more
fundamental reason:
return;
will break any macro.
You can use variadic marcos in this case if the piece of code debugged
M. Warner Losh schrieb:
In message: <49fcafa2.60...@gmx.de>
Christoph Mallon writes:
: Julian Elischer schrieb:
: >> Christoph Mallon wrote:
: >>>> K&R code should be changed as part of related changes if possible.
: >>>> A sweep to
Julian Elischer schrieb:
Christoph Mallon wrote:
K&R code should be changed as part of related changes if possible.
A sweep to change a whole file is probably also ok.
changing them one at a time is probably not ok.
But this is what actually is practiced.
You still did not answer my ques
Julian Elischer schrieb:
Christoph Mallon wrote:
I'm talking about an optimized build - no matter what the style of the
original source was, you will have a hard time debugging it.
but by removing -Ox I can debug it and you can't
Declaring variables earlier does not magi
Julian Elischer schrieb:
Christoph Mallon wrote:
Julian Elischer schrieb:
Christoph Mallon wrote:
So at the one hand you argue that hunting things is bad, but at the
same time you prefer it? I am confused.
well, I won't hold your problems against you.. :-)
It is sad that you are
Julian Elischer schrieb:
David Malone wrote:
As I said, the point of a style guide is consistency. Changing it
doesn't promote consistency, so there needs to be a good reason for
the change, rather than a good reason not to change. In my opinion,
there isn't a strong reason. Similarly for parens
Julian Elischer schrieb:
Christoph Mallon wrote:
variables. Sorting them in a beneficial way for space efficiency is
better left to them (and it is a rather trivial thing to do). Also you
cannot control if more spill slots have to be inserted or some values
do not live in memory at all, so
Julian Elischer schrieb:
David Malone wrote:
-Do not put declarations
-inside blocks unless the routine is unusually complicated.
+Prefer declaring loop iterators in the for-statement to limit their
scope.
I usually don't like this style - I like being able to review the
variables used in a f
David Malone schrieb:
+When the value is not supposed to change in the function, make the
variable
+const.
Using const seems sensible, and a good example of a time where
declaring at initialisation makes sense.
+This makes it easier for a reader to identify the where the value of a
variable
M. Warner Losh schrieb:
In message: <20090501.081229.1359784281@bsdimp.com>
M. Warner Losh writes:
: In message: <49fa8e88.1040...@gmx.de>
: Christoph Mallon writes:
: : M. Warner Losh schrieb:
: : > In message: <20090430233648.ga95...@keira
deeptec...@gmail.com schrieb:
Well I agree with the proposed changes.
What about allowing // comments?
These are already widely used. grep shows hundreds of hits in sys/.
Probably a clause should be added to style(9) to allow them
"officially", but not right now.
Christoph
M. Warner Losh schrieb:
In message: <49fa8d73.6040...@gmx.de>
Christoph Mallon writes:
: M. Warner Losh schrieb:
: > In message: <20090428114754.gb89...@server.vk2pj.dyndns.org>
: > Peter Jeremy writes:
: > : >> +.Sh LOCAL VARIABLES
: >
Marius Strobl schrieb:
On Fri, May 01, 2009 at 01:37:23PM +0200, Christoph Mallon wrote:
Marius Strobl schrieb:
On Sun, Apr 26, 2009 at 09:02:36AM +0200, Christoph Mallon wrote:
return with parentheses:
Removed, because it does not improve maintainability in any way. There
is no source for
Daniel Eischen schrieb:
+1 for leaving style(9) alone.
Have you looked at all the proposed changes? I ask to consider them
individually.
Christoph
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebs
Julian Elischer schrieb:
Christoph Mallon wrote:
You are mistaken. Re-read the "if": It already contains a "return;" as
then-part. The declaration of "bp" has no relation to the "if".
In fact this is very good: "bp" can only be used after t
Zaphod Beeblebrox schrieb:
On Fri, May 1, 2009 at 4:30 AM, Julian Elischer wrote:
As an old-fart I have found many cases where what I thought was
a silly style rule, turned out to save my work in some way.
Christoph Mallon wrote:
struct foo *fp;
struct bar *bp;
fp = get_foo
Peter Jeremy schrieb:
On 2009-Apr-26 09:02:36 +0200, Christoph Mallon wrote:
as some of you may have noticed, several years ago a new millenium
started and a decade ago there was a new C standard.
Your implication that FreeBSD is therefore a decade behind the times
is unfair. Whilst the C99
Julian Elischer schrieb:
Christoph Mallon wrote:
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
Marius Strobl schrieb:
On Sun, Apr 26, 2009 at 09:02:36AM +0200, Christoph Mallon wrote:
return with parentheses:
Removed, because it does not improve maintainability in any way. There
is no source for confusion here, so the rule even contradicts the rule,
which states not to use redundant
Julian Elischer schrieb:
As an old-fart I have found many cases where what I thought was
a silly style rule, turned out to save my work in some way.
Christoph Mallon wrote:
struct foo *fp;
struct bar *bp;
fp = get_foo();
if (!fp) return;
bp = fp->bp;
this can'
Roman Divacky schrieb:
I like the part about using as many variables as possible because
of documentation and performance enhancements. I tend to like
the other changes as well..
This is not about using as many variables as possible. The goal is to
use as many variables as you have logically d
M. Warner Losh schrieb:
In message: <20090430233648.ga95...@keira.kiwi-computer.com>
"Rick C. Petty" 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 in
M. Warner Losh schrieb:
In message: <20090428114754.gb89...@server.vk2pj.dyndns.org>
Peter Jeremy 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
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.
T
David Schultz schrieb:
On Thu, Feb 26, 2009, Christoph Mallon wrote:
David Schultz schrieb:
As for gcc's math builtins, most of them are buggy. They fail to
respect the dynamic rounding mode, fail to generate exceptions
where appropriate, fail to respect FENV_ACCESS and other pragmas
David Schultz schrieb:
On Thu, Feb 26, 2009, Christoph Mallon wrote:
David Schultz schrieb:
On Thu, Feb 26, 2009, Ed Schouten wrote:
One of the reasons why we can't compile the base system yet, is because
some applications in the base system (keyserv, newkey, chkey, libtelnet)
won'
Christoph Mallon schrieb:
David Schultz schrieb:
On Thu, Feb 26, 2009, Ed Schouten wrote:
One of the reasons why we can't compile the base system yet, is because
some applications in the base system (keyserv, newkey, chkey, libtelnet)
won't compile, because a library they depend (li
David Schultz schrieb:
On Thu, Feb 26, 2009, Ed Schouten wrote:
One of the reasons why we can't compile the base system yet, is because
some applications in the base system (keyserv, newkey, chkey, libtelnet)
won't compile, because a library they depend (libmp)on has a function
called pow(). By
Aniruddha Bohra schrieb:
On Wed, Feb 11, 2009 at 8:25 AM, Andriy Gapon wrote:
on 10/02/2009 22:43 Aniruddha Bohra said the following:
You can see Click: http://read.cs.ucla.edu/click/
It does not run on FreeBSD >4.
I have an old diff which builds on the work by Marko Zec and Bruce
Simpson, th
Christian Peron schrieb:
On Wed, Feb 04, 2009 at 03:54:41PM +0100, Christoph Mallon wrote:
[..]
Yes, function arguments are considered being read. The problem is
different here: mtod() should be a macro, but the macro declaration was
missing (*cough* hacked build process *cough*). So the
Christian Peron schrieb:
I started following up on this and ran into an issue for these:
sys/net/bpf_buffer.c:133: warning: variable 'dst' is never read
sys/net/bpf_buffer.c:134: warning: variable 'count' is never read
sys/net/bpf_buffer.c:142: warning: variable 'dst' is never read
/*
* Scatt
Max Laier schrieb:
On Monday 02 February 2009 20:42:32 Christoph Mallon wrote:
A small disclaimer: There might be some false positives due to errors
which are caused by HEAD sources in combination with my installed 7.x
headers plus a hacked up build process. Also some warnings are the
result
Andrew Thompson schrieb:
This is helpful, my only nit would be to run it through sort. :)
Fixed (:
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers
Hi,
I compiled a list of all local variables in src/sys/ (r188000), which
are only written to, but never read. This is more than the GCC warning,
which only complains about variables, which are only declared (and maybe
initialised) and not used otherwise. In contrast this list contains
variab
Lukasz Jaroszewski schrieb:
2009/1/26 Hans Petter Selasky :
On Monday 26 January 2009, Lukasz Jaroszewski wrote:
Hi,
after opening /dev/ad4 with success for O_RDWR, I am getting [EINVAL]
from write(2), which according to man 2 write, means
`` [EINVAL] The pointer associated with
Oliver Fromme schrieb:
> cut -f 2,7 -d '|' |
> grep -E '^f' |
> cut -f 2 -d '|' |
> sort -u > filelist
It's unclear why there are two "cut" commands. The 7th
field isn't used at all. Also, the -E option to grep
After the first cut the s
Christoph Mallon schrieb:
@@ -1340,7 +1340,8 @@
}
TAILQ_INSERT_HEAD(&bufqueues[bp->b_qindex], bp, b_freelist);
/* buffers with junk contents */
-} else if (bp->b_flags & (B_INVAL | B_NOCACHE | B_RELBUF) ||
+} else if (bp->b_flags &
Sadly I got no response about the panic problem so far. I investigated
further and I came to the conclusion, that there are at least two
problems/bugs in brelse(). Here are my findings. All lines refer to
sys/kern/vfs_bio.c at r183754, which is the most recent version of this
file.
Below is t
xorquew...@googlemail.com schrieb:
Hello.
I have some C code that's compiled with -fexceptions using
the lang/gnat-gcc43 port. I'm on 6.4-RELEASE-p2.
A function c_function in the C code takes a callback as an argument.
I'm passing this function the address of a function ext_function defined
in
Danny Braniss schrieb:
some facts:
#include
int
main()
{
printf("%s\n", strerror(2));
return 0;
}
1- it works fine on i386
2- it bombs on amd64
3- with a local strerror.c (instead of the one in libc)
works fine
so, there is something realy wrong goin
Garrett Cooper schrieb:
On Fri, Jan 16, 2009 at 2:21 AM, Christoph Mallon
wrote:
Christian Kandeler schrieb:
On Friday 16 January 2009 09:53, Christoph Mallon wrote:
int
main() {
int mib[4];
size_t len;
if (sysctlnametomib("kern.ipc.shmmax", mib,
Garrett Cooper schrieb:
Ok, I just installworld'ed, recompiled the program with the
following modifications, and I still get segfaults. And the question
of the night is: why amd64 on a VERY recent CURRENT?
I'm going to try the same app on an amd64 freebsd VMware instance
with RELENG_7.
Christian Kandeler schrieb:
On Friday 16 January 2009 09:53, Christoph Mallon wrote:
int
main() {
int mib[4];
size_t len;
if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) {
printf("Errno: %d\n", errno);
Garrett Cooper schrieb:
On Fri, Jan 16, 2009 at 12:58 AM, Garrett Cooper wrote:
On Fri, Jan 16, 2009 at 12:57 AM, Christoph Mallon
wrote:
Garrett Cooper schrieb:
Good point. I modified the source to do that.
Thanks,
-Garrett
You should reply to all so the discussion stays on the list
Garrett Cooper schrieb:
Hi amd64 and Hackers,
Uh, I'm really confused why 1) this error (errno => ENOMEM) would
occur when I have more than enough free memory (both on x86 and amd64)
and 2) why strerror would segfault in the call to errx in the attached
sourcefile on amd64 only. Not initializ
Yoshihiro Ota schrieb:
Try GEOM Cache(gcache).
Just a side note: gcache does not seem to have any documentation. "man
gcache" is unsuccessful, geom(8) does not mention it (geom and gcache
are the same hardlinked binary). Is there information about it somewhere?
__
Hi,
I observe a failed assertion in the VFS regarding a buffer. I
investigated a bit and now I want to present my findings and I have a
question:
Assume I have a buffer with
b_iocmd = BIO_WRITE
b_ioflags = BIO_ERROR
b_error = EIO
b_flags = B_NOCACHE
passed to brelse() in kern/vf
rihad schrieb:
$ mkfifo /var/tmp/foo
$ buffer -i /var/tmp/foo# misc/buffer
# in another console:
$ echo hi > /var/tmp/foo
buffer prints hi and exits. I want it to keep reading and printing
indefinitely.
Further experimentation revealed that I need two writers: one dummy
w
Garrett Cooper schrieb:
On Fri, Dec 5, 2008 at 1:11 AM, Christoph Mallon
<[EMAIL PROTECTED]> wrote:
Garrett Cooper schrieb:
(I feel like I'm getting off on a bikeshed topic, but...)
1. What dialect of C was it defined in? Is it still used in the
standard dialect (honestly, this i
Garrett Cooper schrieb:
(I feel like I'm getting off on a bikeshed topic, but...)
1. What dialect of C was it defined in? Is it still used in the
standard dialect (honestly, this is the first time I've ever seen it
before, but then again I am a younger generation user)?
Dialect? The ! operator
Won De Erick schrieb:
- Original Message
From: Rink Springer <[EMAIL PROTECTED]>
On Mon, Dec 01, 2008 at 09:38:51AM +0100, Christoph Mallon wrote:
Userland is not allowed to write to ports. That's the bus error you see.
Also without a call to the exit syscall at the e
Won De Erick schrieb:
Hello,
I was trying the assembly language program that is specified in the following
document (p24) to set, reset the built-in watchdog timer for the Boser Box.
http://www.boser.com.tw/manual/HS-7001v1.1.pdf
I then installed nasm in FreeBSD 6.2, and added the following l
Alexander Leidinger schrieb:
Quoting Christoph Mallon <[EMAIL PROTECTED]> (from Thu, 27 Nov
2008 21:39:45 +0100):
cparser is a C compiler, which can parse C89 and C99 as well as many
GCC and some MSVC extensions. The handled GCC extensions include
__attribute__, inline assembler, co
Max Laier schrieb:
On Thursday 27 November 2008 21:39:45 Christoph Mallon wrote:
A few days ago libFIRM[1] and cparser were added to the ports tree. If
you want to see, what other compilers besides GCC have to offer, this
might be of interest for you. libFIRM is a modern optimizing
intermediate
Eygene Ryabinkin schrieb:
Christoph, good day.
Thu, Nov 27, 2008 at 09:39:45PM +0100, Christoph Mallon wrote:
A few days ago libFIRM[1] and cparser were added to the ports tree. If
you want to see, what other compilers besides GCC have to offer, this
might be of interest for you. libFIRM is a
A few days ago libFIRM[1] and cparser were added to the ports tree. If
you want to see, what other compilers besides GCC have to offer, this
might be of interest for you. libFIRM is a modern optimizing
intermediate representation (IR) library. cparser is a C compiler
providing many useful warni
59 matches
Mail list logo
