i sent the following message to freebsd-quaestions@ and got no answer. mybe it
is better suited for freebsd-hackers@.
hi there,
i found hundreds of the following cases in the FreeBSD src:
[...]
struct periph_driver {
periph_init_func_t init;
char
. Without named initializers, all fields until the last
non-zero one need to be explicitly present.
style(9) doesn't address it, having been written too long ago, but IMO
initializations in a C translation unit [1] should use C99's named
initializer feature, to protect against future member re-ordering
The convincing one applies to Java and C++:
if (constant.equals(object))
instead of
if (object != null object.equals(constant))
actually looks easier to read.
Though you are right about constants being pretty rare.
Your .sig is strangely appropriate...
Not my invention,
2010/5/11 Eitan Adler li...@eitanadler.com:
My proposal is simple:
require that any if statement that compares a constant to a mutable variable
be written as
if (constant == variable)
instead of
if (variable == constant)
Use const qualification. It's portable and does not require
rewriting
recommendation in style(9). Or to say it
another way, I'd be annoyed if an otherwise-correct patch was asked
to be rewritten just because the developer used (variable == constant)
instead of (constant == variable).
--
Garance Alistair Drosehn = dros...@rpi.edu
Senior Systems
don't do it
as much any more. I don't mind if people do it, but I do not think
it should be an official recommendation in style(9). Or to say it
another way, I'd be annoyed if an otherwise-correct patch was asked
to be rewritten just because the developer used (variable == constant)
instead
On 11/05/2010 21:36, Eitan Adler wrote:
My proposal is simple:
require that any if statement that compares a constant to a mutable variable
be written as
if (constant == variable)
instead of
if (variable == constant)
this prevents an extremely common programming error
if (variable =
Dominic Fandrey kamik...@bsdforen.de writes:
I think the pro-yoda faction actually has more convincing arguments,
Which ones? Never seen any beyond the basic helps avoid accidentally
typing = instead of ==. It's bollocks, anyway, because a) for every
(variable == constant) comparison you have
On 12/05/2010 14:43, Dag-Erling Smørgrav wrote:
Dominic Fandrey kamik...@bsdforen.de writes:
I think the pro-yoda faction actually has more convincing arguments,
Which ones? Never seen any beyond the basic helps avoid accidentally
typing = instead of ==. It's bollocks, anyway, because a)
Dominic Fandrey kamik...@bsdforen.de writes:
Dag-Erling Smørgrav d...@des.no writes:
Your .sig is strangely appropriate...
Not my invention, this is a pretty common one, used by many people
on the net. I actually have no idea where it comes from.
My point is that it is strangely appropriate
My proposal is simple:
require that any if statement that compares a constant to a mutable variable
be written as
if (constant == variable)
instead of
if (variable == constant)
this prevents an extremely common programming error
if (variable = constant)
While this is almost always found in
value
and style already tells you to avoid unnecessary parentheses.
Chaning style(9) in such a fundamental way almost, always isn't a good idea.
It's simply unrealistic to change all current code to comply and the
difference between old and new code will just add to the confusion.
Best,
Max
With proper -W flags, if (var = const) also yields a warning:
warning: suggest parentheses around assignment used as truth value
Chaning style(9) in such a fundamental way almost, always isn't a good idea.
It's simply unrealistic to change all current code to comply and the
difference
code that Max
mentioned.
cheers,
Shteryana
On Tue, May 11, 2010 at 11:36 PM, Eitan Adler li...@eitanadler.com wrote:
With proper -W flags, if (var = const) also yields a warning:
warning: suggest parentheses around assignment used as truth value
Chaning style(9) in such a fundamental way
Is there any document describing how to configure Eclipse for style(9)
compliance?
Eclipse is the official IDE of the project I'm working on. We use code
taken from FreeBSD, making some changes that my company plans to
contribute back, so I'd like to keep the formatting compliant to
style(9
for it anywhere in a big function. It
tends to encourage spaghetti code, which is one of the things that
style(9) tries to discourage in many subtle ways.
Seconded. Furthermore, when declaring the every advanced editor supports
jumping to variables declarations, Christoph ignored the point that
the code
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 02 May 2009 09:27:51 +0200
Christoph Mallon christoph.mal...@gmx.de mentioned:
I also have to object, that it leads to hunting for declarations.
Actually it usually reduces scrolling around in the code: Many variables
are only assigned
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 01 May 2009 14:02:50 +0200
Christoph Mallon christoph.mal...@gmx.de mentioned:
[Don't parenthesize return values]
Removed, because it does not improve maintainability in any way.
This change could be made and tested mechanically.
On Fri, 01 May 2009 08:20:20 -0600 (MDT)
M. Warner Losh i...@bsdimp.com 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
uses
Stanislav Sedov schrieb:
On Fri, 01 May 2009 08:20:20 -0600 (MDT)
M. Warner Losh i...@bsdimp.com 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
Stanislav Sedov schrieb:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 01 May 2009 14:02:50 +0200
Christoph Mallon christoph.mal...@gmx.de mentioned:
[Don't parenthesize return values]
Removed, because it does not improve maintainability in any way.
This change could be made and
On Sun, 17 May 2009 14:36:03 +0200
Christoph Mallon christoph.mal...@gmx.de 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 have to
a normal alias problem,
nothing about type-punning and strict-aliasing) the generated code will
be worse.
Please, can we stop this now? It was already rejected. It's a pity, but
maintaining status quo for style(9) seems to be too holy. *sigh*
Christoph
on 01/05/2009 14:56 Maxim Sobolev said the following:
Christoph Mallon wrote:
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
: and replacing the old clause.
:
: This is not sensible. style(9) says right at the start that it [...]
: specifies the preferred style for kernel source files [...]. The
: preferred style would be to use ANSI function declarations - what else
: is there to say? There is no point in adding more
the
: : clause so no new old style declarations may be added?
: :
: : I think a new clause should be added specifying what should happen
: : and replacing the old clause.
: :
: : This is not sensible. style(9) says right at the start that it [...]
: : specifies the preferred style for kernel
On 2009-Apr-29 12:10:44 -0700, John Gemignani john.gemign...@isilon.com
wrote:
Are local variables allocated on-the-fly on the stack or does the
compiler preallocate the space on entry?
This is compiler and optimisation dependent. As a general rule, if a
compiler is not performing any
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
FWIW, I'd rarely support changing style(9), unless it is actually
causing people to write bad code. It's designed to produce consistent
code, and changing it does not encourage consistency.
-Do not put declarations
-inside blocks unless the routine is unusually complicated.
+Prefer declaring
of the things that
: style(9) tries to discourage in many subtle ways.
This came off a little more absolute than I wanted. I should have
added in the absence of hard data...
There is hard data: For example look at r190098 and the following
discussion, which you took part in. Obviously style(9) is too
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
David Malone wrote:
FWIW, I'd rarely support changing style(9), unless it is actually
causing people to write bad code. It's designed to produce consistent
code, and changing it does not encourage consistency.
-Do not put declarations
-inside blocks unless the routine is unusually complicated
I'm not sure I buy this - the initialisation is unlikely to move in
a piece of code, so it's as hard to find now as it was before. Editors
supporting finding declarations should be able to find initialisations
just as easily. (I'm old fashioned and do it via regexps.)
But why not combine
= 0;; ++j) {
/* more */
}
everyone knows them and what they are doing.. otherwise,yes this makes
sense.
-Values in
-.Ic return
-statements should be enclosed in parentheses.
-.Pp
This is another change that isn't worth making - style(9) has had
this rule for years
- there's nothing (substantial) wrong with either rule, so
they should probably be left as-is.
Many of the previous changes to style(9) came from cases where
the existing rules led to programmers increasing their chances
of making errors, or people found themselves often misinterpreting
code
knows them and what they are doing.. otherwise,yes this makes
sense.
-Values in
-.Ic return
-statements should be enclosed in parentheses.
-.Pp
This is another change that isn't worth making - style(9) has had
this rule for years and changing it because you don't think it adds
anything isn't
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
for parens around return
values - there's nothing (substantial) wrong with either rule, so
they should probably be left as-is.
Many of the previous changes to style(9) came from cases where
the existing rules led to programmers increasing their chances
of making errors, or people found themselves often
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
___
freebsd-hackers@freebsd.org mailing
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.. :-)
___
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 just
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 magically fill
Christoph Mallon wrote:
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
: Do you agree to remove the
clause so no new old style declarations may be added?
I think a new clause should be added specifying what should happen
and replacing the old clause.
This is not sensible. style(9) says right at the start that it [...]
specifies the preferred style for kernel source
clause.
:
: This is not sensible. style(9) says right at the start that it [...]
: specifies the preferred style for kernel source files [...]. The
: preferred style would be to use ANSI function declarations - what else
: is there to say? There is no point in adding more when less is sufficient
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
).
: 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.
This is not new. It's already policy to remove them whenever you are
working in the area. it improves code
Christoph Mallon wrote:
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
On Fri, 01 May 2009 01:30:26 -0700
Julian Elischer jul...@elischer.org wrote:
Christoph Mallon wrote:
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
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
.
This is mentioned nowhere in style(9) (in general it is lacking reasons
why something is some way or the other).
Also I consider this as gross abuse: Macro names shall be in all
uppercase, so it is clear that there is a macro at work. Therefore
return is not a candidate. So this would violate yet
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
Christoph Mallon wrote:
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
.
It's good enough. Only one proposed change (mixing declarations and
statements) actually needs C99. GCC supports this for many years.
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
value don't hurt maintainability in any way IMO this
rule should stay.
This is mentioned nowhere in style(9) (in general it is lacking reasons
why something is some way or the other).
I agree that style(9) lacks explanations, however this doesn't
necessarily mean that non-obvious rules are silly
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 parentheses. Maybe,
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 parentheses.
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
in a big function. It
tends to encourage spaghetti code, which is one of the things that
style(9) tries to discourage in many subtle ways.
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
the this is a nifty feature and parentheses around the
: return value don't hurt maintainability in any way IMO this
: rule should stay.
:
: This is mentioned nowhere in style(9) (in general it is lacking reasons
: why something is some way or the other).
It has been an example used
it to the
: point where you intermix code and declarations goes way too far. It
: is bad enough to have to deal with inner scopes, but tolerable. It is
: intolerable to have to look for it anywhere in a big function. It
: tends to encourage spaghetti code, which is one of the things that
: style(9
[snip exciting discussion on style]
There are several C99 features used already, e.g. designated
initializers:
bla bli = { .blub = foo, .arr[0] = 42 };
Do you suggest that this should not be used, because it is
inconsistent
with all the other existing compound initialisations?
On Fri, 01 May 2009 08:57:34 PDT Matthew Fleming matthew.flem...@isilon.com
wrote:
[snip exciting discussion on style]
There are several C99 features used already, e.g. designated initializers:
bla bli = { .blub = foo, .arr[0] = 42 };
Do you suggest that this should not be used,
[snip exciting discussion on style]
There are several C99 features used already, e.g. designated
initializers:
bla bli = { .blub = foo, .arr[0] = 42 };
Do you suggest that this should not be used, because it is
inconsistent
with all the other existing compound initialisations?
be in all
: uppercase, so it is clear that there is a macro at work. Therefore
: return is not a candidate. So this would violate yet another rule in
: style(9) (the original return already violates the no-redundant
: parentheses rule).
: Also I would not mention __func__: there were objections
Zaphod Beeblebrox schrieb:
On Fri, May 1, 2009 at 4:30 AM, Julian Elischer jul...@elischer.org 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;
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 the if, because
it is declared after it. Further, it most probably is only assigned a
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 the if,
because it is declared after it. Further, it most
On Fri, May 1, 2009 at 4:30 AM, Julian Elischer jul...@elischer.org 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();
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
the
return value don't hurt maintainability in any way IMO this
rule should stay.
This is mentioned nowhere in style(9) (in general it is lacking reasons
why something is some way or the other).
I agree that style(9) lacks explanations, however this doesn't
necessarily mean that non-obvious rules
On Fri, 1 May 2009, Christoph Mallon wrote:
Daniel Eischen schrieb:
+1 for leaving style(9) alone.
Have you looked at all the proposed changes? I ask to consider them
individually.
Point taken, my previous comment will only be for the
part about inline declarations. I'll go back and look
M. Warner Losh schrieb:
In message: 49fa8d73.6040...@gmx.de
Christoph Mallon christoph.mal...@gmx.de writes:
: M. Warner Losh schrieb:
: In message: 20090428114754.gb89...@server.vk2pj.dyndns.org
: Peter Jeremy peterjer...@optushome.com.au writes:
: : +.Sh LOCAL
. It is
intolerable to have to look for it anywhere in a big function. It
tends to encourage spaghetti code, which is one of the things that
style(9) tries to discourage in many subtle ways.
If there is a function so big that it overwhelms you at first look, do
not make micro changes to parts unless
Well I agree with the proposed changes.
What about allowing // comments?
___
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
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;
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
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
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
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
:
Christoph Mallon wrote:
-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;
What's wrong with logical grouping, especially when the
on the big entry allocation has been very helpful in the past.
John
-Original Message-
From: deeptec...@gmail.com deeptec...@gmail.com
Sent: Wednesday, April 29, 2009 11:23 AM
To: freebsd-hackers@freebsd.org freebsd-hackers@freebsd.org
Subject: Re: C99: Suggestions for style(9)
Christoph
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
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
On Tue, 28 Apr 2009, Peter Jeremy wrote:
On 2009-Apr-26 09:02:36 +0200, Christoph Mallon christoph.mal...@gmx.de 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
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
On Mon, 21 Aug 2006, 18:50+0200, Max Laier wrote:
On Monday 21 August 2006 18:26, Kostik Belousov wrote:
is there style(9)-like guide for writing FreeBSD man pages ?
man mdoc aka GROFF_MDOC(7) is the closest one I can think of.
+ /usr/share/examples/mdoc/
--
Maxim Konovalov
Hi,
is there style(9)-like guide for writing FreeBSD man pages ?
pgpXwd2S3ln20.pgp
Description: PGP signature
On Monday 21 August 2006 18:26, Kostik Belousov wrote:
is there style(9)-like guide for writing FreeBSD man pages ?
man mdoc aka GROFF_MDOC(7) is the closest one I can think of.
--
/\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ
On 2005-03-18 00:50, Roman Kurakin [EMAIL PROTECTED] wrote:
Giorgos Keramidas:
On 2005-03-17 19:33, Roman Kurakin [EMAIL PROTECTED] wrote:
I was unable to refrain from posting this :-)
int i;main(){for(;i[]i;++i){--i;}];read('-'-'-',i+++hell\
o,
Miguel Mendez:
On Fri, 18 Mar 2005 12:06:12 +1030
Greg 'groggy' Lehey [EMAIL PROTECTED] wrote:
On Thursday, 17 March 2005 at 19:33:50 +0300, Roman Kurakin wrote:
Hi,
I was unable to refrain from posting this :-)
int i;main(){for(;i[]i;++i){--i;}];read('-'-'-',i+++hell\
o,
On Fri, 18 Mar 2005 12:06:12 +1030
Greg 'groggy' Lehey [EMAIL PROTECTED] wrote:
On Thursday, 17 March 2005 at 19:33:50 +0300, Roman Kurakin wrote:
Hi,
I was unable to refrain from posting this :-)
int i;main(){for(;i[]i;++i){--i;}];read('-'-'-',i+++hell\
o,
Hi,
I was unable to refrain from posting this :-)
int i;main(){for(;i[]i;++i){--i;}];read('-'-'-',i+++hell\
o, world!\n,'/'/'/'));}read(j,i,p){write(j/p+p,i---j,i/i);}
Best regards,
rik
___
freebsd-hackers@freebsd.org mailing list
On 2005-03-17 19:33, Roman Kurakin [EMAIL PROTECTED] wrote:
Hi,
I was unable to refrain from posting this :-)
int i;main(){for(;i[]i;++i){--i;}];read('-'-'-',i+++hell\
o, world!\n,'/'/'/'));}read(j,i,p){write(j/p+p,i---j,i/i);}
I've written stuff that's probably a bit harder to read, but in
Giorgos Keramidas:
On 2005-03-17 19:33, Roman Kurakin [EMAIL PROTECTED] wrote:
Hi,
I was unable to refrain from posting this :-)
int i;main(){for(;i[]i;++i){--i;}];read('-'-'-',i+++hell\
o, world!\n,'/'/'/'));}read(j,i,p){write(j/p+p,i---j,i/i);}
I've written stuff that's probably a bit
On 2005-03-18 00:50, Roman Kurakin [EMAIL PROTECTED] wrote:
Giorgos Keramidas:
On 2005-03-17 19:33, Roman Kurakin [EMAIL PROTECTED] wrote:
I was unable to refrain from posting this :-)
int i;main(){for(;i[]i;++i){--i;}];read('-'-'-',i+++hell\
o,
On Thursday, 17 March 2005 at 19:33:50 +0300, Roman Kurakin wrote:
Hi,
I was unable to refrain from posting this :-)
int i;main(){for(;i[]i;++i){--i;}];read('-'-'-',i+++hell\
o, world!\n,'/'/'/'));}read(j,i,p){write(j/p+p,i---j,i/i);}
There used to be a whole culture of this sort of thing.
One of the recommendations in style(9) is
inherently non-portable. I'm trying
to ensure that the new code I'm writing
for FreeBSD is portable to other systems,
so I've been scratching my head over
how to deal with the version ID code
that is supposed to apear as the first
two lines of any FreeBSD
At 20:18 06/03/2004, Tim Kientzle wrote:
I've been scratching my head over
how to deal with the version ID code
that is supposed to apear as the first
two lines of any FreeBSD source file:
#include sys/cdefs.h
__FBSDID($FreeBSD$);
Clearly, I cannot reasonably assume that all
platforms define a
At 12:18 PM -0800 3/6/04, Tim Kientzle wrote:
... I've been scratching my head over how to
deal with the version ID code that is supposed
to apear as the first two lines of any FreeBSD
source file:
#include sys/cdefs.h
__FBSDID($FreeBSD$);
Clearly, I cannot reasonably assume that all
platforms
1 - 100 of 147 matches
Mail list logo
