Pedants

[Kaz Kylheku]

Re: Pedants

On Jun 28, 2:51 am, "Serve Lau" <ni...@qinqin.c omwrote:

"Kaz Kylheku" <kkylh...@gmail .comschreef in berichtnews:1a9 07d38-8880-476d-9420-f0c458983d98@59 g2000hsb.google groups.com...
On Jun 27, 3:03 pm, "Serve Lau" <ni...@qinqin.c omwrote:
>

"Richard Heathfield" <r...@see.sig.i nvalidschreef in

A little care up front, and everyone wins.

>

Using 0 instead of NULL is a matter of opinion though, its both correct.
That's true, and knowing this perhaps makes you more of a language
pedant than your fake pedant.

>
as im sure you remember from the first post a pedant is:
>
1. a person who makes an excessive or inappropriate display of learning.

I recall from the root article that a disjunction of three possible
definitions was given. By the above branch, nobody is a pedant during
a code review, because display of all pertinent learning is required.
In that situation you're an expert, and as such you're being paid for
what you know, and so you have to deliver.

A commercial lint program can generate thousands of diagnostics even
for a fairly small project. Many of those diagnostics are not useful
in the given situation, so the tool has to be iteratively configured
to improve its yield. People pay for tools like this and expect them
to have a large diagnostic base.

A pedant can also be configured that way. For instance, if I am told
``this code deliberately uses non-standard escape sequences in string
and character literals, please ignore'', then I will no longer flag
such uses.

[Richard Bos]

Re: Pedants

roberson@ibd.nr c-cnrc.gc.ca (Walter Roberson) wrote:

In article <g4asrm$au7$2@a ioe.org>, santosh <santosh.k83@gm ail.comwrote:

Nick Keighley wrote:

>

int i = NULL;

>

Is there any reason at all to assign a null pointer constant to an int?
Why would anyone do this instead of using 0?

>
Confusion with the NUL character perhaps?

Why? Would you normally do

int i='\0';

rather than

char c='\0';
int i=0;
void *p=NULL;

Richard

[pete]

Re: Pedants

Richard Bos wrote:

roberson@ibd.nr c-cnrc.gc.ca (Walter Roberson) wrote:
>

>In article <g4asrm$au7$2@a ioe.org>, santosh <santosh.k83@gm ail.comwrote:

>>Nick Keighley wrote:
>>>int i = NULL;
>>Is there any reason at all to assign a null pointer constant to an int?
>>Why would anyone do this instead of using 0?

>Confusion with the NUL character perhaps?

>
Why? Would you normally do
>
int i='\0';
>
rather than
>
char c='\0';
int i=0;
void *p=NULL;

For
char *a = {STRING};
in a context of doing something
like what the ctype functions do,
do you prefer
if (a[x] 0)
or
if (a[x] '\0')
?

--
pete

[Richard Bos]

Re: Pedants

pete <pfiland@mindsp ring.comwrote:

Richard Bos wrote:

roberson@ibd.nr c-cnrc.gc.ca (Walter Roberson) wrote:

In article <g4asrm$au7$2@a ioe.org>, santosh <santosh.k83@gm ail.comwrote:
>Nick Keighley wrote:
>>int i = NULL;
>Is there any reason at all to assign a null pointer constant to an int?
>Why would anyone do this instead of using 0?
Confusion with the NUL character perhaps?

Why? Would you normally do

int i='\0';

rather than

char c='\0';
int i=0;
void *p=NULL;

>
For
char *a = {STRING};
in a context of doing something
like what the ctype functions do,
do you prefer
if (a[x] 0)
or
if (a[x] '\0')
?

No, but in that case, a[x] _is_ a char, not an int. The discussion was
about assigning NULL (or the NUL character) to an int, not to any kind
of integer including the rather special char.

Richard

[pete]

Re: Pedants

Richard Bos wrote:

pete <pfiland@mindsp ring.comwrote:

>For
> char *a = {STRING};
>in a context of doing something
>like what the ctype functions do,
>do you prefer
> if (a[x] 0)
>or
> if (a[x] '\0')
>?

>
No, but in that case, a[x] _is_ a char, not an int. The discussion was
about assigning NULL (or the NUL character) to an int, not to any kind
of integer including the rather special char.

.... and it was about pedants, before it was about that.

Now, I want to talk about some code that I've written:

I used
if (a[x] '\0')

--
pete

[Walter Roberson]

Re: Pedants

In article <4869ef20.15549 25150@news.xs4a ll.nl>,
Richard Bos <rlb@hoekstra-uitgeverij.nlwr ote:

>roberson@ibd.n rc-cnrc.gc.ca (Walter Roberson) wrote:

>In article <g4asrm$au7$2@a ioe.org>, santosh <santosh.k83@gm ail.comwrote:

>Nick Keighley wrote:

>int i = NULL;

>Is there any reason at all to assign a null pointer constant to an int?
>Why would anyone do this instead of using 0?

>Confusion with the NUL character perhaps?

>Why? Would you normally do

int i='\0';

>rather than

char c='\0';
int i=0;
void *p=NULL;

Someone might (but *I* probably wouldn't), if i represented a character.
For example,

int i='\0';
if (somecondition) {
i = getchar();
}
if (i == EOF) {
/* whatever */
}

That is, Best Practice is to use an int to store any value that
is a char that has to be read in by getchar(), getc() or fgetc()
(because you need to be able to post-check against the int value EOF).
If someone were initializing that int and they wanted to emphasize the
char-in-int's-clothing nature of the variable, they just might
choose to initialize with '\0'... or might get confused about the
meaning of NULL and try to initialize with that.
--
"After all, what problems has intellectualism ever solved?"
-- Robert Gilman

[Richard Bos]

Re: Pedants

Kaz Kylheku <kkylheku@gmail .comwrote:

Casting malloc is just fine.

Casting malloc() is a grave mistake, as bad as making a bottle of apple
juice carry a dangerous substance sign.

In fact, it's useful in a C compiler to have C++-style type checking
for void *: that is to say, implicit conversions from void * to some
other pointer type being diagnosed.

No, it's not. In C, those conversions are correct, and with good reason.
Getting spurious warnings for them is a bother, and makes you ignore
real warnings. Casting away those spurious warnings is also a bother,
and makes you a. ignore real casts and b. cast away other, important,
warnings.

The rationale for /not/ casting malloc is outdated, based on the idea
that compilers allow functions to be called without a prior
declaration, without issuing a diagnostic.

That's only part of the rationale, and not the most important part.

Code reviewers have to look not only for bugs, but for adherence to
coding conventions (and be pedantic about that just as much as
language issues).

And to look for dangerous code.

Spurious casts are dangerous. Not always to the program - but nearly
always to the program_mer_. That's the real reason to avoid them. Casts
should make you sit up and think "Hey, a cast! What is going on here?",
not "Oh, *yawn* another cast, must be more C++-avoidance hackery".

Richard