:: Re: [DNG] Making sense of C pointer…
Top Page
Delete this message
Reply to this message
Author: KatolaZ
Date:  
To: Edward Bartolo
CC: dng
Subject: Re: [DNG] Making sense of C pointer syntax.
On Wed, Mar 30, 2016 at 10:40:37PM +0200, Edward Bartolo wrote:
> Hi, thanks for your help.
>
> So: [ I am recalling this from memory to test where I am ]
> a) type* pp; // declare a pointer pp
> b) *pp = RHS; // assign RHS to the data pointed to by pp


This is a bit fishy, and should be taken with care. In a word, you
should be very careful about what is in the RHS, and you should be
sure that whatever is on the RHS "fits" in the memory area starting at
the location stored into pp.

> c) type **ss; // declare a pointer to pointer. System only allocates
> space for one address


C pointers are *always* one variable, precisely a variable large
enough to store a memory address on the current architecture.

> d) *ss = RHS; // assign RHS to the pointer pointed to by ss.


This is no different from b) above, is it?

> e) const char* and char* are not the same ie treated differently by the compiler


"const" is a qualifier that modifies what you can do with a
pointer. If a pointer is declared "const" (usually in the signature of
a function), then any assignment that directly tries to change the
value of that pointer should be forbidden at compile time. I say
"should" because some compilers simply ignore the "const" qualifier.

> f) strings are character arrays, so they obey the rules governing arrays


Definitely. A string is just an array of char, and the variable you
use to handle strings is a char*. The usual pointer arithmetics holds
for any kind of pointer, including char*.

> g) strings are terminated by a null character which is a byte with eight zeros


This only makes sense if you want to use the standard functions to
handle strings. Nothing forbids you for creating and handling by your
own an array or chars (identified by a char*) which is not
null-terminated.

> h) extra care must be taken when copying strings not to write beyond
> the end of allocated memory. This can result in buffer overflows that
> may cause execution of arbitrary code


Extra care should be taken when copying between *any* two memory
areas, and strings are not an exception.

> i) some built in string function provided by C, especially vintage
> string functions, suffer from the buffer overrun bug. Guard against
> that by making sure there is enough memory allocated.
> j) When calling backend CLI programs make sure, the input to the
> calling function cannot be maliciously modified to allow execution of
> arbitrary commands. Functions like execl can be abused so extra care
> to block abuse must be taken.


This is generally true, but has nothing much to do with the previous
points.

My2Cents

KatolaZ

--
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]