J
Jasper Dozer
Is this a healthy way to get a pointer to point ?
char *p = "longenough";
regards,
jasper
char *p = "longenough";
regards,
jasper
J
Joona I Palaste
Jasper Dozer said:
Depends what you mean by "healthy". If you do this, you can access the
string "longenough" for reading every time p is in scope, but you can't
portably access it for writing.
--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"When a man talks dirty to a woman, that's sexual harassment. When a woman talks
dirty to a man, that's 14.99 per minute + local telephone charges!"
- Ruben Stiller
T
Thomas Matthews
Jasper said:
No. Use 'const':
const char * p = "longenough";
The literal should be treated as constant data. The
pointer should be of type "pointer to const data". One
could argue that fact that the value of the pointer
should be constant too; but I'll leave that as a style
issue.
If you want to modify the string literal, then try:
char p[] = "Modify Me.";
The array notation will tell the compiler to create
an array, length determined by the size of the literal
constant, and copy the data into the array.
--
Thomas Matthews
C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book
D
Default User
Jasper said:
Depends on what you want to do. Do you know what string literals are,
and how they may be used and may not be used? The name of the literal
you've chosen bothers me, it seems like you think this is a quick way to
dynamically allocate space for some other use. DO NOT DO THAT!
Brian Rodenborn
A
Amarendra GODBOLE
Is this a healthy way to get a pointer to point ?
In most of the cases, memory for the string (where p points) is
allocated in a ro memory area, which will result in an error if you
try to change the contents of that area where p points to.
Cheers,
AG
In most of the cases, memory for the string (where p points) is
allocated in a ro memory area, which will result in an error if you
try to change the contents of that area where p points to.
Cheers,
AG
J
Jasper Dozer
Thanks for your replies. No I do not know what a sting literal is and
how the are to be used. Neither do i have an idea what a ro memory
area is. I am sorry that my initial question was so unclear. Let me be
more specific. The reason that I asked this is because I found the
following piece of code in software is used daily in our lab:
static char *statename= "NOTINITIALIZEDYETBUTLONGENOUGH";
later on the program statename is used in an video interrupt loop like
this
....
statename="WAITBLOCKREADY";
....
statename="SHOWSTIMULUS"
....
etc.
which is used outside the videointerrupt to
Str255 str; /* typedef unsigned char Str255[256]; */
sprintf( (char *)str, "%s", staten );
the &str is used to plot the statename to a dialog window with a
function that takes a pointer to a Str55 as an argument.
So Brian Rodenborn was right when he thought this was used as a trick
to easily allocate memory for other use. So what should I do instead?
Will this be ok?
char *statename;
in an initialisation function that can be called more than once:
void initfunc()
{
if (statename!=NULL) {
free(statename);
}
statename = malloc(100);
if (statename==NULL) {
// give an error and quit the program
}
}
in the videointerrupt:
if (statename!=NULL) {
strcpy( statename, "WAITBLOCKREADY");
}
and use &statename to plot the statename in the dialog. (outside the
videointerrupt)
and finally
free(statename);
J
Joona I Palaste
A string literal is a piece of C code somewhat like this:
""
"Hello, world!\n"
"longenough"
"You have performed an illegal operation. We have informed Microsoft\
General HQ of the recent activities. Resistance is futile."
String literals are objects of type char[], with the length of the
array being the length of the string plus one char for the terminating
'\0'.
Video interrupts are off-topic for comp.lang.c. But luckily your
question does not depend on knowledge about video interrupts, but can
be solved entirely within the domain of standard C.
Don't do that. (Or if you didn't do that, tell the one who did not to
do that.) Such typedefs are confusing. Why don't you simply type:
unsigned char str[256];
or:
#define STRSIZE 256
unsigned char str[STRSIZE];
?
You don't have to cast str. It will automatically "decay" into a char *
when used as a parameter.
Surely you mean statename and not staten?
What &str? I don't see any &str in the above code. And also, don't
you mean Str255 and not Str55?
Lastly, plotting and dialog windows are off-topic on comp.lang.c.
You don't need the guard. free(NULL) is a safe no-op.
The only difference between this and a direct assignment:
statename = "WAITBLOCKREADY";
is that with a direct assignment, you are not *guaranteed* to be able
to write to the string. With the malloc and the strcpy, you are
guaranteed.
This depends entirely on what your "plotting function" needs to be able
to do to the string. If it only needs to read it, you're safe with a
direct assignment. Otherwise you need malloc, strcpy and free.
--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Nothing lasts forever - so why not destroy it now?"
- Quake
G
goose
note that those statements dont actually overwrite the
original string literal ("NOTINITIALIZEDYETBUTLONGENOUGH').
as far as I can see from the tiny snippets above, a string literal is
not /actually/ being overwritten. iow, there is no problem (other than
lack of understanding about how the string literal is to be used).
why not
char *statename;
in the videointerrupt:
....
statename = "WAITBLOCKREADY";
much cleaner than making a copy of a string literal that never
gets written anyway. the dialog routine can just use statename then,
with no need to copy, malloc and/or free anything.
hth
goose,
S
Sheldon Simms
It appears to me that the author of this code thought that an assignment
like
statename="WAITBLOCKREADY";
copies the characters in the string literal "WAITBLOCKREADY" into the
same memory area used by "NOTINITIALIZEDYETBUTLONGENOUGH" in the original
definition of statename. However, that is not the case.
statename starts out as a pointer that references the first character in
"NOTINITIALIZEDYETBUTLONGENOUGH". Later that pointer is changed to point
at the first character in some other string literal. There is no need,
to point statename at a "long enough" string literal. It can be defined
as a null pointer so:
char *statename = 0;
With this definition, though, you should make sure that statename is
no longer a null pointer before you get to the sprintf().
-Sheldon
M
Michael Haines - Sun
Hi All,
I would like some help on the following please:
The following code I have llist peforms the following function:
# llist hosts
dn: cn=foo+ipHostNumber=192.168.100.22,ou=Hosts,dc=Sun,dc=COM
dn: cn=bar-lh.bar.com+ipHostNumber=192.168.100.23,ou=Hosts,dc=Sun,dc=COM
What I want this code to output is the following:
192.168.100.22 foo
192.168.100.23 bar
So, if I want to change the C program to print what I want, I need to split the entry->attr_pair[j]->attrvalue[0] that is printed in my first fprintf(). I believe what is involved is chopping the string into pieces at the '=' and ',' characters and displaying the right pieces?
Any advice or help on how to do this would be much appreciated.
I would like some help on the following please:
The following code I have llist peforms the following function:
# llist hosts
dn: cn=foo+ipHostNumber=192.168.100.22,ou=Hosts,dc=Sun,dc=COM
dn: cn=bar-lh.bar.com+ipHostNumber=192.168.100.23,ou=Hosts,dc=Sun,dc=COM
What I want this code to output is the following:
192.168.100.22 foo
192.168.100.23 bar
So, if I want to change the C program to print what I want, I need to split the entry->attr_pair[j]->attrvalue[0] that is printed in my first fprintf(). I believe what is involved is chopping the string into pieces at the '=' and ',' characters and displaying the right pieces?
Any advice or help on how to do this would be much appreciated.
D
Default User
Jasper Dozer wrote:
Then you really need to get a book and get familiar with them. Postings
to a newsgroup are no substitute for actual learning.
Without a firm grounding in the basics of C, it's pointless to try and
read other people's code. You won't know the difference between errors
and obscure but legal constructs.
The statement is fine in and of itself. Again, the name makes me
suspicious the writer though he was allocating a memory buffer.
It's a common misconception in C that the = operator will assign values
to entire arrays. It doesn't. In the above cases, pointers to string
literals are substituted. In the case shown, that "works" just as well
as actually allocating memory and copying data, perhaps better. The
initialized value of statename was not particularly useful unless it was
tested at some point.
This is relatively ok, the cast is unnecessary. I assume that staten
should be statename.
There's actually nothing really wrong. As long as you understand what's
going on, this code can be used. I'd change the intialization of
statename to either NULL or "UNINITIALIZED" or something like that.
The test is unnecessary. free (NULL) is a no-op.
I can't see where statename will ever get set to NULL. Barring that,
this works, but so did the original. The original has the benefit of not
allocating and deallocating memory at runtime. You are going to have to
get familiar with strings and string literals.
Brian Rodenborn
Then you really need to get a book and get familiar with them. Postings
to a newsgroup are no substitute for actual learning.
Without a firm grounding in the basics of C, it's pointless to try and
read other people's code. You won't know the difference between errors
and obscure but legal constructs.
The statement is fine in and of itself. Again, the name makes me
suspicious the writer though he was allocating a memory buffer.
It's a common misconception in C that the = operator will assign values
to entire arrays. It doesn't. In the above cases, pointers to string
literals are substituted. In the case shown, that "works" just as well
as actually allocating memory and copying data, perhaps better. The
initialized value of statename was not particularly useful unless it was
tested at some point.
This is relatively ok, the cast is unnecessary. I assume that staten
should be statename.
There's actually nothing really wrong. As long as you understand what's
going on, this code can be used. I'd change the intialization of
statename to either NULL or "UNINITIALIZED" or something like that.
The test is unnecessary. free (NULL) is a no-op.
I can't see where statename will ever get set to NULL. Barring that,
this works, but so did the original. The original has the benefit of not
allocating and deallocating memory at runtime. You are going to have to
get familiar with strings and string literals.
Brian Rodenborn
M
Mark McIntyre
so you've declared a char pointer which happens to point to a string
literal. Which you never use, and which is a waste of time.
Whoever did this did /not/ understand how strings work in C, they
thought they were programming in basic.
remember that these expressions are assignments, not copy operations.
statename (ie the pointer) is assigned a new value, teh address of
your new string., Nothing is copied into hte original location, which
is just as well ,as you can't legally copy into string literals.
J
Jasper Dozer
Joona I Palaste said:
Str255 is a typedef that engineers at apple think is usefull. I don't
know these guys so I will not be able to them their idea sucks. In the
future I will not comment on system specific typedefs but replace them
by ANSI C before posting to comp.lang.c
---REASON FOR POSTING THIS REPLY:
when I remove the cast my compiler issues the following error:
illegal implicit conversion from 'unsigned char[256] to 'char *'
Is this specific for my compiler or would something similar happen in
pure ANSI C? In other words, are you sure it will automatically
"decay" into a char* when used as a parameter?
Mea culpa
sorry, I thought I used a fancy way to make clear that the adress of
str was used as an argument for some plotting routine.
I missed the 2 key
Of course. I was just giving some context to my question
J
Joona I Palaste
Jasper Dozer said:
It is not a system specific typedef, its behaviour is fully defined
within ANSI C. So it's not *wrong* to post it to comp.lang.c. Only I
personally find it ugly.
Actually my answer was only partially correct. It will, in fact,
decay into a "unsigned char *". Some compilers permit automatic
conversion from unsigned char * to char *, but some don't.
*Any* array of type T will decay into a pointer to type T, where T
is any type. This applies both to ANSI C and pre-ANSI C. However the
point I initially missed was that char and unsigned char are not
*necessarily* the same type.
(snip)
--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Roses are red, violets are blue, I'm a schitzophrenic and so am I."
- Bob Wiley
J
Joona I Palaste
j said:
We're lucky "Str255" fails to meet this regular expression then, as
"Str" does match [sS][tT][rR] but "2" isn't any letter from A to Z,
or any letter from a to z, that I've ever heard of.
(snip)
--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Show me a good mouser and I'll show you a cat with bad breath."
- Garfield
J
j
Joona I Palaste said:
I believe under c90 that (str[A-Z][0-9]{3}) is reserved for the
implementation.
Also, if I remember correctly, the first three characters for ``str'' is
case insensitive
So for c89/90 ([sS][tT][rR][A-Z][0-9]{3}) is reserved for the
implementation.
J
j
Joona I Palaste said:
Oops!
echo -e "Str255\nStr2555\n" | sed -n '/[sS][tT][rR][A-Za-z0-9]\{3\}$/p'
J
John Bode
IIRC, Str255 was meant to be used as a Pascal-style string (leading
length byte) instead of a C-style string (zero-terminated array). I
haven't done a ton of Mac programming, but from what I remember the
API calls expected Pascal-style strings, and there were several
routines to convert from C to Pascal strings, and Str255 was used for
the Pascal strings.
C strings should simply be typed as char[].
M
Micah Cowan
Even more, most C implementations for that API that I've seen has
an extension which replaces the escape sequence "\p" within
string literals with the pascal-style leading length byte.
Absolutely agreed
-Micah
D
Dave Thompson
[ typedef Str255 for unsigned char [256] ]
Any valid identifier beginning str[a-z], thus str[a-z][a-zA-Z0-9_]*,
is reserved as a function name and macro name, hence effectively for
all purposes, *if* you #include <string.h> (perhaps indirectly).
In C89 the same identifiers possibly with case ignored (in all
letters) and possibly truncated to as little as six characters, in
both cases at the (documented) choice of the implementation, are
reserved as external (i.e. linker) names, period, whether you #include
or declare or not. In C99 the case folding is gone and truncation can
not be below 31 characters, so practically speaking only the exact
identifiers are reserved. But a typedef, even a "global" (file-scope)
one, is purely compile time and never conflicts with an external name.
They are never the same type, and the conversion must not be allowed
without a cast, on any conforming compiler. According to 6.2.5p15 and
footnote 35 plain char has the same "range, representation, and
behavior" as either signed or unsigned char at the implementation's
choice, but is still a formally distinct and incompatible type.
(Except, presumably, if bitfields are allowed to be char under
6.7.2.1p4 the i-d choice of signed or unsigned for bitfields applies?)
C90 6.1.2.5 did not have this footnote, but does consistently list
plain char separately from signed and/or unsigned char where
applicable, in particular as basic types, and says "Even if the
implementation defines two or more basic types to have the same
representation, they are nonetheless different types."
- David.Thompson1 at worldnet.att.net