HELP PLEASE - How to convert string to byte array

[cpptutor2000]

Could some C guru help me please? A byte is an unsigned char in C.
How do I convert from a C string to a corresponding byte array. Any
help would be greatly appreciated.

 

[Joona I Palaste]

(e-mail address removed) scribbled the following:

Could some C guru help me please? A byte is an unsigned char in C.
How do I convert from a C string to a corresponding byte array. Any
help would be greatly appreciated.

You don't need to "convert" it. A C string can be used like a byte
array.

For example:
char *s = "Hello, world!";
char c = s[0]; /* c now contains 'H' */

 

[Martin Ambuhl]

Could some C guru help me please? A byte is an unsigned char in C.

No, 'byte' is a synonym for 'char', which may be either signed or
unsigned. An unsigned byte is an unsigned char. Whether there is any
type that corresponds to, for example, an octet depends upon the
implementation.

How do I convert from a C string to a corresponding byte array. Any
help would be greatly appreciated.

A C string *is* a zero-terminated byte array.

char foo[] = "a string";

foo is a string and a char (or byte) array containing
{'a', ' ', 's', 't', 'r', 'i', 'n', 'g', 0}

 

[Ari Lukumies]

No, 'byte' is a synonym for 'char', which may be either signed or
unsigned. An unsigned byte is an unsigned char. Whether there is any
type that corresponds to, for example, an octet depends upon the
implementation.

What? Have I been away too long? I thought that a char is an entity
of value, but not necessarily one that resembles a byte. Maybe
I've missed a standard...

-atl-

 

[Martin Ambuhl]

What? Have I been away too long? I thought that a char is an entity
of value, but not necessarily one that resembles a byte. Maybe
I've missed a standard...

I have no idea what you think you said. A byte and a char are the same
by definition in C, and has been for 16 years, so you've missed not *a*
standard, but *every* standard.

Here's what a char is (3.1.2.5 in C89)
An object declared as type char is large enough to store any member
of the basic execution character set. If a member of the required
source character set enumerated in $2.2.1 is stored in a char object,
its value is guaranteed to be positive. If other quantities are
stored in a char object, the behavior is implementation-defined: the
values are treated as either signed or nonnegative integers.

Here's what a byte is (1.6 in C89)
* Byte --- the unit of data storage in the execution environment
large enough to hold any member of the basic character set of the
execution environment. It shall be possible to express the address of
each individual byte of an object uniquely. A byte is composed of a
contiguous sequence of bits, the number of which is
implementation-defined. The least significant bit is called the
low-order bit; the most significant bit is called the high-order bit.

and if that's not clear, note from the language for sizeof (3.3.3.4);
The sizeof operator yields the size (in bytes) of its operand, ...
When applied to an operand that has type char , unsigned char , or
signed char , (or a qualified version thereof) the result is 1

 

[pete]

What? Have I been away too long? I thought that a char is an entity
of value, but not necessarily one that resembles a byte. Maybe
I've missed a standard...

A byte is a unit of memory.
char is an object type.

 

[Joona I Palaste]

A byte is a unit of memory.
char is an object type.

In the context of the C programming language, "byte" and "char" are the
same thing. In other contexts they might be different.

 

[Joe Wright]

In the context of the C programming language, "byte" and "char" are the
same thing. In other contexts they might be different.

I agree. Now if we can get Chris Torek to agree ..

 

[Richard Bos]

I agree. Now if we can get Chris Torek to agree ..

Well, if you're being picky, pete is right: char is a basic object type;
a byte is the amount of memory that one object of type char takes.

Richard

 

[Joe Wright]

Well, if you're being picky, pete is right: char is a basic object type;
a byte is the amount of memory that one object of type char takes.

Richard

Maybe a difference without a distinction. The term char is a C language
thing and the term byte is more generic, having to do with memory size
and disk size, etc. For most practical purposes the C char type
describes a byte object in memory and on disk. Some might suggest a
difference between a char object and a byte object. I am not one of them.

 

[pete]

Lawrence Kirby wrote:

Note that in the description above there is no
such thing in C as a "byte
object" (objects always have a type),
a char object is a byte *sized* object.

An allocated object doesn't always have a type.

 

[Lawrence Kirby]

Maybe a difference without a distinction. The term char is a C language
thing and the term byte is more generic, having to do with memory size
and disk size, etc. For most practical purposes the C char type
describes a byte object in memory and on disk. Some might suggest a
difference between a char object and a byte object. I am not one of them.

As the standard defines them char is a type and byte is a typeless unit of
memory allocation. Although strongly related (character types are defined
to have a size of 1 byte) they are different concepts.

Note that in the description above there is no such thing in C as a "byte
object" (objects always have a type), a char object is a byte *sized*
object.

Lawrence

 

[Mark McIntyre]

An allocated object doesn't always have a type.

Can you provide an example?

 

[Ben Pfaff]

Can you provide an example?

The object that a non-null pointer returned by malloc() points to
initially has no type.

 

[pete]

Can you provide an example?

/* BEGIN new.c */

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
void *pointer;

pointer = malloc(1);
printf("If %p", pointer);
puts(
" isn't a null pointer, then it's the address of an\n"
"allocated object that doesn't have a type."
);
free(pointer);
return 0;
}

/* END new.c */

 

[Lawrence Kirby]

An allocated object doesn't always have a type.

An allocated object is a grey area. The definition of the term "object"
says it is a region of data storage then contents of which can represent
values. Well a value in an object is an interpretation of a bit pattern
according to the rules of a type - if you have no type you can't represent
values.

Lawrence

 

[pete]

An allocated object is a grey area.

Not really.
In C99 there's 3 kinds of durations for objects,
and allocated is one of them.

The definition of the term "object"
says it is a region of data storage then contents of which
can represent values.

It can represent values,
as long as you do what takes to get the values in there.

An uninitialised object of type int,
can't represent values either,
but it's still an object.

Well a value in an object is
an interpretation of a bit pattern
according to the rules of a type
- if you have no type you can't represent values.

*Until* you have a type, you can't represent values.

malloc returns the address of an object with indeterminate value.

 

[Tim Rentsch]

An allocated object is a grey area. The definition of the term "object"
says it is a region of data storage then contents of which can represent
values. Well a value in an object is an interpretation of a bit pattern
according to the rules of a type - if you have no type you can't represent
values.

Any object that is designated has a type, which is the type of the
expression used to designate it; section 6.3.2.1 p1.

Any object that is accessed has an effective type, which if it isn't
anything else is the type of the lvalue used to access it; section
6.5 p6.

Some objects have an "inherent type" in the sense that the memory
corresponds to (an instance of) a declared variable, and the variable
has a type. This "inherent type" shows up tacitly in the language of
6.5 p6, eg, "the declared type of the object, if any" (despite
effective type being defined only when accessing objects, and despite
the small inconsistency that variables, not objects, have a type
declared for them). Section 6.5 p6 specifically anticipates the
circumstance that an object not have an "inherent type", eg, "If a
value is stored into an object having no declared type ...".

Section 6.5 p7 imposes requirements on the relationship between the
type of an object (that was designated) and the effective type of an
object (that was accessed). Apparently there are no requirements
imposed on the relationship between type and effective type (or
"inherent type" for that matter), except in the case of access.

The language in the standard is confused about what the word "object"
means. It's defined (3.14) as 'a region of data storage in the
execution environment', but in lots of places in the text of the
standard it's used to mean something more like "an instance of a
variable". There is the example language above, talking about the
'declared type of the object', despite there being no definition of
what the "declared type" of an object is (at least not that I could
find). Also, although I don't have a reference, I'm pretty sure
I remember seeing a phrase like "an instance of the object", which
I took to mean that it's being used basically as a synonym for
variable.

To respond to the comment above - whenever an object is designated it
has a type, which is the type of the expression used to designate the
object; it is this type that is used to interpret what value might
be represented.

A region of storage need not have any type. Whenver that region of
storage takes part in a computation, a type is imposed on it by the
expression used to access it.