8 Nov
2017
8 Nov
'17
4:17 p.m.
From a mailing list I belong to, a back-and-forth is going on that I am
not involved in. The following sums it up nicely:
It's really the implied equality that's the
problem. For example:
if (flags & DLADM_OPT_PERSIST) {
would be better written as:
if ((flags & DLADM_OPT_PERSIST) == 0) {
Seriously? What do (or would) "original C" programmers think of this? To me,
anything non-zero is "true" so the first is perfectly acceptable.
The original assertion in the discussion was that the following is not "right"
because of the mixing of bitwise and boolean.
if ((flags & DLADM_OPT_PERSIST) &&
(link_flags & DLMGMT_PERSIST)) {
art k.
8 Nov
8 Nov
4:27 p.m.
On Wed, Nov 8, 2017 at 9:17 AM, Arthur Krewat <krewat(a)kilonet.net> wrote:
From a mailing list I belong to, a back-and-forth is
going on that I am
not involved in. The following sums it up nicely:
It's really the implied equality that's the problem. For example:
No it wouldn't. That would be a bug. s/==/!=/ there and you might be right.
Except code reviews that make such 'crazy' suggestions often do more to
introduce bugs than prevent future bugs.
But even then, there's a time and place for testing against zero,
especially in code that has complicated bit testing, where you only want to
proceed if a subset of bits are set and others are clear. Or if you are
mixing boolean and flags, it can be clearer.
Or do the Linux-school and go with
if (!!(flags & DLADM_OPT_PERSIST)) {
to really confuse things...
Seriously? What do (or would) "original C" programmers think of this? To
if (flags & DLADM_OPT_PERSIST) {
would be better written as:
if ((flags & DLADM_OPT_PERSIST) == 0) {
me, anything non-zero is "true" so the first
is perfectly acceptable.
Acceptable to the compiler sure. But if you use the different forms to
convey information to the reader, then you might choose something slightly
different.
For pointers, say, you have the choice of the following forms:
if (foo)
if (!foo)
if (foo == NULL)
if (foo != NULL)
if (foo == 0)
if (foo != 0)
The middle two remind the reader that foo is a pointer, while the first two
might slightly suggest that from other context near by. The last one,
though technically correct, suggest the original author may be confusing
pointers and ints, even though its 100% legal C in every single properly
implemented C compiler (even if the native representation of a null-pointer
has bits set). It also spurs even more bogus comments that it is wrong on
exotic architectures because someone wants to appear to be smart, but is
actually being wrong, or reporting a situation where a compiler that
purports to be a C compiler is actually implementing a different language
that is only superficially similar to C.
The original assertion in the discussion was that the
following is not
"right" because of the mixing of bitwise and boolean.
if ((flags & DLADM_OPT_PERSIST) && (link_flags & DLMGMT_PERSIST)) {
Wow! That's grade a crazy they are smoking. That's not a rule in C, and
not
even a widely followed 'kool-aide kult kode" practice, but there's so many
different cults, it's hard to keep up.
Warner
9 Nov
9 Nov
10:17 a.m.
On 8 Nov 2017 09:27 -0700, from imp(a)bsdimp.com (Warner Losh):
Or do the Linux-school and go with
if (!!(flags & DLADM_OPT_PERSIST)) {
to really confuse things...
That smells like a Javascript influence to me, where
if (!!x)
or z = !!x;
is _more or less_ idiomatic for
if (x == true)
or z = x == true ? true : false;
(mind the difference between _assignment_ = and _equality_ == and
_actually equals_ ===)
or what in another language could be written as something largely
similar to a simple
if (x)
if so desired.
Simply, !!x coerces x from whatever it is to a boolean, based on the
_truthiness_ of x. Where _truthiness_ is another of those lovely
Javascript concepts.
This, of course, is partly because Javascript (even more so than, say,
C) lacks _any_ sane idea of types. Its type system is more similar to
that of BCPL or PHP than even C, in that not only do you get to keep
the pieces if things break (assuming that you're lucky enough to
_know_ that things broke), but also that anything goes anywhere. That
variable which held a boolean a moment ago? Sure, go right ahead and
put an object or an array or a string in it. The next line of code can
replace it with a floating-point value or single character no problem,
and then you can have a conditional based on whether or not the latter
has sufficient truthiness.
(People who work with quantum computers must love that language.)
--
Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)
8 Nov
8 Nov
6:14 p.m.
Hi art,
> if (flags & DLADM_OPT_PERSIST) {
...
> if ((flags & DLADM_OPT_PERSIST) == 0) {
...
To me, anything non-zero is "true" so the
first is perfectly
acceptable.
It's not what acceptable that matters, but what's idiomatic as that is
instantly familiar to other readers and lets them read code without
being jolted out of concentrating on the important stuff by wondering
why the expression isn't idiomatic, was something else meant instead,
and does it mean the author has dodgy practices.
`if (w & MASK)' is idiomatic.
The original assertion in the discussion was that the
following is not
"right" because of the mixing of bitwise and boolean.
> if ((flags & DLADM_OPT_PERSIST) && (link_flags & DLMGMT_PERSIST)) {
What's the alternative? As the Eskimo C FAQ points out, if you think
if ((w & MASK) != FALSE)
is better then why stop there? Why not
if (((w & MASK) != FALSE) == TRUE)
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
8:13 p.m.
There's a lot of weird lore around use of C nowadays, a lot of it in my
experience from folks who come from Java. But this w & MASK discussion is
one of the weirder ones.
For me one of the worst is the 80-column requirement that came from out of
I don't know where. Let's see, we're all getting 4k monitors, and yet
somehow
80 columns is how we have to write code? Hollerith would be proud.
On Wed, Nov 8, 2017 at 11:05 AM Larry McVoy <lm(a)mcvoy.com> wrote:
On Wed, Nov 08, 2017 at 06:14:20PM +0000, Ralph
Corderoy wrote:
is better then why stop there? Why not
if (((w & MASK) != FALSE) == TRUE)
Thanks for this, that's the perfect come back to the pedantic folks.
8:23 p.m.
For me one of the worst is the 80-column requirement
that came from out of
I don't know where. Let's see, we're all getting 4k monitors, and yet
somehow
80 columns is how we have to write code? Hollerith would be proud.
I'm an 80 column person, I like it for side by side diffs, stuff like that.
I also read very very fast by reading down the center and using peripheral
vision for either side (hockey habits die hard). I can't do that with much
wider than 80 column.
I had a guy working for me who started to argue with me and caught himself:
"I work for you, so it's 80 columns. When you work for me it won't
be."
Fair enough.
8:32 p.m.
80 was the number of columns in the IBM punched cards.
Teletypes only had 72 coumns.
Most lineprinters could do 132.
I remember making the jump from the Visual200's (a vt52 clone) to the 5620
DMD. I actually had at home in my kitchen a ASR-37. It was one of the
only terminals I have used that I didn't need to engage nl mode.
It had a big NEWLINE key that sent "\n" and didn't need to have the
"\r"
also sent. It also did stuff with all the SI/SO and ESC 8 and 9 things
that nroff sent by default without the need for an converting filter.
Amusingly, it was also one of the the only terminals I used that did
something with CD and DSR. Upon DSR coming up, it would turn on the motor
and on CD a giant green PROCEED indicator came on. I never turned it off,
I just shutdown the modem.
-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Larry McVoy
Sent: Wednesday, November 8, 2017 3:24 PM
To: ron minnich
Cc: tuhs(a)minnie.tuhs.org
Subject: Re: [TUHS] C question for the historians
For me one of the worst is the 80-column requirement
that came from
out of I don't know where. Let's see, we're all getting 4k monitors,
and yet somehow
80 columns is how we have to write code? Hollerith would be proud.
I'm an 80 column person, I like it for side by side diffs, stuff like that.
I also read very very fast by reading down the center and using peripheral
vision for either side (hockey habits die hard). I can't do that with much
wider than 80 column.
I had a guy working for me who started to argue with me and caught himself:
"I work for you, so it's 80 columns. When you work for me it won't
be."
Fair enough.
8:39 p.m.
Terminals used to have 80 columns almost universally back in the 80's (yes,
you can find exceptions). CGA/MHA/VGA consoles still do because they were
designed to replace said terminals. The notion, at least for FreeBSD, was
that you'd want to be able to easily hack on the code if you had to on the
console. Likely a bit antiquated, but there's a solid reason for it.
There's other side effects of that, most of which are good, but some
crazy...
Warner
On Wed, Nov 8, 2017 at 1:13 PM, ron minnich <rminnich(a)gmail.com> wrote:
There's a lot of weird lore around use of C
nowadays, a lot of it in my
experience from folks who come from Java. But this w & MASK discussion is
one of the weirder ones.
For me one of the worst is the 80-column requirement that came from out of
I don't know where. Let's see, we're all getting 4k monitors, and yet
somehow
80 columns is how we have to write code? Hollerith would be proud.
On Wed, Nov 8, 2017 at 11:05 AM Larry McVoy <lm(a)mcvoy.com> wrote:
On Wed, Nov 08, 2017 at 06:14:20PM +0000, Ralph
Corderoy wrote:
is better then why stop there? Why not
if (((w & MASK) != FALSE) == TRUE)
Thanks for this, that's the perfect come back to the pedantic folks.
8:41 p.m.
On 11/8/17 3:13 PM, ron minnich wrote:
There's a lot of weird lore around use of C
nowadays, a lot of it in my
experience from folks who come from Java. But this w & MASK discussion is
one of the weirder ones.
gcc warns about it in its default mode, which is why so many people who
are adamant about warning-free compilation have weird workarounds. It's
just a PITA.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/
9 Nov
9 Nov
1:22 a.m.
Hi Chet,
I'm having trouble triggering that, though often these things crop up
when you don't want them, not when you do.
$ cat t.c
#define M 0xa5
int foo(int i, int j)
{
if (i & M && j & ~M)
return 42;
return -314;
}
$ gcc -Wall -pedantic`: swine` -O3 -c t.c
$
When it does moan, is it one of those things where just extra
parenthesis suffice as a signal that you meant it?
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
But this w
& MASK discussion is one of the weirder ones.
gcc warns about it in its default mode
1:41 a.m.
On 11/8/17 8:22 PM, Ralph Corderoy wrote:
Hi Chet,
I'm having trouble triggering that, though often these things crop up
when you don't want them, not when you do.
$ cat t.c
#define M 0xa5
int foo(int i, int j)
{
if (i & M && j & ~M)
return 42;
return -314;
}
$ gcc -Wall -pedantic`: swine` -O3 -c t.c
$
When it does moan, is it one of those things where just extra
parenthesis suffice as a signal that you meant it?
Yeah, that's what I thought, but I didn't go so far as to test it.
(There's also the annoying warning on `if (x = something)'; maybe that's
what I was thinking.)
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/
But this
w & MASK discussion is one of the weirder ones.
gcc warns about it in its default mode
1:49 a.m.
On 11/8/2017 8:41 PM, Chet Ramey wrote:
(There's also the annoying warning on `if (x =
something)'; maybe that's
what I was thinking.)
Which Visual Studio 2013 doesn't warn about in it's default state. I
know it doesn't through personal experience (insert ashamed look-away
emoticon here).
Truth be told, there is some utility in the "if (x = something) ..." -
always set x, but also conditionally do something when it's not 0. But
it's also a dumb mistake. Yeah, I'm dumb.
art k.
8 Nov
8 Nov
8:43 p.m.
On Wed, 08 Nov 2017 20:13:31 +0000 ron minnich <rminnich(a)gmail.com> wrote:
ron minnich writes:
For me one of the worst is the 80-column requirement that came from out of
I don't know where. Let's see, we're all getting 4k monitors, and yet
somehow
80 columns is how we have to write code? Hollerith would be proud.
Put me in the 80 column column! Very wide screens have the
same issue as moden webpages which are content light and white
space heavy arctic look. With 80 columns you can almost scan
top to bottom without moving eye focus left to right too much.
The 4k monitors are for opening *multiple* 80 column windows :-)
8:55 p.m.
On Wed, 8 Nov 2017, ron minnich wrote:
There's a lot of weird lore around use of C
nowadays, a lot of it in my
experience from folks who come from Java. But this w & MASK discussion is
one of the weirder ones.
For me one of the worst is the 80-column requirement that came from out of
I don't know where. Let's see, we're all getting 4k monitors, and yet
somehow
80 columns is how we have to write code? Hollerith would be proud.
I can fit 115x38 in my standard text editor on a 1280x1024 display and
although I often write to the size of the window, I still consider 80
columns, or more correctly *79* columns, the limit that my lines should
not exceed for hysterical reasons (and when I used EDIT in MS-DOS, this
limit was usually 77 but I walked over it all the time).
-uso.
8:36 p.m.
On Wed, Nov 8, 2017 at 12:05 PM, Larry McVoy <lm(a)mcvoy.com> wrote:
On Wed, Nov 08, 2017 at 06:14:20PM +0000, Ralph
Corderoy wrote:
It's also wrong. You couldn't flip it around to write
if (((w & MASK) == TRUE) == TRUE)
because that only works when MASK == 1. So it's dangerous since you can't
apply the normal laws of algebra on it because you are comparing BOOLEANS
and MASKS, which has always ended in pain...
Warner
is better then why stop there? Why not
if (((w & MASK) != FALSE) == TRUE)
Thanks for this, that's the perfect come back to the pedantic folks.
2353
days inactive
2354
days old
16 comments
10 participants
participants (10)
-
Arthur Krewat -
Bakul Shah -
Chet Ramey -
Larry McVoy -
Michael Kjörling -
Ralph Corderoy -
ron minnich -
Ron Natalie -
Steve Nickolas -
Warner Losh