Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > difference between pointers

Reply
Thread Tools

difference between pointers

 
 
Tim Rentsch
Guest
Posts: n/a
 
      04-11-2013
Jorgen Grahn <(E-Mail Removed)> writes:

> On Tue, 2013-04-02, Tim Rentsch wrote:
>> Varun Tewari <(E-Mail Removed)> writes:
>>
>>> Yep it did give warning. Thnx for pointing the correct gcc option for
>>> correct ansi parsing.

>>
>> You may also want to try
>>
>> gcc -std=c99 -pedantic-errors

> ...
>> gcc -std=c11 -pedantic-errors

>
> I strongly recommend
>
> -std=something -Wall -Wextra -pedantic -O2
>
> [snip elaboration]


I used to be a fan of -Wall and -W (aka -Wextra). Now,
not so much. In no particular order, my complaints are:

* I believe good programming practice normally treats
warnings as errors (ie, -Werror in gcc). Using -Wall
or -Wextra sometimes works at cross-purposes to that.

* The set of warnings included in -Wall or -Wextra include
some that are purely stylistic and have no bearing on
code correctness.

* IMO some of the style warnings are not just neutral but
actually bad.

* Some -Wall/-Wextra warning conditions can be removed
selectively with other option settings, but some can't.

* In cases where a warning class indicates a potential
code problem, there often are too many false positives.
This has the effect of training people either to muck
their code about just to shut up the compiler, or to
ignore warnings; neither of these is a good thing.

* The documentation is wrong, at least in the sense of
being incomplete -- there are warnings that come out
under -Wall or -Wextra that don't correspond to any
of the described warning conditions (and hence there
is no way to turn them off, at least not that I could
find).

* Moving target - the set of warnings included under -Wall
or -Wextra in one version of gcc might change in the next
version of gcc. It is very disconcerting to find code
thought to be completely clean suddenly start generating
warnings when compiled in a new environment.

There are lots of individual warnings in gcc that are quite
valuable, eg, "variable might not be initialized before use."
But rather than using the -Wall/-Wextra shotgun to turn
everything on, it's better to turn the high quality warning
conditions on individually, and not use the others. And also
-Werror, or at least -pedantic-errors (and please let the GNU
people know when -pedantic-errors gives an error for something
that is only undefined behavior, and not a syntax/constraint
violation).
 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      04-11-2013
Jorgen Grahn <(E-Mail Removed)> writes:

> On Tue, 2013-04-02, Tim Rentsch wrote:
>> Varun Tewari <(E-Mail Removed)> writes:
>>
>>> Yep it did give warning. Thnx for pointing the correct gcc option for
>>> correct ansi parsing.

>>
>> You may also want to try
>>
>> gcc -std=c99 -pedantic-errors

> ...
>> gcc -std=c11 -pedantic-errors

>
> I strongly recommend
>
> -std=something -Wall -Wextra -pedantic -O2
>
> [...]


Another complaint I forgot:

* Usually turning on optimization (eg, -O2) will allow
additional warning conditions to be checked, but it
also can have the effect of removing some warnings
that are generated without it.
 
Reply With Quote
 
 
 
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      04-11-2013
Tim Rentsch <(E-Mail Removed)> wrote:

(snip of things I already agree with)

> * In cases where a warning class indicates a potential
> code problem, there often are too many false positives.
> This has the effect of training people either to muck
> their code about just to shut up the compiler, or to
> ignore warnings; neither of these is a good thing.


Yes. People often consider the benefit of adding a warning,
but not its cost. Looking through false positives is a
definite cost.

> * The documentation is wrong, at least in the sense of
> being incomplete -- there are warnings that come out
> under -Wall or -Wextra that don't correspond to any
> of the described warning conditions (and hence there
> is no way to turn them off, at least not that I could
> find).


> * Moving target - the set of warnings included under -Wall
> or -Wextra in one version of gcc might change in the next
> version of gcc. It is very disconcerting to find code
> thought to be completely clean suddenly start generating
> warnings when compiled in a new environment.


I suppose that could be fixed with a warning version option,
not to generate warnings added since a specific version of
the compiler. Not likely to be added, though.

> There are lots of individual warnings in gcc that are quite
> valuable, eg, "variable might not be initialized before use."


I somewhat like the Java idea on this. Any variable that the
compiler can't detect is initialized before use is an error.

Sometimes the compiler doesn't see something that you know,
but reasonably often it is right.

> But rather than using the -Wall/-Wextra shotgun to turn
> everything on, it's better to turn the high quality warning
> conditions on individually, and not use the others. And also
> -Werror, or at least -pedantic-errors (and please let the GNU
> people know when -pedantic-errors gives an error for something
> that is only undefined behavior, and not a syntax/constraint
> violation).


I suppose those could be selected separately if one wanted them.

-- glen
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      04-12-2013
glen herrmannsfeldt <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> wrote:
> [snip]
>> There are lots of individual warnings in gcc that are quite
>> valuable, eg, "variable might not be initialized before use."

>
> I somewhat like the Java idea on this. Any variable that the
> compiler can't detect is initialized before use is an error.


Java pays a price for this choice, namely, the algorithm for
deciding whether a variable has been initialized therefore
must be included as part of the language definition. (And
whatever algorithm is chosen, it can't be right all the time,
because the problem is undecidable.) That choice may be a
good choice for Java, but IMO it would be a bad one for C.
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      04-12-2013
Tim Rentsch <(E-Mail Removed)> wrote:
> glen herrmannsfeldt <(E-Mail Removed)> writes:


>> Tim Rentsch <(E-Mail Removed)> wrote:
>> [snip]
>>> There are lots of individual warnings in gcc that are quite
>>> valuable, eg, "variable might not be initialized before use."


>> I somewhat like the Java idea on this. Any variable that the
>> compiler can't detect is initialized before use is an error.


> Java pays a price for this choice, namely, the algorithm for
> deciding whether a variable has been initialized therefore
> must be included as part of the language definition. (And
> whatever algorithm is chosen, it can't be right all the time,
> because the problem is undecidable.)


I have wondered about that. Seems that you might get away
with improving the algorithm, such that old programs would
still compile. New ones might not compile on old compilers,
but then they might not anyway if they use new features.

But as for the undecidable, the default is that it is
an error. That is, if the compiler can't prove that it is
defined before use, it is an error.

That is only for scalar variables. Arrays are always initialized
to zero when allocated.

> That choice may be a good choice for Java, but IMO
> it would be a bad one for C.


I agree.

(Besides, it is a little late now.)

-- glen
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      04-12-2013
On Thu, 2013-04-11, Tim Rentsch wrote:
> Jorgen Grahn <(E-Mail Removed)> writes:
>
>> On Tue, 2013-04-02, Tim Rentsch wrote:
>>> Varun Tewari <(E-Mail Removed)> writes:
>>>
>>>> Yep it did give warning. Thnx for pointing the correct gcc option for
>>>> correct ansi parsing.
>>>
>>> You may also want to try
>>>
>>> gcc -std=c99 -pedantic-errors

>> ...
>>> gcc -std=c11 -pedantic-errors

>>
>> I strongly recommend
>>
>> -std=something -Wall -Wextra -pedantic -O2
>>
>> [snip elaboration]


This part of the elaboration is important:

>> It's a good start for new code [...]


I didn't intend to suggest the flags above as the universal solution
to all problems.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      04-13-2013
glen herrmannsfeldt <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> wrote:
>> glen herrmannsfeldt <(E-Mail Removed)> writes:

>
>>> Tim Rentsch <(E-Mail Removed)> wrote:
>>> [snip]
>>>> There are lots of individual warnings in gcc that are quite
>>>> valuable, eg, "variable might not be initialized before use."
>>>
>>> I somewhat like the Java idea on this. Any variable that the
>>> compiler can't detect is initialized before use is an error.

>>
>> Java pays a price for this choice, namely, the algorithm for
>> deciding whether a variable has been initialized therefore
>> must be included as part of the language definition. (And
>> whatever algorithm is chosen, it can't be right all the time,
>> because the problem is undecidable.)

>
> I have wondered about that. Seems that you might get away
> with improving the algorithm, such that old programs would
> still compile. New ones might not compile on old compilers,
> but then they might not anyway if they use new features.


A new language definition could choose a different algorithm, or
specify an initialization rule for all declared variables, or
allow uninitialized variables, or some combination of the above.
But compilers have to do what the language definition says, for
whatever language they are implementing.

> But as for the undecidable, the default is that it is
> an error.


What you mean is that the language definition for Java has
chosen a conservative algorithm that never mis-identifies an
uninitialized variable as having been initialized. And I
believe that's right.

> That is, if the compiler can't prove that it is defined
> before use, it is an error.


The compiler is obliged to do whatever the language definition
says, which completely defines the result, with no latitude
left to the compiler. Anything else is not consistent with
the "Write once, run anywhere" philosophy that Java espouses.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      04-13-2013
Jorgen Grahn <(E-Mail Removed)> writes:

> On Thu, 2013-04-11, Tim Rentsch wrote:
>> Jorgen Grahn <(E-Mail Removed)> writes:
>>
>>> On Tue, 2013-04-02, Tim Rentsch wrote:
>>>> Varun Tewari <(E-Mail Removed)> writes:
>>>>
>>>>> Yep it did give warning. Thnx for pointing the correct gcc option for
>>>>> correct ansi parsing.
>>>>
>>>> You may also want to try
>>>>
>>>> gcc -std=c99 -pedantic-errors
>>> ...
>>>> gcc -std=c11 -pedantic-errors
>>>
>>> I strongly recommend
>>>
>>> -std=something -Wall -Wextra -pedantic -O2
>>>
>>> [snip elaboration]

>
> This part of the elaboration is important:
>
>>> It's a good start for new code [...]


Yes, my snipping here was a bit overzealous. Sorry about that.

However, that qualifier doesn't lessen my reaction -- if anything
it intensifies it. Using -Wall and -Wextra on new code is the
worst place to use them, because that's where they are most
likely to nudge people into bad habits, or cause problems later.
It is much better to use -Wall/-Wextra sparingly, on source code
that is more mature, as an independent sanity check or quality
assessment step. Using -Wall or -Wextra on a regular basis,
especially as a default for new code, is IMO a bad practice and
one likely to lead to poor coding habits.

> I didn't intend to suggest the flags above as the universal
> solution to all problems.


Certainly that was not my impression, and I hope my comments
didn't suggest otherwise.
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      04-13-2013
On Sat, 2013-04-13, Tim Rentsch wrote:
> Jorgen Grahn <(E-Mail Removed)> writes:
>
>> On Thu, 2013-04-11, Tim Rentsch wrote:
>>> Jorgen Grahn <(E-Mail Removed)> writes:
>>>
>>>> On Tue, 2013-04-02, Tim Rentsch wrote:
>>>>> Varun Tewari <(E-Mail Removed)> writes:
>>>>>
>>>>>> Yep it did give warning. Thnx for pointing the correct gcc option for
>>>>>> correct ansi parsing.
>>>>>
>>>>> You may also want to try
>>>>>
>>>>> gcc -std=c99 -pedantic-errors
>>>> ...
>>>>> gcc -std=c11 -pedantic-errors
>>>>
>>>> I strongly recommend
>>>>
>>>> -std=something -Wall -Wextra -pedantic -O2
>>>>
>>>> [snip elaboration]

>>
>> This part of the elaboration is important:
>>
>>>> It's a good start for new code [...]

>
> Yes, my snipping here was a bit overzealous. Sorry about that.
>
> However, that qualifier doesn't lessen my reaction -- if anything
> it intensifies it. Using -Wall and -Wextra on new code is the
> worst place to use them, because that's where they are most
> likely to nudge people into bad habits, or cause problems later.
> It is much better to use -Wall/-Wextra sparingly, on source code
> that is more mature, as an independent sanity check or quality
> assessment step. Using -Wall or -Wextra on a regular basis,
> especially as a default for new code, is IMO a bad practice and
> one likely to lead to poor coding habits.
>
>> I didn't intend to suggest the flags above as the universal
>> solution to all problems.

>
> Certainly that was not my impression, and I hope my comments
> didn't suggest otherwise.


Ok, good. But we're still on opposide sides: IMO -Wall, -Wextra and
-pedantic lead to *good* habits in the usual case.

(There's one class of warnings I would agree are problematic, and
that's the ones for unused static functions, parameters and variables.
Useful, but when they don't alert you to an actual bug, it's often
hard to do anything about them without making the code worse. And yes,
I refuse to do that just to please the compiler.)

Others will have to make up their own minds, I guess.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Noob
Guest
Posts: n/a
 
      04-13-2013
Tim Rentsch wrote:

> Usually turning on optimization (eg, -O2) will allow
> additional warning conditions to be checked, but it
> also can have the effect of removing some warnings
> that are generated without it.


Do you have an example?

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
pointers, pointers, pointers... cerr C Programming 12 04-07-2011 11:17 PM
Difference between function pointers ram kishore C Programming 8 07-27-2008 04:02 PM
[pointers and arrays]: The difference between an array name and a pointer iamchiaweilin@gmail.com C Programming 7 10-02-2006 11:03 PM
Difference between bin and obj directories and difference between project references and dll references jakk ASP .Net 4 03-22-2005 09:23 PM
Why do so few people know the difference between arrays and pointers. Me C Programming 79 06-18-2004 12:35 PM



Advertisments