character assignment

[CptDondo]

I came across this bit of code:

char devname[4] = "wl0";
....
devname[2]++;

This looks wrong to me.... I am chasing a bad pointer issue in this
code, and I suspect this is not valid C.

--Yan

 

[David T. Ashley]

I came across this bit of code:

char devname[4] = "wl0";
...
devname[2]++;

This looks wrong to me.... I am chasing a bad pointer issue in this code,
and I suspect this is not valid C.

The second assignment makes sense. The collation sequence for the ASCII
digits is linear, so someone is trying to go from , for example, "wl0" to
"wl1".

The first assigment doesn't make sense to me. "wl0" (which will include a
zero terminator) is a statically allocated string managed by the compiler.
I'm not aware that a typical compiler will allow this syntax. The string
should have the type of (char *), perhaps with const.

How about:

char devname[4] = {'w', 'l', '0', 0};

?

And there are no warnings or errors from the compiler?

 

[CptDondo]

I came across this bit of code:

char devname[4] = "wl0";
...
devname[2]++;

This looks wrong to me.... I am chasing a bad pointer issue in this code,
and I suspect this is not valid C.

The second assignment makes sense. The collation sequence for the ASCII
digits is linear, so someone is trying to go from , for example, "wl0" to
"wl1".

Right - except, as you point out, the string is static, so I don't see
how the bloody thing is incremented later.

The first assigment doesn't make sense to me. "wl0" (which will include a
zero terminator) is a statically allocated string managed by the compiler.
I'm not aware that a typical compiler will allow this syntax. The string
should have the type of (char *), perhaps with const.

How about:

char devname[4] = {'w', 'l', '0', 0};

OK, I'll try that.

?

And there are no warnings or errors from the compiler?

None that I've seen, but the development environment hides a lot of
information. As it apparently works for the developer, but not for me,
there resulting errors may well be gcc-version dependent.

In the older, working version of the code, they assign

char *devname = "wl0";

and then increment that. (??? This really makes no sense.)

I'm going to rewrite it correctly, and see if that fixes the issue.

 

[Walter Roberson]

I came across this bit of code:
char devname[4] = "wl0";

The first assigment doesn't make sense to me. "wl0" (which will include a
zero terminator) is a statically allocated string managed by the compiler.
I'm not aware that a typical compiler will allow this syntax.

char *devname = "wl0";

would be the case of a (theoretically read-only) string managed by
the compiler. (If my memory holds, the compiler is not -required- to
statically allocate the string... that's just by far the easiest way to
meet the lifetime requirements.)


char devname[4] = "wl0";

is completely valid C. The C standard specifically indicates that
an array of char may be initialized by a string literal, with
successive elements of the literal being assigned into successive
elements of the array. The resulting array will be writable.

 

[Mike Wahler]

I came across this bit of code:

char devname[4] = "wl0";
...
devname[2]++;

This looks wrong to me.... I am chasing a bad pointer issue in this code,
and I suspect this is not valid C.

The second assignment makes sense. The collation sequence for the ASCII
digits is linear, so someone is trying to go from , for example, "wl0" to
"wl1".

Yes, and the language guarantees that the digit characters ('0'
through '9') do indeed have consecutive values.

The first assigment doesn't make sense to me.

The first line is not an assignment, it's an initialization,
and is indeed valid. It creates an array of four characters,
initializes the first with 'w', the second with '1', the third
with '0', and the fourth with zero. (i.e. a zero-terminated
string).

"wl0" (which will include a zero terminator) is a statically allocated
string managed by the compiler.

... which is placed in the array 'devname'.

I'm not aware that a typical compiler will allow this syntax.

Any conforming compiler must.

The string should have the type of (char *), perhaps with const.

No, that would not be a string. That would be a pointer.

How about:

char devname[4] = {'w', 'l', '0', 0};

That is also valid. But what OP posted is just as valid,
and far more common (I suppose because it's easier to type
and to read).

I think you need to do some reading about arrays and pointers
in C.

See the reviews at www.accu.org for book selections.

-Mike

And there are no warnings or errors from the compiler?

There shouldn't be any. Nothing is wrong.

-Mike

 

[Charlton Wilbur]

>> I came across this bit of code:
>>
>> char devname[4] = "wl0"; ... devname[2]++;
>>
>> This looks wrong to me.... I am chasing a bad pointer issue in
>> this code, and I suspect this is not valid C.

It is, actually, valid C.

DTA> The first assigment doesn't make sense to me. "wl0" (which
DTA> will include a zero terminator) is a statically allocated
DTA> string managed by the compiler.

....which is used as an initializer for the char array that's allocated
in that line.

DTA> How about:

DTA> char devname[4] = {'w', 'l', '0', 0};

DTA> ?

Functionally identical to what's there, but a lot harder to make sense of.

DTA> And there are no warnings or errors from the compiler?

It's valid C - why should the compiler complain?

Charlton

 

[Walter Roberson]

char devname[4] = "wl0";
devname[2]++;

The second assignment makes sense. The collation sequence for the ASCII
digits is linear, so someone is trying to go from , for example, "wl0" to
"wl1".

Right - except, as you point out, the string is static, so I don't see
how the bloody thing is incremented later.

The string is not static. The relevant section of C89 (X3.159-1989)
is 3.5.7; I don't know the corresponding ISO section number.

devname[2]++; is not going to create any pointer problems for you.

However, note that devname will have lifetime appropriate to its
scope, whereas char *devname = "wl0"; would point to something
with essentially indefinite lifetime but which is theoretically
read-only.

Based on what you have said, the code previously relied upon
the indefinite lifetime, and relied upon literals being writable.
The corresponding correct code would be

static char devname[4] = "wl0";

That would only be initialized once, not once per visit to the
function.

 

[Charlton Wilbur]

CD> Right - except, as you point out, the string is static, so I
CD> don't see how the bloody thing is incremented later.

The string literal is used as an initializer for the array that's
allocated.

CD> In the older, working version of the code, they assign

CD> char *devname = "wl0";

CD> and then increment that. (??? This really makes no sense.)

When you write

char devname[4] = "wl0";

you are allocating an array of 4 chars and initializing it to 'w',
'l', '0', 0. That char string is modifiable, and has automatic
storage duration. In many implementations, it would be stored on the
stack.

When you write

char *devname = "wl0";

you allocate a pointer that points to that string literal. The
compiler may store it anywhere it wants; you can't modify it without
invoking undefined behavior. The pointer variable has automatic
storage duration. In some implementations, the string would be stored
in a read-only segment of the executable.

CD> I'm going to rewrite it correctly, and see if that fixes the
CD> issue.

char devname[4] = "wl0"; *is* written correctly.

Charlton

 

[Al Balmer]

I came across this bit of code:

char devname[4] = "wl0";
...
devname[2]++;

This looks wrong to me.... I am chasing a bad pointer issue in this
code, and I suspect this is not valid C.

Keep looking <g>. The expression is one I would avoid, but it's not
causing your problem.

 

[David T. Ashley]

The first assigment doesn't make sense to me. "wl0" (which will include a
zero terminator) is a statically allocated string managed by the compiler.
I'm not aware that a typical compiler will allow this syntax.

char *devname = "wl0";

would be the case of a (theoretically read-only) string managed by
the compiler. (If my memory holds, the compiler is not -required- to
statically allocate the string... that's just by far the easiest way to
meet the lifetime requirements.)

char devname[4] = "wl0";

is completely valid C. The C standard specifically indicates that
an array of char may be initialized by a string literal, with
successive elements of the literal being assigned into successive
elements of the array. The resulting array will be writable.

Thanks for the correction. I've never seen that initialization syntax.

I'm only familiar with:

char *p = "I like coconuts and grapes.";

and it was my understanding that in that case that compiler was assigning a
pointer into a static string pool.

But I may be wrong there again, too! Beat me up more if I blew that one,
too!

Thanks.

 

[Richard Tobin]

I'm only familiar with:

char *p = "I like coconuts and grapes.";

and it was my understanding that in that case that compiler was assigning a
pointer into a static string pool.

But I may be wrong there again, too! Beat me up more if I blew that one,
too!

You are right, in that case the string may be in read-only memory and
(I think) shared with other strings.

-- Richard

 

[Walter Roberson]

You are right, in that case the string may be in read-only memory and
(I think) shared with other strings.

In C89, literal strings need not be distinct, and need not be writable.
But in C89, I cannot find any indication of the scope or lifetime
of a string literal, so I do not think it is correct to say that
the compiler is necessarily "assigning a pointer into a static string pool".

There must be -something- about the lifetime, as it is well understood
that pointers to literals may be returned and may be stored and passed
around. The common usages are such that string literals must have
a lifetime "as if" equivilent to that of static variables, but if the
compiler can determine that a particular literal's address is not
being squirreled away, I see no documented limitation that would
prevent the compiler from effectively making the string literal local
to a routine -- possibly even coding the contents right into
the instruction space. I have these flashbacks to disassembling
in my Z80 days...

 

[Ben Pfaff]

In C89, literal strings need not be distinct, and need not be writable.
But in C89, I cannot find any indication of the scope or lifetime
of a string literal, so I do not think it is correct to say that
the compiler is necessarily "assigning a pointer into a static string pool".

C89 (or at least a late draft) says:

A character string literal has static storage duration and
type ``array of char,'' and is initialized with the given
characters.

 

[CBFalconer]

.... snip ...
prevent the compiler from effectively making the string literal
local to a routine -- possibly even coding the contents right into
the instruction space. I have these flashbacks to disassembling
in my Z80 days...

What makes you think such coding into instructions isn't static
storage?

 

[Walter Roberson]

Walter Roberson wrote:

... snip ...

What makes you think such coding into instructions isn't static
storage?

a) It wouldn't be a "static pool of strings";
b) In my Z80 days, bank switching was used to extend memory, and
it was not uncommon for a swappable bank to include instructions. It
is debatable as to whether such a situation would be "static
storage" or not.

 

[WaterWalk]

I came across this bit of code:

char devname[4] = "wl0";
...
devname[2]++;

This looks wrong to me.... I am chasing a bad pointer issue in this
code, and I suspect this is not valid C.

Both are valid C. I remember that old C compilers would require this:
static char devname[4] = "wI0";
But it seems that since c89 this restraint no longer exists.