Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #88991 > unrolled thread
| Started by | G G <gdotone@gmail.com> |
|---|---|
| First post | 2016-06-12 16:21 -0700 |
| Last post | 2016-06-16 21:39 -0700 |
| Articles | 7 on this page of 87 — 20 participants |
Back to article view | Back to comp.lang.c
setting pointers to NULL and testing question. G G <gdotone@gmail.com> - 2016-06-12 16:21 -0700
Re: setting pointers to NULL and testing question. Richard Heathfield <rjh@cpax.org.uk> - 2016-06-13 00:50 +0100
Re: setting pointers to NULL and testing question. G G <gdotone@gmail.com> - 2016-06-12 17:03 -0700
Re: setting pointers to NULL and testing question. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-06-12 20:25 -0600
Re: setting pointers to NULL and testing question. James Kuyper <jameskuyper@verizon.net> - 2016-06-12 22:57 -0400
Re: setting pointers to NULL and testing question. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-06-13 10:03 -0600
Re: setting pointers to NULL and testing question. Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-15 14:43 -0700
Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-13 08:06 -0700
Re: setting pointers to NULL and testing question. Richard Damon <Richard@Damon-Family.org> - 2016-06-16 08:27 -0400
Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-16 06:27 -0700
Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-16 07:31 -0700
Re: setting pointers to NULL and testing question. Richard Damon <Richard@Damon-Family.org> - 2016-06-18 13:39 -0400
Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-18 11:37 -0700
Re: setting pointers to NULL and testing question. Richard Damon <Richard@Damon-Family.org> - 2016-06-18 17:17 -0400
Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-18 17:22 -0700
Re: setting pointers to NULL and testing question. James Kuyper <jameskuyper@verizon.net> - 2016-06-13 14:10 -0400
Re: setting pointers to NULL and testing question. Keith Thompson <kst-u@mib.org> - 2016-06-13 11:28 -0700
Re: setting pointers to NULL and testing question. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-06-13 12:31 -0600
Re: setting pointers to NULL and testing question. Keith Thompson <kst-u@mib.org> - 2016-06-12 19:38 -0700
Re: setting pointers to NULL and testing question. Richard Heathfield <rjh@cpax.org.uk> - 2016-06-13 07:35 +0100
Re: setting pointers to NULL and testing question. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-13 11:40 +0100
Re: setting pointers to NULL and testing question. BartC <bc@freeuk.com> - 2016-06-13 11:56 +0100
Re: setting pointers to NULL and testing question. Martin Shobe <mashobe9@gmail.com> - 2016-06-13 06:22 -0500
Re: setting pointers to NULL and testing question. BartC <bc@freeuk.com> - 2016-06-13 12:39 +0100
Re: setting pointers to NULL and testing question. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-13 15:22 +0100
Re: setting pointers to NULL and testing question. BartC <bc@freeuk.com> - 2016-06-13 17:34 +0100
Re: setting pointers to NULL and testing question. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-13 19:31 +0100
Re: setting pointers to NULL and testing question. BartC <bc@freeuk.com> - 2016-06-13 20:17 +0100
Re: setting pointers to NULL and testing question. Keith Thompson <kst-u@mib.org> - 2016-06-13 12:47 -0700
Re: setting pointers to NULL and testing question. Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-15 16:44 -0700
Re: setting pointers to NULL and testing question. Keith Thompson <kst-u@mib.org> - 2016-06-15 17:20 -0700
Re: setting pointers to NULL and testing question. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-13 04:01 -0700
Re: setting pointers to NULL and testing question. Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-16 12:57 -0700
Re: setting pointers to NULL and testing question. Richard Heathfield <rjh@cpax.org.uk> - 2016-06-13 12:18 +0100
Re: setting pointers to NULL and testing question. David Brown <david.brown@hesbynett.no> - 2016-06-13 14:01 +0200
Re: setting pointers to NULL and testing question. Richard Heathfield <rjh@cpax.org.uk> - 2016-06-13 14:15 +0100
Re: setting pointers to NULL and testing question. David Brown <david.brown@hesbynett.no> - 2016-06-13 15:37 +0200
Re: setting pointers to NULL and testing question. Richard Heathfield <rjh@cpax.org.uk> - 2016-06-13 14:48 +0100
Re: setting pointers to NULL and testing question. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-13 15:43 +0100
Re: setting pointers to NULL and testing question. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-12 17:54 -0700
Re: setting pointers to NULL and testing question. John Bode <jfbode1029@gmail.com> - 2016-06-14 08:36 -0700
Re: setting pointers to NULL and testing question. Richard Heathfield <rjh@cpax.org.uk> - 2016-06-14 16:41 +0100
Re: setting pointers to NULL and testing question. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-14 09:01 -0700
Re: setting pointers to NULL and testing question. "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-14 13:25 -0400
Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-14 10:48 -0700
Re: setting pointers to NULL and testing question. Ian Collins <ian-news@hotmail.com> - 2016-06-15 08:24 +1200
Re: setting pointers to NULL and testing question. "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-14 16:57 -0400
Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-14 14:29 -0700
Re: setting pointers to NULL and testing question. BartC <bc@freeuk.com> - 2016-06-14 22:41 +0100
Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-14 15:16 -0700
Re: setting pointers to NULL and testing question. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-15 00:25 +0100
Re: setting pointers to NULL and testing question. Keith Thompson <kst-u@mib.org> - 2016-06-14 16:58 -0700
Re: setting pointers to NULL and testing question. David Brown <david.brown@hesbynett.no> - 2016-06-15 09:28 +0200
Re: setting pointers to NULL and testing question. Keith Thompson <kst-u@mib.org> - 2016-06-15 09:57 -0700
Re: setting pointers to NULL and testing question. David Brown <david.brown@hesbynett.no> - 2016-06-15 09:23 +0200
Re: setting pointers to NULL and testing question. Richard Heathfield <rjh@cpax.org.uk> - 2016-06-15 08:35 +0100
Re: setting pointers to NULL and testing question. Richard Heathfield <rjh@cpax.org.uk> - 2016-06-15 08:37 +0100
Re: setting pointers to NULL and testing question. David Brown <david.brown@hesbynett.no> - 2016-06-15 10:42 +0200
Re: setting pointers to NULL and testing question. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-15 13:28 +0100
Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-15 11:41 -0700
Re: setting pointers to NULL and testing question. raltbos@xs4all.nl (Richard Bos) - 2016-06-15 19:43 +0000
Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-15 13:09 -0700
Re: setting pointers to NULL and testing question. David Brown <david.brown@hesbynett.no> - 2016-06-15 22:31 +0200
Re: setting pointers to NULL and testing question. Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-15 17:11 -0400
Re: setting pointers to NULL and testing question. raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:44 +0000
Re: setting pointers to NULL and testing question. Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-18 17:20 -0400
Re: setting pointers to NULL and testing question. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-14 23:22 -0700
Re: setting pointers to NULL and testing question. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-15 13:23 +0100
Re: setting pointers to NULL and testing question. John Bode <jfbode1029@gmail.com> - 2016-06-20 13:36 -0700
Re: setting pointers to NULL and testing question. Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-14 14:59 -0400
Re: setting pointers to NULL and testing question. "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-14 15:17 -0400
Re: setting pointers to NULL and testing question. Richard Heathfield <rjh@cpax.org.uk> - 2016-06-14 20:25 +0100
Re: setting pointers to NULL and testing question. Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-15 19:48 -0700
Re: setting pointers to NULL and testing question. Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-15 23:25 -0400
Re: setting pointers to NULL and testing question. James Kuyper <jameskuyper@verizon.net> - 2016-06-16 12:11 -0400
Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-16 09:25 -0700
Re: setting pointers to NULL and testing question. Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-16 21:46 -0700
Re: setting pointers to NULL and testing question. Gareth Owen <gwowen@gmail.com> - 2016-06-17 06:13 +0100
Re: setting pointers to NULL and testing question. Robert Wessel <robertwessel2@yahoo.com> - 2016-06-17 02:03 -0500
Re: setting pointers to NULL and testing question. Martin Shobe <mashobe9@gmail.com> - 2016-06-17 07:07 -0500
Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-17 03:18 -0700
Re: setting pointers to NULL and testing question. James Kuyper <jameskuyper@verizon.net> - 2016-06-17 09:16 -0400
Re: setting pointers to NULL and testing question. Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-21 11:03 -0700
Re: setting pointers to NULL and testing question. Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-21 10:58 -0700
Re: setting pointers to NULL and testing question. Keith Thompson <kst-u@mib.org> - 2016-06-21 11:28 -0700
Re: setting pointers to NULL and testing question. Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-18 08:24 -0700
Re: setting pointers to NULL and testing question. Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-16 21:39 -0700
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-06-17 03:18 -0700 |
| Message-ID | <1e22e2e2-1bbd-4792-92c9-e7ffdd494d07@googlegroups.com> |
| In reply to | #89366 |
On Friday, June 17, 2016 at 12:13:38 AM UTC-5, gwowen wrote: > There are no cases a compiler *can't* catch. There are cases that > compilers don't catch[0]. Most notably, if a pointer to an uninitialized > variable is passed to a function defined in a different translation > unit. Those can be caught in languages which require that variables be initialized before pointers or references are exposed to outside code in ways that would permit them to be read (some languages suppose "out" parameters to allow for the case where a called function will be responsible for initializing a variable, but then require the called function must write a value before exiting via any code path).
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-06-17 09:16 -0400 |
| Message-ID | <nk0t76$ber$2@dont-email.me> |
| In reply to | #89366 |
On 06/17/2016 01:13 AM, Gareth Owen wrote: > Tim Rentsch <txr@alumni.caltech.edu> writes: > >>> Counter: >>> If an uninitialized variable is used before being initialized, in a way >>> that the compiler can't catch - it will cause problems. [...] >> >> There are no such cases. I didn't mean "can't catch" in the sense that "no algorithm can be designed to catch them". I meant it in the sense that "the particular algorithm used by this particular compiler can't catch them". The key point is that these messages are not mandatory. It's entirely up to the implementor whether such warning messages are provided, and under what circumstances. The implementation might, therefore, fail to issue such messages in some cases where I'd like it to.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-06-21 11:03 -0700 |
| Message-ID | <kfna8ie1ktd.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #89408 |
James Kuyper <jameskuyper@verizon.net> writes: > On 06/17/2016 01:13 AM, Gareth Owen wrote: >> Tim Rentsch <txr@alumni.caltech.edu> writes: >> >>>> Counter: >>>> If an uninitialized variable is used before being initialized, in a way >>>> that the compiler can't catch - it will cause problems. [...] >>> >>> There are no such cases. > > I didn't mean "can't catch" in the sense that "no algorithm can be > designed to catch them". I meant it in the sense that "the particular > algorithm used by this particular compiler can't catch them". A better phrasing is that the algorithm /does not/ catch them. It is precisely the distinction between /does not/ and /can not/ that prompted my earlier response. > The key point is that these messages are not mandatory. It's entirely up > to the implementor whether such warning messages are provided, and under > what circumstances. The implementation might, therefore, fail to issue > such messages in some cases where I'd like it to. I agree that is an important practical consideration, but it has no bearing on the point I was making.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-06-21 10:58 -0700 |
| Message-ID | <kfneg7q1l12.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #89366 |
Gareth Owen <gwowen@gmail.com> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: > >>> Counter: >>> If an uninitialized variable is used before being initialized, in a way >>> that the compiler can't catch - it will cause problems. [...] >> >> There are no such cases. > > There are no cases a compiler *can't* catch. There are cases that > compilers don't catch[0]. Most notably, if a pointer to an uninitialized > variable is passed to a function defined in a different translation > unit. > >> A conservative analysis can catch every situation where a variable >> might be used before being given an initial value, provided of course >> that we are willing to tolerate some false positives. > > A sufficiently good compiler .... > Nevertheless, no existing compiler known to me does such an exhaustive search. > > [0] There are also cases that a single compiler sometimes catches, > depending on which compiler flags you use. Optimisations often > catch extra things. I pretty much agree with everything you say. Two comments though. On the last point, it also can happen that turning on optimizations get rid of warnings (pretty sure I have this happen although I can't swear to it). The inconsistency (in either direction) is regrettable. Also, it isn't that it's hard to write code that is guaranteed to catch all cases of uninitialized variables. Rather, compiler writers choose not to report them in the interest of not giving too many false positives. Obviously in some circumstances that could be a good decision. It's unfortunate that there isn't a compiler option to say, "let me know if there is even a remote chance that a variable might not be initialized", because it isn't hard to provide that capability (assuming there is is a demand for it).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-06-21 11:28 -0700 |
| Message-ID | <lnlh1yqtui.fsf@kst-u.example.com> |
| In reply to | #89363 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> James Kuyper <jameskuyper@verizon.net> writes:
[...]
>> Counter:
>> If an uninitialized variable is used before being initialized, in a way
>> that the compiler can't catch - it will cause problems. [...]
>
> There are no such cases. A conservative analysis can catch every
> situation where a variable might be used before being given an
> initial value, provided of course that we are willing to tolerate
> some false positives.
The degenerate algorithm is to flag every variable reference with
a warning that it might be used without having been initialized.
This will catch all cases where variables are used before being
initialized, but with enough false positives to make it useless.
A more nearly reasonable approach is to flag any use where the
compiler can't *prove* that the variable has been initialized.
This avoids the most obvious false positives (assuming a reasonably
clever compiler), but it's still likely to produce too many
spurious warnings -- unless, as you suggest downthread, there's
an option to say "gimme those spurious warnings anyway, I want to
see *everything*".
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-18 08:24 -0700 |
| Message-ID | <kfn8twzyno4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #89718 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> James Kuyper <jameskuyper@verizon.net> writes: > > [...] > >>> Counter: >>> If an uninitialized variable is used before being initialized, in a way >>> that the compiler can't catch - it will cause problems. [...] >> >> There are no such cases. A conservative analysis can catch every >> situation where a variable might be used before being given an >> initial value, provided of course that we are willing to tolerate >> some false positives. > > The degenerate algorithm is to flag every variable reference with > a warning that it might be used without having been initialized. [...] I had in mind a slightly more sophisticated degenerate algorithm: to flag any block-scope variable (that is or might be used for lvalue conversion) without an initializer in its declaration. :) > A more nearly reasonable approach is to flag any use where the > compiler can't *prove* that the variable has been initialized. > This avoids the most obvious false positives (assuming a reasonably > clever compiler), but it's still likely to produce too many > spurious warnings -- unless, as you suggest downthread, there's > an option to say "gimme those spurious warnings anyway, I want to > see *everything*". I think I understand your point, but how the comment is phrased is IMO misleading. In cases where variables are used only locally, static analysis can do a pretty good job of determining which reads might be getting an uninitialized variable. (Also I don't think that is overly hard to do, given the kinds of analysis already done in optimizing compilers.) Sometimes there will be some false positives in these cases, but that almost always means code that is complicated enough so that a warning is a good idea anyway. The big problem is not when static analysis can be done, but when it cannot be done, which in C usually means that a variable had its address taken and passed off to some function in another translation unit. Now the compiler is at a loss: the information needed to do analysis simply isn't there, and such cases must be flagged if warnings are being issued conservatively. I wouldn't label such a warning as spurious, because for all we know the function being called didn't (or will not in some future compilation) do its job, and an unintialized read may occur. A better characterization is to say such cases are annoying, because programmers "know" (ie, they expect) that a value will be assigned and things will be okay. But from the point of view of compiling just this .c file, a use like that should be flagged as a potential problem. Now I am curious what the results would be if "uninitialized" warnings were divided into two categories, one where there is enough local information to determine a result, and one where a result cannot be determined because it depends on non-local information (such as passing a variable's address to a function in another TU). My guess is that the first category can be made sufficiently good so it's worth flagging all of them, with false positives being accepted as indicating the code is in need of re-writing anyway.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-06-16 21:39 -0700 |
| Message-ID | <kfn4m8s2zua.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #89250 |
Eric Sosman <esosman@comcast-dot-net.invalid> writes: > On 6/15/2016 10:48 PM, Tim Rentsch wrote: >> Eric Sosman <esosman@comcast-dot-net.invalid> writes: >> >>> On 6/14/2016 11:36 AM, John Bode wrote: >>>> On Sunday, June 12, 2016 at 6:21:40 PM UTC-5, G G wrote: >>>>> when should a pointer to set to NULL and test whether >>>>> it is NULL? >>>> >>>> In a non-static declaration, a pointer variable should always be initialized >>>> explicitly to NULL or to a valid pointer value: >>>> [...] >>> >>> The arguments both for and against this practice are, I think, >>> too well-known to bear yet another repetition. [...] >> >> Pretend for a moment you were talking to someone who hadn't >> heard both (or perhaps either) points of view. Can you give >> a brief statement of the reasons for and against, without >> advocating either side but just listing what motivations >> are commonly given? > > PRO: An uninitialized pointer variable has an indeterminate value, > leading to unpredictable behavior if that variable is dereferenced. A > pointer variable initialized to NULL has a well-determined value, but > still yields undefined behavior if dereferenced. Nonetheless, the > undefined behavior resulting from a NULL dereference is more likely to > be reproducible than if the variable had an indeterminate value, and > "solid" bugs are easier to find and fix than "Heisenbugs." > > CON: Compilers are pretty good at warning if a variable is used > when there exists some execution path that fails to give the variable > a value prior to use. Routinely initializing to NULL defeats any such > warnings, because no such paths exist. It is better to learn about > "may be used uninitialized" from the compiler than (perhaps) from > testing, or from irate customers. > > COUNTER-PRO: But, but, but!!! > > COUNTER-CON: But, but, but!!! > > (For myself, I'm a CON. Hoping for parole.) Thank you, this is just what I was looking for.
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c
csiph-web