Dan­gling Point­ers Avoid them Strictly!

This ar­ti­cle takes off from an ear­lier one on con­stant point­ers. Here, the fo­cus is on dan­gling point­ers—how they oc­cur and how to pre­vent them. The ar­ti­cle is a great guide for C new­bies.

OpenSource For You - - CONTENTS -

Dan­gling point­ers are those in the C pro­gram­ming lan­guage that do not point to valid ob­jects. Point­ers are like sharp knives that have tremen­dous power in C pro­gram­ming. When used prop­erly, they re­duce the com­plex­ity of the pro­grams to a great ex­tent. But when not used prop­erly, they re­sult in ad­verse ef­fects and, in the worst case sce­nario, may crash the sys­tem.

In this ar­ti­cle, I mainly fo­cus on dan­gling point­ers and what causes them by look­ing at sev­eral dif­fer­ent sit­u­a­tions in which they oc­cur. I also sug­gest sim­ple meth­ods to avoid them.

Note: Code snip­pets pro­vided here are tested with the GCC com­piler [gcc ver­sion 4.7.3] run­ning un­der the Linux en­vi­ron­ment.

Let’s now look at three dif­fer­ent cases that give rise to dan­gling point­ers.

Case 1: When a func­tion re­turns the ad­dress of the auto vari­ables

Con­sider the sim­ple code snip­pet given be­low (Code 1):

When we run the pro­gram shown in Code 1 in the GCC com­piler, we get the warn­ing shown in Fig­ure 1.

What is wrong when the ad­dress of the auto/lo­cal vari­ables is re­turned? Let us ex­am­ine this in de­tail: 1. We know that when­ever there is a func­tion call, a new stack frame will be cre­ated au­to­mat­i­cally, where auto vari­able au­to_­var is lo­cal in our ex­am­ple. Its scope and life­time is within the func­tion call. 2. When the con­trol re­turns from the func­tion call, all the

mem­ory al­lo­cated for that func­tion will be freed au­to­mat­i­cally. 3. In our ex­am­ple pro­gram, we are re­turn­ing the ad­dress of the auto vari­able and col­lect­ing this in the in­t_ptr pointer in the main func­tion. So, in­t_ptr is still point­ing to the mem­ory, which is freed as men­tioned in Point 2. 4. One can ob­serve al­lo­ca­tion and deal­lo­ca­tion of the stack frame (let us called this fun frame) for the fun() in Fig­ure 2 for bet­ter un­der­stand­ing. 5. Now, in­t_ptr be­comes a dan­gling pointer. Deref­er­enc­ing

this pointer re­sults in un­ex­pected out­put. 6. So, al­ways take ex­tra care while play­ing with point­ers and lo­cal vari­ables. Any at­tempt to deref­er­ence the pointer that is al­ready dan­gling may still print the cor­rect value af­ter the con­trol re­turn­ing from a func­tion call, but any func­tions called there­after will over­write the stack stor­age al­lo­cated for the au­to_­var vari­able with other val­ues, and the pointer will no longer work cor­rectly.

How to pre­vent a pointer from be­com­ing a dan­gling pointer in this case: If a pointer to au­to_­var is to be re­turned, au­to_­var must have scope be­yond the func­tion so that it may be de­clared as static in or­der to avoid the pointer from dan­gling. This is be­cause the mem­ory al­lo­cated to the static vari­ables is from the data seg­ment, where the life­time will be through­out the pro­gram.

Case 2: When the vari­able goes out of scope

Con­sider the sam­ple code (Code 2) given be­low for anal­y­sis:

Run­ning the pro­gram shown in Code 2 in the GCC com­piler with the -Wall op­tion re­sults in the warn­ing shown in Fig­ure 3.

Since the vari­able var is in­vis­i­ble for the outer block shown in Code 2, iptr is still point­ing to the same ob­ject even when the con­trol comes out of the in­ner block. Hence, the pointer iptr be­comes a dan­gling pointer af­ter Line 10 in the ex­am­ple shown in Code 2.

Case 3: When, in dy­namic mem­ory al­lo­ca­tion, the block of mem­ory that is al­ready freed is used

Con­sider the sam­ple code given be­low:

Fig­ure 2: Pro­gram mem­ory and stack frames

Fig­ure 1: Com­piler gen­er­at­ing warn­ing

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.