Help on pointer to structures!

M

monkey man

hi . im doin ma 2nd year in comp science Engg and im just starting to
learn c programming .
i have a doubt to be cleared . look at the following code snippet:

struct dhilip
{
int d;
struct dhilip *next;

}*START, *END, *dhil;

during the compilation of the program, will "START", "END" and "dhil"
be initialized, by default, to '0' or '\0' .
plz plz plz , some one help me . sorry for the english.
 
M

Martin Ambuhl

monkey said:
hi . im doin ma 2nd year in comp science Engg and im just starting to
learn c programming .
i have a doubt to be cleared . look at the following code snippet:

struct dhilip
{
int d;
struct dhilip *next;

}*START, *END, *dhil;

during the compilation of the program, will "START", "END" and "dhil"
be initialized, by default, to '0' or '\0' .

Maybe. If the declaration is for static variables, the are initialized
to null pointers. It is very unlikely that a null pointer has the same
representation or value as '0', but it may well have the same value as
'\0'. If the declaration is for auto variables, their contents are
completely unknown (and perhaps unknowable).
plz plz plz , some one help me . sorry for the english.

No one expects perfect English, but you should know that many real
programmers (in contrast to kiddie hackers) consider "plz" to be baby-talk.
 
F

Falcon Kirtaran

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin said:
Maybe. If the declaration is for static variables, the are initialized
to null pointers. It is very unlikely that a null pointer has the same
representation or value as '0', but it may well have the same value as
'\0'. If the declaration is for auto variables, their contents are
completely unknown (and perhaps unknowable).

That is not unlikely at all! Also, the null character in ASCII happens
to have the value 0, and is more or less equivalent to 0. Thus, using
the very common glibc and gcc, the code:

#include <stdio.h>

int main() {
printf("NULL=%d 0=%d '\\0'=%hhd\n", (int)NULL, 0, '\0');
return 0;
}

will print "NULL=0 0=0 '\0'=0".

- --
- --Falcon Darkstar Christopher Momot
- --
- --OpenPGP: (7902:4457) 9282:A431

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoJNVMACgkQeQJEV5KCpDHPhgCfX6CIAMunMvcjI6IHi4QUieR8
3tMAmgO1GgNNPxUqeVeDPtbG4dIXZdMC
=ajcg
-----END PGP SIGNATURE-----
 
J

James Kuyper

Falcon said:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



That is not unlikely at all! Also, the null character in ASCII happens
to have the value 0, and is more or less equivalent to 0.

He didn't say 0, he said '0', which is something quite different.
 
B

Ben Bacarisse

Richard said:
Did you see static there?

Do you not know what he means? It is a shorthand for an "object with
static storage duration". In other contexts you like non-standard
shorthand. For example, you've argued in favour of "global variable"
even though it has no exact meaning in C.
What total nonsense guaranteed to confuse the newcomer. It is almost
100% certain that these pointers do indeed have the VALUE 0 stored in
them if they are initialised to null pointers.

That is very similar to what he said except you have gone for "almost
100% certain" over Martin's "may well have". Personally, I would have
pointed out, much more clearly, that '0' and 0 are probably different
whereas '\0' and 0 are not but that does not seem to be what you are
complaining about.
Don't believe me? Look in
the debugger

In simple cases the debugger will give a simple answer, but the hard
cases to understand are where pointers are not simply numbers (like on
an old PC). In these cases the debugger has to invent a notation for
an address and that might be more confusing than being clear about
what a null pointer is in the first place.
.... Not static or specifically initiliased then yes random
values are possible.

Stop trying to confuse new comers with your ridiculous
oneupsmanship.

I think the fact that the OP had written '0' could have been pointed
out more clearly, but to attribute a complex intent like oneupmanship
to the answer is unfounded. A programmer I know well (and can
therefore comment on their intent in such matters) is so painfully
literal that they would not be able to answer a question in any way
but exactly as it was asked. There is, however, absolutely no
maliciousness in it at all -- they have an almost child-like
inability to see what might have been intended. I have no idea about
Martin's motivation or intentions -- my point is that it is almost
always unwise to try see intentions behind posts.

(And, yes, I know Just Plain Richard often posts inflammatory remarks,
but I will try hard not to get inflamed.)
 
K

Keith Thompson

Falcon Kirtaran said:
Martin Ambuhl wrote: [...]
Maybe. If the declaration is for static variables, the are initialized
to null pointers. It is very unlikely that a null pointer has the same
representation or value as '0', but it may well have the same value as
'\0'. If the declaration is for auto variables, their contents are
completely unknown (and perhaps unknowable).

That is not unlikely at all! Also, the null character in ASCII happens
to have the value 0, and is more or less equivalent to 0. Thus, using
the very common glibc and gcc, the code:

'0' is the digit; in ASCII, for example, it has the value 48, which is
quite unlikely to match the representation of a null pointer.

And the null character has the value 0 in any character set, by
definition.
#include <stdio.h>

int main() {
printf("NULL=%d 0=%d '\\0'=%hhd\n", (int)NULL, 0, '\0');
return 0;
}

will print "NULL=0 0=0 '\0'=0".

Maybe.

Whether (int)NULL is valid or not depends on how the NULL macro is
defined. If it's defined as 0, it's fine. If it's defined as
((void*)0), then the conversion yields an implementation-defined
result, not necessarily 0 -- and whether (int)((void*)0) yields 0 is,
in principle, independent of whether a null pointer is represented as
all-bits-zero.

There's no need to use "%hhd" to print '\0'. Character constants are
of type int, not char.
 
J

jfbode1029

hi . im doin ma 2nd year in comp science Engg and im just starting to
learn c programming .
i have a doubt to be cleared . look at the following code snippet:

struct dhilip
{
        int d;
        struct dhilip *next;

}*START, *END, *dhil;

during the compilation of the program, will "START", "END" and "dhil"
be initialized, by default, to '0' or '\0' .

That depends on where and how you declare them. If you declare them
at file scope (outside of any function), or if you declare them as
static, they will be implicitly initialized to NULL. If they are
declared auto (within a block), then they are not implicitly
initialized and their value is unknown.

Examples:

struct dhilip {
int d;
struct dhilip *next;
};

struct dhilip *p1; // file scope, initialized to NULL

void foo()
{
static struct dhilip *p2; // static, initialized to NULL
struct dhilip *p3; // auto, not initialized
...
}

One important thing to remember is that the value we use to represent
a null pointer in the source code (the null pointer constant) is not
necessarily the same as the value used by the underlying hardware to
represent a null pointer (the null pointer value). In the source
code, a 0 (or an expression that evaluates to 0) in a pointer context
is always treated as a null pointer. The macro NULL is always defined
to evaluate to 0. However, the hardware may use an address other than
0x00000000 to signify a null pointer (0xDEADBEEF maybe).

Tiny nitpick: '0' and '\0' are typically read to mean character
constants, which in ASCII would evaluate to 48 and 0, respectively.
 
F

Falcon Kirtaran

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James said:
He didn't say 0, he said '0', which is something quite different.

Aah. Whoops. It still stands, though, that 0 and NULL are commonly
equivalent.

- --
- --Falcon Darkstar Christopher Momot
- --
- --OpenPGP: (7902:4457) 9282:A431

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoJ0TMACgkQeQJEV5KCpDGkZwCeIOiS2Hw2R8lippDLsShXcN9O
UXsAn1Q09mkcNJYzmGGH1VaUF0IqDYba
=RKqM
-----END PGP SIGNATURE-----
 
F

Falcon Kirtaran

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

monkey said:
hi . im doin ma 2nd year in comp science Engg and im just starting to
learn c programming .
i have a doubt to be cleared . look at the following code snippet:

struct dhilip
{
int d;
struct dhilip *next;

}*START, *END, *dhil;

during the compilation of the program, will "START", "END" and "dhil"
be initialized, by default, to '0' or '\0' .
plz plz plz , some one help me . sorry for the english.

Sorry for all the confusion :)

In the simplest way possible, with no regard for pedantic accuracy, the
following holds. If START, END, and dhil are declared outside a
function, or statically, they will be initialized to 0, that is NULL or
\0. If they are inside a function, they will not be initialized at all.

No pointer should ever be initialized to the ASCII value for the
character 0 on any reasonable implementation I can imagine. If your
instructor is saying pointers should be initialized to 0, they mean
NULL, not '0'.

- --
- --Falcon Darkstar Christopher Momot
- --
- --OpenPGP: (7902:4457) 9282:A431

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoJ00cACgkQeQJEV5KCpDGiPQCfT9R8efIfKptWX3RpJo8wiPAc
uaYAn17Y1Bye+5lJBT8+iMF1OGn/Zxpn
=hh36
-----END PGP SIGNATURE-----
 
J

jameskuyper

Falcon said:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Aah. Whoops. It still stands, though, that 0 and NULL are commonly
equivalent.

No, they are not necessarily equivalent. Try using NULL rather than 0
as a bit-field size. 0 is permitted as a bit-field size. However, if
NULL is defined as ((void*)0) (which is permitted), a bit-field size
of NULL would be a constraint violation.

The standard does mandate that NULL == 0 must evaluate as true; also
NULL== '\0'. It doesn't say so directly, you have to apply several
different parts of the standard to reach that conclusion. NULL is
required to expand into an null pointer constant (NPC), which allows
two possibilities:

a) NULL expands to an integer constant expression with a value of 0.
In this case, the usual arithmetic conversions apply, leaving both
operands of NULL==0 as expressions of the same integral type, and
still with a value of zero, so they must compare equal.

b) NULL expands to an integer constant expression with a value of 0,
converted to void*. That integer constant expression by itself also
qualifies as an NPC, which means that the conversion to void* produces
a null pointer. In general, you can't compare pointers for equality
with integers. However, the 0 (or '\0') which is the right operand of
the comparison is a also an NPC. When an NPC is compared for equality
with a pointer value, it automatically gets converted into a null
pointer value of the same type as the other operand. All null pointers
are required to compare equal, so we still have NULL==0 (or NULL ==
'\0') evaluating to true, though the logic is more convoluted in this
case.
 
D

Default User

Richard said:
Falcon Kirtaran said:



Except, as you mentioned above, if they are static.

The are not required to be initialized. The implementation can, and
sometimes does, initialize them anyway. It's somewhat common for
implementations to initialize automatic data in "debug" mode.





Brian
 
D

Default User

Richard said:
Default User said:


True enough. I should have said so.


Nevertheless, it is not wise to rely on such optional
initialisations.

That is the case. Occasionally, we get posts along the lines of, "This
works in debug but not in release!!!! What's happening?"



Brian
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,431
Messages
2,571,677
Members
48,796
Latest member
Greg L.

Latest Threads

Top