char *p = "longenough";

[Jasper Dozer]

Is this a healthy way to get a pointer to point ?
char *p = "longenough";
regards,
jasper

[Joona I Palaste]

Jasper Dozer <ja*********@hotmail.com> scribbled the following:

Is this a healthy way to get a pointer to point ?
char *p = "longenough";
regards,
jasper

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 (pa*****@cc.helsinki.fi) ---------------------------\
| 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

[Thomas Matthews]

Jasper Dozer wrote:

Is this a healthy way to get a pointer to point ?
char *p = "longenough";
regards,
jasper

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

[Default User]

Jasper Dozer wrote:

Is this a healthy way to get a pointer to point ?
char *p = "longenough";

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

[Amarendra GODBOLE]

> > Is this a healthy way to get a pointer to point ?

char *p = "longenough";

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!

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

[Jasper Dozer]

ro**@zworg.com (Amarendra GODBOLE) wrote in message news:<89**************************@posting.google. com>...

Is this a healthy way to get a pointer to point ?
char *p = "longenough";

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!

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

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);

---

regards,
Jasper

[Joona I Palaste]

Jasper Dozer <ja*********@hotmail.com> scribbled the following:

ro**@zworg.com (Amarendra GODBOLE) wrote in message news:<89**************************@posting.google. com>...

> > Is this a healthy way to get a pointer to point ?
> > char *p = "longenough";
>
> 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!
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.

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:
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'.
static char *statename= "NOTINITIALIZEDYETBUTLONGENOUGH"; later on the program statename is used in an video interrupt loop like
this ...
statename="WAITBLOCKREADY";
...
statename="SHOWSTIMULUS"
...
etc.
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.
which is used outside the videointerrupt to Str255 str; /* typedef unsigned char Str255[256]; */
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];
?
sprintf( (char *)str, "%s", staten );
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?
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.
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.
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);
}
You don't need the guard. free(NULL) is a safe no-op.
statename = malloc(100);
if (statename==NULL) {
// give an error and quit the program
}
} in the videointerrupt:
if (statename!=NULL) {
strcpy( statename, "WAITBLOCKREADY");
}
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.
and use &statename to plot the statename in the dialog. (outside the
videointerrupt) and finally free(statename);

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 (pa*****@cc.helsinki.fi) ---------------------------\
| 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

[goose]

ja*********@hotmail.com (Jasper Dozer) wrote in message news:<57**************************@posting.google. com>...

ro**@zworg.com (Amarendra GODBOLE) wrote in message news:<89**************************@posting.google. com>...

> Is this a healthy way to get a pointer to point ?
> char *p = "longenough";
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!
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

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.

note that those statements dont actually overwrite the
original string literal ("NOTINITIALIZEDYETBUTLONGENOUGH').


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?
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).
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");
}

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.
and use &statename to plot the statename in the dialog. (outside the
videointerrupt)

hth
goose,

[Sheldon Simms]

On Wed, 01 Oct 2003 03:45:26 -0700, Jasper Dozer wrote:

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?

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

[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.
---
Best Regards

-Michael

[Default User]

Jasper Dozer wrote:

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.
Then you really need to get a book and get familiar with them. Postings
to a newsgroup are no substitute for actual learning.
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:
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.
static char *statename= "NOTINITIALIZEDYETBUTLONGENOUGH";
The statement is fine in and of itself. Again, the name makes me
suspicious the writer though he was allocating a memory buffer.
later on the program statename is used in an video interrupt loop like
this

...
statename="WAITBLOCKREADY";
...
statename="SHOWSTIMULUS"
...
etc.
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.
which is used outside the videointerrupt to

Str255 str; /* typedef unsigned char Str255[256]; */
sprintf( (char *)str, "%s", staten );
This is relatively ok, the cast is unnecessary. I assume that staten
should be statename.
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?
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.
Will this be ok?

char *statename;

in an initialisation function that can be called more than once:

void initfunc()
{
if (statename!=NULL) {
free(statename);
The test is unnecessary. free (NULL) is a no-op.
}
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);

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

[Mark McIntyre]

On 1 Oct 2003 03:45:26 -0700, in comp.lang.c , ja*********@hotmail.com
(Jasper Dozer) wrote:

static char *statename= "NOTINITIALIZEDYETBUTLONGENOUGH";
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.
later on the program statename is used in an video interrupt loop like
this
statename="WAITBLOCKREADY";

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.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>

[Jasper Dozer]

Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message news:<bl**********@oravannahka.helsinki.fi>...

Jasper Dozer <ja*********@hotmail.com> scribbled the following:

ro**@zworg.com (Amarendra GODBOLE) wrote in message news:<89**************************@posting.google. com>...

> > Is this a healthy way to get a pointer to point ?
> > char *p = "longenough";
>
> 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!

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.

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:
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'.

static char *statename= "NOTINITIALIZEDYETBUTLONGENOUGH";

later on the program statename is used in an video interrupt loop like
this

...
statename="WAITBLOCKREADY";
...
statename="SHOWSTIMULUS"
...
etc.

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.

which is used outside the videointerrupt to

Str255 str; /* typedef unsigned char Str255[256]; */

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];
?

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

sprintf( (char *)str, "%s", staten );

You don't have to cast str. It will automatically "decay" into a char *
when used as a parameter.

---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?
Surely you mean statename and not staten?

Mea culpa

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.

What &str? I don't see any &str in the above code. And also, don't

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.
you mean Str255 and not Str55?
I missed the 2 key

Lastly, plotting and dialog windows are off-topic on comp.lang.c.

Of course. I was just giving some context to my question

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);
}

You don't need the guard. free(NULL) is a safe no-op.

statename = malloc(100);
if (statename==NULL) {
// give an error and quit the program
}
}

in the videointerrupt:
if (statename!=NULL) {
strcpy( statename, "WAITBLOCKREADY");
}

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.

and use &statename to plot the statename in the dialog. (outside the
videointerrupt)

and finally

free(statename);

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 I Palaste]

Jasper Dozer <ja*********@hotmail.com> scribbled the following:

Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message news:<bl**********@oravannahka.helsinki.fi>...

Jasper Dozer <ja*********@hotmail.com> scribbled the following:

> ro**@zworg.com (Amarendra GODBOLE) wrote in message news:<89**************************@posting.google. com>...
>> > > Is this a healthy way to get a pointer to point ?
>> > > char *p = "longenough";
>> >
>> > 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!
>>
>> 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.
(snip)
> Str255 str; /* typedef unsigned char Str255[256]; */
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];
? 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
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.

> sprintf( (char *)str, "%s", staten );

You don't have to cast str. It will automatically "decay" into a char *
when used as a parameter.

---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?

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 (pa*****@cc.helsinki.fi) ---------------------------\
| 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" <pa*****@cc.helsinki.fi> wrote in message
news:bl**********@oravannahka.helsinki.fi...

Jasper Dozer <ja*********@hotmail.com> scribbled the following:

Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message news:<bl**********@oravannahka.helsinki.fi>...

Jasper Dozer <ja*********@hotmail.com> scribbled the following:
> ro**@zworg.com (Amarendra GODBOLE) wrote in message news:<89**************************@posting.google. com>... >> > > Is this a healthy way to get a pointer to point ?
>> > > char *p = "longenough";
>> >
>> > 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!
>>
>> 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.
(snip)
Str255 str; /* typedef unsigned char Str255[256]; */

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];
?

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

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.

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.

> sprintf( (char *)str, "%s", staten );

You don't have to cast str. It will automatically "decay" into a char *
when used as a parameter.

---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?

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 (pa*****@cc.helsinki.fi) ---------------------------\
| 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

[Joona I Palaste]

j <ja*******@bellsouth.net> scribbled the following:

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bl**********@oravannahka.helsinki.fi...

Jasper Dozer <ja*********@hotmail.com> scribbled the following:

> Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message news:<bl**********@oravannahka.helsinki.fi>... >> Jasper Dozer <ja*********@hotmail.com> scribbled the following:
>> > Str255 str; /* typedef unsigned char Str255[256]; */
>>
>> 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];
>> ?

> 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

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.

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.

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 (pa*****@cc.helsinki.fi) ---------------------------\
| 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]

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bl**********@oravannahka.helsinki.fi...

j <ja*******@bellsouth.net> scribbled the following:

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bl**********@oravannahka.helsinki.fi...

Jasper Dozer <ja*********@hotmail.com> scribbled the following:
> Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message news:<bl**********@oravannahka.helsinki.fi>...

>> Jasper Dozer <ja*********@hotmail.com> scribbled the following:
>> > Str255 str; /* typedef unsigned char Str255[256]; */
>>
>> 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];
>> ?

> 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

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.

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.

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.

Oops!

echo -e "Str255\nStr2555\n" | sed -n '/[sS][tT][rR][A-Za-z0-9]\{3\}$/p'
(snip)

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| 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

[John Bode]

ja*********@hotmail.com (Jasper Dozer) wrote in message news:<57**************************@posting.google. com>...

Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message news:<bl**********@oravannahka.helsinki.fi>...

Jasper Dozer <ja*********@hotmail.com> scribbled the following:

ro**@zworg.com (Amarendra GODBOLE) wrote in message news:<89**************************@posting.google. com>...
[snip]
Str255 str; /* typedef unsigned char Str255[256]; */

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];
?

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

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[].

[Micah Cowan]

jo*******@my-deja.com (John Bode) writes:

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.
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.
C strings should simply be typed as char[].

Absolutely agreed :-)

-Micah

[Dave Thompson]

On Thu, 2 Oct 2003 05:48:44 -0700, "j" <ja*******@bellsouth.net>
wrote:

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bl**********@oravannahka.helsinki.fi... [ typedef Str255 for unsigned char [256] ] 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.

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.

<snip>

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.

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