[ale] [OT] Anyone up for a 90 Day Wonder Challenge?
Byron Jeff
byronjeff at clayton.edu
Thu Dec 3 10:48:56 EST 2015
On Thu, Dec 03, 2015 at 09:40:33AM -0500, Ed Cashin wrote:
> I wasn't thinking of memory management (although I agree that adopting
> conventions helps avoid errors in that domain).
> I'm thinking of the difference between truly grokking the power of
> multiple levels of read-write indirection. A deep comfort with the use
> of pointers is what Linus Torvalds was talking about here:
>
> [1]http://meta.slashdot.org/story/12/10/11/0030249/linus-torvalds-answe
> rs-your-questions
>
> ... when he talks about linked list operations. Here's a quote:
>
> At the opposite end of the spectrum, I actually wish more people
> understood the really core low-level kind of coding. Not big,
> complex stuff like the lockless name lookup, but simply good use of
> pointers-to-pointers etc. For example, I've seen too many people who
> delete a singly-linked list entry by keeping track of the "prev"
> entry, and then to delete the entry, doing something like
> if (prev)
> prev->next = entry->next;
> else
> list_head = entry->next;
> and whenever I see code like that, I just go "This person doesn't
> understand pointers". And it's sadly quite common.
> People who understand pointers just use a "pointer to the entry
> pointer", and initialize that with the address of the list_head. And
> then as they traverse the list, they can remove the entry without
> using any conditionals, by just doing a "*pp = entry->next".
>
The above example isn't exactly a lack of understanding. Everyone uses a
subset of programming languages that they feel comfortable with. While the
code above isn't sexy, it is clear and it does work.
Lack of understanding of pointers is code that leads to data loss or access
failure. For example something like:
prev->next = prev->next->next;
This blows up if prev is pointing to the end of the list. It also loses the
node that prev->next was pointing to if it wasn't pointing to the end of
the list. This scenario is much more likely with novice to intermediate
pointer programmers.
When I used to teach C, I always taught my students to change pointers in a
particular order to prevent mishaps of losing data. The rules of pointer management:
1. Change new pointers first. Since they are new they have no valid contents.
2. Change NULL pointers next. NULL is a fixed value that can be accessed at
any time.
3. Change duplicate pointers (i.e. a pointer with another pointer pointing
to the same object) next. Since they are duplicates, the object is still
accessible.
and the most important rule:
4. If a pointer is in none of the above 3 categories, DO NOT CHANGE IT!
So in the example above prev->next is likely in category 4, so unless you
duplicate it (which entry was in the initial example), you cannot change it
at all.
BAJ
>
>
> On Thu, Dec 3, 2015 at 9:03 AM, DJ-Pfulio <[2]djpfulio at jdpfu.com>
> wrote:
>
> Pointers are easy.
> Either they point to valid, allocated memory (or a function), or
> they point to
> NULL. PERIOD. A null pointer exception is much nicer than any bug
> that seems to
> work.
> char* myName=NULL;
> myName = malloc( sizeof("1234546789") );
> if ( NULL == myName ) return; /* Always validate the desired memory
> allocation
> worked */
> /* do something interesting ; pass myName around, into functions,
> etc .... */
> free(myName);
> myName=NULL;
> /* Any attempts to reference myName now will provide a null pointer
> exception
> and crash (throw exception). */
> BTW, I haven't written any C code that uses malloc() since ....
> 1995-ish, so
> don't expect that to compile cleanly. Writing clear C code is VERY
> important.
> Sure, there are wasted statements, but there is a reason. Clarity. A
> good
> compiler will optimize out any wasted code. Some of this code will
> be running in
> 50 yrs, perhaps longer. Make the source clear, always.
> I don't expect a SmartPtr class to manage memory for me. They tend
> to do things
> when I don't want and do it in a way different from what I'd like.
> Simple. Good pointer management is an important skill for all
> programmers, even
> python, java, and other languages that don't provide direct access
> to pointers.
> After all, what is a reference? It is just a pointer. Perl has
> references and
> they are used ALL-THE-TIME.
> On 12/03/2015 08:22 AM, Ed Cashin wrote:
> > For some reason this statement reminded me that there was a
> critical
> > supplement to all the C books I read.
> >
> > Ted Jensen's pointer tutorial:
> >
> > [3]http://pw1.netcom.com/~tjensen/ptr/pointers.htm
> >
> > ... will eliminate any residual discomfort with pointers. It's a
> gem.
> >
> >
> >
> > On Wed, Dec 2, 2015 at 3:05 PM, Boris Borisov
> <[4]bugyatl at gmail.com> wrote:
> >
> >> I guess everybody is reading their C books. So quiet:)
> >>
> >> On Wednesday, December 2, 2015, Scott M. Jones
> <[5]eff at dragoncon.org> wrote:
> >>
> >>> [6]talky.io claims to do screen sharing. That's why I'd like to
> test to
> >>> see how well it works, and if it works at all for bare metal
> Linux.
> >>>
> >>> [7]https://about.talky.io
> >>>
> >>>
> >>>
> >>> On 12/2/15 11:30 AM, DjPfulio wrote:
> >>>>
> >>>> The problem with web RTC is its only webcam based; how do we
> share
> >>>> screens through it? that's the problem.
> >>>>
> >>>> On 2 December 2015 10:08:09 GMT-05:00, "Scott M. Jones"
> >>>> <[8]eff at dragoncon.org> wrote:
> >>>>
> >>>> On 11/26/15 6:41 AM, Leam Hall wrote:
> >>>>
> >>>> Soo...Scott, does that mean you're volunteering to be a
> resident
> >>>> mentor? :P
> >>>>
> >>>>
> >>>> I'd be interested in helping to the extent that I can. We
> went to
> >>> C++
> >>>> in 2001 and Java in 2006, and sinc> options. One
> possibility
> >>> not mentioned so far is [9]talky.io <[10]http://talky.
> <[11]http://talky.io>>
> >>> __________
>
> >>
> >>
> _______________________________________________
> Ale mailing list
> [12]Ale at ale.org
> [13]http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> [14]http://mail.ale.org/mailman/listinfo
>
> --
> Ed Cashin <[15]ecashin at noserose.net>
>
> References
>
> 1. http://meta.slashdot.org/story/12/10/11/0030249/linus-torvalds-answers-your-questions
> 2. mailto:djpfulio at jdpfu.com
> 3. http://pw1.netcom.com/~tjensen/ptr/pointers.htm
> 4. mailto:bugyatl at gmail.com
> 5. mailto:eff at dragoncon.org
> 6. http://talky.io/
> 7. https://about.talky.io/
> 8. mailto:eff at dragoncon.org
> 9. http://talky.io/
> 10. http://talky/
> 11. http://talky.io/
> 12. mailto:Ale at ale.org
> 13. http://mail.ale.org/mailman/listinfo/ale
> 14. http://mail.ale.org/mailman/listinfo
> 15. mailto:ecashin at noserose.net
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
--
Byron A. Jeff
Associate Professor: Department of Computer Science and Information Technology
College of Information and Mathematical Sciences
Clayton State University
http://faculty.clayton.edu/bjeff
More information about the Ale
mailing list