[TUHS] C question for the historians

[TUHS] C question for the historians

[Arthur Krewat]

 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.

[TUHS] C question for the historians

[Warner Losh]

On Wed, Nov 8, 2017 at 9:17 AM, Arthur Krewat <krewat at 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:
>>
>>     if (flags & DLADM_OPT_PERSIST) {
>>
>> would be better written as:
>>
>>     if ((flags & DLADM_OPT_PERSIST) == 0) {
>
>
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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/9fafdce7/attachment-0001.html>

[TUHS] C question for the historians

[Ralph Corderoy]

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

[TUHS] C question for the historians

[Arthur Krewat]

On 11/8/2017 1:14 PM, Ralph Corderoy wrote:
> Hi art,
> <snip>
>      if (((w & MASK) != FALSE) == TRUE)

Laugh of the day ;)

Thanks for that ...

art k.

[TUHS] C question for the historians

[Larry McVoy]

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.

[TUHS] C question for the historians

[ron minnich]

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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/fe3a2616/attachment.html>

[TUHS] C question for the historians

[Larry McVoy]

> 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.

[TUHS] C question for the historians

[Ron Natalie]

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 at 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.

[TUHS] C question for the historians

[Warner Losh]

On Wed, Nov 8, 2017 at 12:05 PM, Larry McVoy <lm at 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.
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/d90d3972/attachment.html>

[TUHS] C question for the historians

[Warner Losh]

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 at 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 at 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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171108/04ffd755/attachment-0001.html>

[TUHS] C question for the historians

[Chet Ramey]

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 at case.edu    http://cnswww.cns.cwru.edu/~chet/

[TUHS] C question for the historians

[Bakul Shah]

On Wed, 08 Nov 2017 20:13:31 +0000 ron minnich <rminnich at 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 :-)

[TUHS] C question for the historians

[Steve Nickolas]

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.

[TUHS] C question for the historians

[Ralph Corderoy]

Hi Chet,

> > But this w & MASK discussion is one of the weirder ones.
>
> gcc warns about it in its default mode

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

[TUHS] C question for the historians

[Chet Ramey]

On 11/8/17 8:22 PM, Ralph Corderoy wrote:
> Hi Chet,
> 
>>> But this w & MASK discussion is one of the weirder ones.
>>
>> gcc warns about it in its default mode
> 
> 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 at case.edu    http://cnswww.cns.cwru.edu/~chet/

[TUHS] C question for the historians

[Arthur Krewat]

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.

[TUHS] C question for the historians

[Michael Kjörling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1661 bytes --]

On 8 Nov 2017 09:27 -0700, from imp at 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 at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)