Problem mit String und Pointer

Du hast keinen Inhalt im sms_buffer[] (==sBase64_roh) in deinem 
Codeschnippsel. Es ist, wenn wie gezeigt verwendet, mit dem gefüllt, was 
zufällig im Stack steht.

Meist nichts druckbares. Oft auch mal eine 0, die das Ende des Strings 
bedeutet.
Daher ist die Ausgabe die du angibst Plausibel.

Leute, die Casts sind in Ordnung, wenn auch unnötig.

char chArray[] ;
und
char *chPointer ;

sind Variablen mit äquivalenten Datenetypen. (Bis auf das Treatment von 
Warnings)

1

char *sBase64_roh;

2

char sms_buffer[721];

3

4

sBase64_roh = &sms_buffer[0];

5

6

Uart_Puts(sBase64_roh);

Die 3(4?) Impliziten hier.

char[] zu char& zu char *
und das ?:
char *
zu const char *

Der eine Implizite in

1

Uart_Puts(sms_buffer);

hätte ausgereicht.

Tim Seidel schrieb:
>

1

> char *sBase64_roh;

2

> char sms_buffer[721];

3

> 

4

> sBase64_roh = &sms_buffer[0];

5

> 

6

> Uart_Puts(sBase64_roh);

7

>

>
> Die 3(4?) Impliziten hier.

Da gibt es keinen implizite Casts.
Alle Datentypen passen perfekt zusammen.

> char[] zu char& zu char *

Den Cast gibt es in C gar nicht.
Und da an dieser Stelle char[] nichts anderes als eine
andere Schreibweise für char* ist, ist auch sofort ersichtlich,
dass es diesen cast, wenn es ihn gäbe, gar nicht braucht.

> sBase64_roh = &sms_buffer[0];

sms_buffer         ist ein Array von char
sms_buffer[0]      ist ein einzelnes Element aus diesem Array,
                   hat also den Datentyp char
&sms_buffer[0]     Wendet man den Address Operator auf einen char an
                   erhält man selbstverständlich einen char*

sBase64_roh = &sms_buffer[0];    links vom = ist der Datentyp char *
                                 rechts vom = ist der Datentyp char *

Also, warum soll da irgendetwas gecastet werden?

> und das ?:
> char *
> zu const char *

Das ist kein Cast.
In die umgekehrte Richtung wäre es einer.
Aber so rum passiert nichts, weil keine Notwendigkeit dazu besteht.

const ist die Zusicherung, nichts zu verändern.
Wenn dir dein Kumpel zusichert, in ein geliehenes Buch nichts 
hinzuschreiben, kannst du ihm bedenkenlos deine wertvolle 
Guthenberg-Bibel geben. Selbst wenn man in die prinzipiell etwas 
hineinschreiben könnte (sie also nicht const ist), dein Kumpel behandelt 
sie ja als nicht-beschreibbar (const)

Erst im umgekehrten Fall musst du dir Sorgen machen:
Deine Bibel ist const (also als nicht-beschreibbar anzusehen) und dein 
Kumpel gibt dir bei der Übernahme nicht die Zusicherung, dieses const zu 
respektieren.
Dann musst du dir überlegen, inwieweit du deinem Kumpel traust, und das 
const für den Zeitraum des Ausleihens wegcastest.

> Der eine Implizite in
>

1

> Uart_Puts(sms_buffer);

2

>

> hätte ausgereicht.

Wenn wir mal eine übliche Def. voraussetzen
void Uart_Puts( const char* string )
dann wird auch hier nichts implizit gecastet.
Die Initialisierung einer const Variablen mit einem Wert erfordert 
keinen Cast, wenn der restlichen Datentypen übereinstimmt. Die Variable 
legt sich stärkere Restriktionen auf, was mit ihr möglich ist. Das 
tangiert aber nicht die Quelle des Wertes und erfordert auch keinerlei 
Aktionen bei der Zuweisung.
Erst umgekehrt, wenn die Quelle über Restriktionen verfügt, die das Ziel 
nicht gewillt ist einzuhalten (oder zumindest keine Zusage dafür 
abgibt), sind Aktionen (wie zb ein Cast) notwendig.

Loonix schrieb:

> Wäre interessant ob es dem TE auch weitergeholfen hat?

Dazu müsste man erst mal wissen, was er eigentlich machen will.
Will er den String an sich ausgeben, oder will er den numerischen Wert 
der Adresse, an der der String gespeichert ist, wissen (wozu auch 
immer).

Im ersten Fall, stimmt das schon so wie er das hat. Jedoch ist der 
eigentliche String entweder nicht initialisiert oder es ist ganz einfach 
ein Leerstring.

Im zweiten Fall, müsste er den numerischen Wert des Pointers erst mal 
mit zb ltoa (wenn sizeof(long) == sizeof(void*)) oder sprintf selbst in 
einen String umwandeln lassen, um den dann mittels Uart_Puts auszugeben.

>> char[] zu char& zu char *
>
> Den Cast gibt es in C gar nicht.

Achso. Dann ist die ANSI-C Spec falsch:
> If the unary * operator is applied to this
> pointer explicitly, or implicitly as a result of subscripting, the
> result is the pointed-to ( n -1)-dimensional array, which itself is
> converted into a pointer if used as other than an lvalue.

> The array-subscript
> [] and member-access .  and -> operators, the address & and
> indirection * unary operators, and pointer casts may be used in the
> creation an address constant, but the value of an object shall not be
> accessed by use of these operators.

Ob die Konversation nun irgendwelche Instruktionen benötigt oder ohne 
Zutun die Binärrepräsentation verwenden kann, ändert nichts daran, dass 
es eine Wandlung (Cast) des qualifizierten Datentyps ist.

Nach Ansi-C sind die beiden qualifizierten Typen const char und char 
nicht kompatibel.
Damit wird eine Wandlung (die aus Nichts ausser dem "Merken" des const 
allein durch den Compiler besteht) in beide Richtungen nötig,
denn die Kompatibilitäts-Relation:
> For two qualified types to be compatible, both shall have the
> identically qualified version of a compatible type; the order of type
> qualifiers within a list of specifiers or qualifiers does not affect
> the specified type.
ist offensichtlich symetrisch.

Tim Seidel schrieb:
>>> char[] zu char& zu char *
>>
>> Den Cast gibt es in C gar nicht.
>
> Achso. Dann ist die ANSI-C Spec falsch:


Wo kommt in den ANSI-C Spec der Datentyp char& (also eine Referenz) vor?

> Nach Ansi-C sind die beiden qualifizierten Typen const char und char
> nicht kompatibel.

OK.
Trotzdem betreibst du hier Haarspalterei

(und wenn wir genau sind, haben wir von const char* und char* 
gesprochen. Und diese beiden Datentypen SIND per Definition kompatibel. 
Der C-Standard macht dafür extra eine Ausnahme :-)

Bei der Zuweisung eines int an einen long gibt es so gesehen dann auch 
einen 'impliziten cast', der allerdings nicht wirklich irgend jemanden 
auch nur im Geringsten interessiert. Und dort ändert sich unter 
Umständen sogar das Bitmuster.

Tim Seidel schrieb:
>>> char[] zu char& zu char *
>>
>> Den Cast gibt es in C gar nicht.
>
> Achso. Dann ist die ANSI-C Spec falsch:
>> If the unary * operator is applied to this
>> pointer explicitly, or implicitly as a result of subscripting, the
>> result is the pointed-to ( n -1)-dimensional array, which itself is
>> converted into a pointer if used as other than an lvalue.
>


Hmm. Der Punkt gilt ja wohl bei
sBase64_roh = &sms_buffer[0];
nicht. Denn hier wird kein unary * operator angewendet, weder explizit 
noch implizit, denn der & operator und anwenden dieser Regel ...

>> The array-subscript
>> [] and member-access .  and -> operators, the address & and
>> indirection * unary operators, and pointer casts may be used in the
>> creation an address constant, but the value of an object shall not be
>> accessed by use of these operators.

... verbietet das. Da ist ausdrücklich davon die Rede, dass & den Wert 
nicht antatscht, dass es also bei der Auswertung von

    &sms_buffer[0]

zu keinem impliziten unary * (Dereferenzierung) kommt. Statt dessen 
steht da, dass eine "address constant" gebildet wird. Und eine "address 
constant", vulgo Pointer, hat meines Wissens nicht den Datentyp 
iregdnwas[] sondern irgendwas*

Karl heinz Buchegger schrieb:
> Tim Seidel schrieb:
>>>> char[] zu char& zu char *
>>>
>>> Den Cast gibt es in C gar nicht.
>>
>> Achso. Dann ist die ANSI-C Spec falsch:
>>> If the unary * operator is applied to this
>>> pointer explicitly, or implicitly as a result of subscripting, the
>>> result is the pointed-to ( n -1)-dimensional array, which itself is
>>> converted into a pointer if used as other than an lvalue.
>>
>
>
> Hmm. Der Punkt gilt ja wohl bei
> sBase64_roh = &sms_buffer[0];
> nicht. Denn hier wird kein unary * operator angewendet, weder explizit
> noch implizit, denn der & operator und anwenden dieser Regel ...

Doch, das wird es.
sBase64_roh = &sms_buffer[0]; evaluiert zu
sBase64_roh = &(*(sms_buffer+(0)))

>
>>> The array-subscript
>>> [] and member-access .  and -> operators, the address & and
>>> indirection * unary operators, and pointer casts may be used in the
>>> creation an address constant, but the value of an object shall not be
>>> accessed by use of these operators.
>
> ... verbietet das. Da ist ausdrücklich davon die Rede, dass & den Wert
> nicht antatscht, dass es also bei der Auswertung von

Du missverstehst den Satz.

Was dort beschrieben wird ist z.B. die folgende Situation (absichtlich 
alles dabei):

1

char array[4] = { 1,2,3,4 } ;

2

u32 val = *(int *)&array[0] ;

Hier wird der Typ des Pointer gecastet. Der Wert jedoch wird nicht 
angetatstet (weder gelesen noch geschrieben)

val ist nach dem Satz oben das int an der Stelle von array (je nach 
endianess) und nicht (das ist die zentrale Aussage, neben der 
Seitenbemerkung, dass es sich bei subscriptions des ersten Quotes um 
Casts handelt) dass val = (int) 1 ist. (bei dem der Wert angefasst und 
erweiter worden wäre.


>     &sms_buffer[0]
>
> zu keinem impliziten unary * (Dereferenzierung) kommt. Statt dessen
> steht da, dass eine "address constant" gebildet wird. Und eine "address
> constant", vulgo Pointer, hat meines Wissens nicht den Datentyp
> iregdnwas[] sondern irgendwas*

>>> may be used in the
>>> creation an address constant

Da steht nicht, wie du hier behaupten willst. Schlüsselworte sind hier 
"may" und in vorderster front "in the creation". Genauer: a) Es muss 
nicht b) und es muss nicht in einem Schritt erledigt sein

Also kann und muss (um OBdA zu arbeiten) angenommen werden, dass jeder 
Schritt zur Adressenbildung auch durchgeführt wird.


PS: Das mit dem Haarespalten fing m.E. früher an. Ich lass mich ungern 
mit falschen Aussagen korrigieren. Insbesondere dann nicht, wenn diese 
falschen Aussagen von Accounts kommen, die eine besondere Verpflichtung 
zur Genauigkeit und gutem Umgangston haben.

Und das für die simple Aussage, dass die Typzuweisungen passen ... naja

Tim Seidel schrieb:

> Und das für die simple Aussage, dass die Typzuweisungen passen ... naja

Genau das ist der springende Punkt
Wiellst du in Zukunft jede Zuweisung ala

 long i;
 i = 5;

mit 'die impliziten Casts sind ok' kommentieren?
Dein Aufbringen der Thematik Casting trägt in dieser Fragestellung 
nichts bei.

Hi,

teste mal:

1

char *sBase64_roh;

2

char sms_buffer[]="Hallo, Welt";

3

4

sBase64_roh = &sms_buffer[0];

5

6

Uart_Puts("AUSGABE DES ROH TEXTES: ");

7

Uart_Puts(sBase64_roh);

Dann siehst du, ob zumindest der Kram funzt (sollte). Ab wo beginnst du 
dein array zu füllen, ab [0] oder [1] ?
Falls erst bei [1], dann könnte in [0] eine 0 stehen, das wäre das Ende 
deines strings :-)

Noch ein Tipp: (s)printf liefert dir die Zahl der Zeichen zurück, damit 
kann man schöne Sachen machen wie:

1

char string[1024];

2

char *pString;

3

4

pString = string;

5

6

pString += sprintf(pString, "Hallo ");

7

pString += sprintf(pString, "Welt");

8

9

printf(string);

Anmerkung: Ev. die n-variante vom sprintf (snprintf) verwenden, auf die 
Gefahr eines Überlaufes hin.


VG,
/th.

muss man da nicht solche strings explizit ins ROM tackern mit PROGMEN ?

Karl heinz Buchegger schrieb:
> Tim Seidel schrieb:
>
>> Und das für die simple Aussage, dass die Typzuweisungen passen ... naja
>
> Genau das ist der springende Punkt
> Wiellst du in Zukunft jede Zuweisung ala
>
>  long i;
>  i = 5;
>
> mit 'die impliziten Casts sind ok' kommentieren?
> Dein Aufbringen der Thematik Casting trägt in dieser Fragestellung
> nichts bei.

Zumindest dann, wenn wie geschehen behauptet wird, dass die Zuweisung 
nicht in Ordnung ist.