From: John Kelly on
On Fri, 27 Nov 2009 13:52:41 +0100, Rainer Weikusat
<rweikusat(a)mssgmbh.com> wrote:

> There is no particular reason for the addition[*]

> [*] It 'encodes' the author lack of understanding of the C language

Spotting a bug is one thing. Knowing what the author had in mind is
another. I've been accused of not understanding C due to this use of
sizeof:

char ts[512];

if (sizeof (ts) < 3) {
errno = EOVERFLOW;
perror ("failure specifying North pipe storage");
exit (EXIT_FAILURE);
}


I know the test will always be false. I use it like an assert. Mine
executes, but since the execution penalty is infinitesimal, who cares.
It provides a self documenting reminder of the minimum usable size for
the buffer, also described in a comment at the top of the program.

I don't mind criticism when I can learn something from it. There should
be more code auditing. The accounting profession has auditors, but many
programmers just cross their fingers and hope their code won't explode.

I have a program you looked at once. I've revised it extensively since
then; it's due for another inspection.

There's no need to discuss the two gotos I used. They prevent needless
indentation of large blocks, and they keep certain lines near each other
right where I want them.

There's also no need to discuss further functional decomposition. I
like the large main() the way it is. The tedious repetition of error
checking and exit (EXIT_FAILURE) is a self debugging style. Many of the
errors will never happen unless there is some systemic failure beyond
control of the programmer, but if that happens, the error message will
help the programmer understand the nature of it.

I don't purport to be a C expert. I'm just a workman with some work to
do. Expert advice is welcome:

http://www.beewyz.com/~jar/etcetera/computer/programming/project/dh/



--
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php

From: Rainer Weikusat on
Rainer Weikusat <rweikusat(a)mssgmbh.com> writes:

[...]

> This is further emphasized by the fact that the MAX_VLAN_ID
> macros is not defined to be the numerically highest VLAN ID
> but the largest valid index for addressing elements of the
> array and because of this, another correction is necessary
> (that's the MAX_VLAN_ID/32 + 1).

Clarification: 4095 is not the largest valid array index (that would
be 127) but the largest possible non-transformed VLAN ID, array index
127, bit index 31.

From: Rainer Weikusat on
John Kelly <jak(a)isp2dial.com> writes:
> On Fri, 27 Nov 2009 13:52:41 +0100, Rainer Weikusat
> <rweikusat(a)mssgmbh.com> wrote:
>
>> There is no particular reason for the addition[*]
>
>> [*] It 'encodes' the author lack of understanding of the C language
>
> Spotting a bug is one thing. Knowing what the author had in mind is
> another.

In this particular case the range of VLAN IDs is changed from (0,
4095) to (1, 4096). This complicates the code for no particular reason
except 'let the first be 1', this being a traditional grudge some
people have with C: Access to field elements is 0-based, not
1-based. But since the 'index' is actually a distance, that's
perfectly sensible in itself.

> I've been accused of not understanding C due to this use of
> sizeof:
>
> char ts[512];
>
> if (sizeof (ts) < 3) {
> errno = EOVERFLOW;
> perror ("failure specifying North pipe storage");
> exit (EXIT_FAILURE);
> }
>
>
> I know the test will always be false. I use it like an assert. Mine
> executes, but since the execution penalty is infinitesimal, who
> cares.

Well, you obviously don't.

[...]

> I have a program you looked at once. I've revised it extensively since
> then; it's due for another inspection.

There is some code I have to read because of my job. Presently, this
is clamav. And there is code I fortunately don't have to read, like
'useless tools produced by people who abhor writing easily readable
text'. I hope this is clear enough.

From: John Kelly on
On Fri, 27 Nov 2009 19:45:15 +0100, Rainer Weikusat
<rweikusat(a)mssgmbh.com> wrote:

>there is code I fortunately don't have to read, like useless tools

if (You != everyone) tool = notuseless;


>produced by people who abhor writing easily readable text

You can read minds too!


> I hope this is clear enough.

Funny that.



--
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php

From: Rainer Weikusat on
John Kelly <jak(a)isp2dial.com> writes:
> On Fri, 27 Nov 2009 19:45:15 +0100, Rainer Weikusat
> <rweikusat(a)mssgmbh.com> wrote:
>
>>there is code I fortunately don't have to read, like useless tools
>
> if (You != everyone) tool = notuseless;

I didn't expect your opinion on this to be identical to my opinion,
for obvious reasons.

>>produced by people who abhor writing easily readable text
>
> You can read minds too!

There is no reason to 'read a mind' when it communicates about itself
in sufficiently detailed ways. Code which has no purpose confuses the
reader (see original posting), you wrote that you like to write code
without purpose because you use it instead of proper documentation.
Further, you stated that you wouldn't like to structure texts into
sensible and easily intelligible, independent units, but rather just
talk along in however ways you presently feel like doing (that was the
'large function' statement) and at least when I was in school, taking
a that cavalier approach towards composition of non-fictional texts
intended to be read by others would solely have resulted in a bad
grade.

You are free to write F-level technical prose. Nobody has a reason to
care for that.