From: "John T. Williams" <jowillia@vt.edu>
To: linux-c-programming@vger.kernel.org
Subject: Re: literal constant..
Date: Tue, 3 Feb 2004 10:04:26 -0500 [thread overview]
Message-ID: <003d01c3ea67$04607ff0$ed64a8c0@descartes> (raw)
In-Reply-To: 401FB158.40408@onlinehome.de
it is actually easier to see the difference if you divorce the assignment
operation from the variable declarations.
char* a;
creates a pointer that points to nothing in particular ( its value is
unknown)
char b[2];
creates a constant pointer that points to a specific place in memory that
has 2 bytes set aside for its use.
I can then make the call
a = (char*) malloc( 300 ); // and a would now point to an array of 300
character in length (on the heap if you care)
however the call
b = (char*) malloc( 300); // is illegal, and should not compile.
----- Original Message -----
From: "Florian Attenberger" <fattenberger@onlinehome.de>
To: "Sandro Dangui" <sdangui@nortelnetworks.com>;
<linux-c-programming@vger.kernel.org>
Sent: Tuesday, February 03, 2004 9:34 AM
Subject: Re: literal constant..
> char c[1]="c" is an unlucky example, it seems to be like this:
> char c* = "c"; // make c point to "c\0".
> char c[1] = "c"; // make c point to an undifined array of char of length
> 1, set last char to '\0', _after_ that overwrite the array with "c",
> since "c" is just as long as the whole array, the \0 gets overwritten.
>
> To get the second example behave equal to the first, it needs to be:
> char c[2] = "c"; // char[0] == 'c', char[1] == '\0'.
>
> So much to code difference.
>
> char c[] is however a constant pointer, so you cannot reassign it.
> That doesn't have to result in any assembler code difference at all, its
> just the compiler that complains.
>
> flo
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2004-02-03 15:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-03 11:41 literal constant Sandro Dangui
2004-02-03 14:34 ` Florian Attenberger
2004-02-03 15:04 ` John T. Williams [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-02-03 6:46 Vadiraj C S
[not found] ` <006601c3ea24$c694d230$ed64a8c0@descartes>
2004-02-03 7:34 ` Vadiraj C S
2004-02-03 15:07 ` Glynn Clements
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='003d01c3ea67$04607ff0$ed64a8c0@descartes' \
--to=jowillia@vt.edu \
--cc=jtwilliams@vt.edu \
--cc=linux-c-programming@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.