strlen()

Hallo Forum,

ich muß mit vielen
> unsigned char *X;
arbeiten.

1. Gibt es eine Möglichkeit ohne die ganzen casts einen strlen() darauf auszuführen?

2. Gibt es wwischen unsigned char und char einen unterschied? Vielleicht wenn ich den Zahlenwert in ein int speichere könnte was negatives rauskommen, aber jeder Funktion die einen unsigned char erwartet kann ich doch einen char übergeben?

Vielen Dank

Martin

CStoll

Ja, es gibt einen Unterschied zwischen 'unsigned char' (immer vorzeichenlos 0..255) und normalem 'char' (je nach System vorzeichenbehaftet -128..127 oder vorzeichenlos 0..255 - aber in jedem Fall ein eigenständiger Typ). Und ich befürchte, wenn du einen 'unsigned char*' an eine Funktion übergeben willst, die einen char* erwartet, kommst du ums Casten nicht herum.

(was spricht eigentlich dagegen, normale char*s zu verwenden?)

Undertaker

martin_salo schrieb:

1. Gibt es eine Möglichkeit ohne die ganzen casts einen strlen() darauf auszuführen?

#define STRLEN(x) strlen((const char*)(x))

martin_salo schrieb:

2. Gibt es wwischen unsigned char und char einen unterschied? Vielleicht wenn ich den Zahlenwert in ein int speichere könnte was negatives rauskommen, aber jeder Funktion die einen unsigned char erwartet kann ich doch einen char übergeben?

char a = -1;
int x = a;  // x ist jetzt -1
int x = (unsigned char)a; // x ist jetzt +255

es wird anders interpretiert, aber verloren geht nichts, weil 'signed char' und 'unsigned char' gleich viele bits haben.

Ich arbeite mit einer DLL von einer Fremdfirma und die benutzt "unsigned char". Elendiges gecaste...

Hey! Das Define ist eine gute Idee.

CodeFinder

martin_salo schrieb:

Hey! Das Define ist eine gute Idee.

Finde ich gar nicht, extremes Beispiel:

STRLEN(5);

Aber ist wohl Ansichtssache.

Ein C++ Template dafür zu erstellen wäre aber Overkill.

CodeFinder

Schreib einfach die Casts aus...
Oder Du verwendest Inline-Funktionen.

Undertaker

CodeFinder schrieb:

martin_salo schrieb:

Hey! Das Define ist eine gute Idee.

Finde ich gar nicht, extremes Beispiel:
STRLEN(5);

ein mindestmass an C-kenntnisssen musste schon voraussetzen

CodeFinder schrieb:

Schreib einfach die Casts aus...

das will er doch nicht.

*D*Evil

inline size_t ustrlen(const unsigned char* const string)	
{
	if (string == 0)
		return 0;

	size_t res = 0;
	while (string[res])	++res;
	return res;
}

vllt?

CStoll

Undertaker schrieb:

CodeFinder schrieb:
martin_salo schrieb:

Hey! Das Define ist eine gute Idee.

Finde ich gar nicht, extremes Beispiel:
STRLEN(5);
ein mindestmass an C-kenntnisssen musste schon voraussetzen

Das Problem bei dem Makro ist aber, daß der Aufruf 'STRLEN(5)' anstandslos durch den Compiler kommt - und zur Laufzeit mächtig auf die Nase fallen wird.

Ansonsten ist es wohl besser, die Cast's notfalls in einer Funktion zu verstecken (btw, seit welcher Version versteht C 'inline'?).

Shade Of Mine

CStoll schrieb:

Ansonsten ist es wohl besser, die Cast's notfalls in einer Funktion zu verstecken (btw, seit welcher Version versteht C 'inline'?).

ja, in eine funktion packen ist deutlich besser als das makro. makros sind kein ersatz für funktionen.

inline gibts seit c99

inline ist aber nicht ganz unproblematisch - aber solange man nicht zuviel hackt, sollte das kein problem darstellen.

Es ist ein Klasse/Warpper für eine CryptoEngine die ich benutzen muß. Das STRLEN Makro ist lokal nur in dieser Klasse gültig; ich bin der einzige der an diesem Modul arbeitet. Für mich ist es ein guter Kompromiss aus Übersichtlichkeit und Korrektheit...

Shade Of Mine schrieb:

inline ist aber nicht ganz unproblematisch - aber solange man nicht zuviel hackt, sollte das kein problem darstellen.

Was ist an inline problematisch?

(ausser dass es nicht immer inlined wenn angegeben)

Undertaker

Tim schrieb:

Was ist an inline problematisch?

lässt sich schlecht debuggen und grosse inline-funktionen mehrfach aufgerufen blähen das binary auf, sonst nix.

Undertaker schrieb:

Tim schrieb:

Was ist an inline problematisch?

lässt sich schlecht debuggen und grosse inline-funktionen mehrfach aufgerufen blähen das binary auf, sonst nix.

Stimmt, debuggen könnte aufwändiger werden. Und dass die Binaries größer werden liegt ja fast schon in der Natur von inline. Und wer große Funktionen inlinen will ist selbst schuld

CStoll

martin_salo schrieb:

Es ist ein Klasse/Warpper für eine CryptoEngine die ich benutzen muß.

"Klasse" klingt für mich nach C++ - und das ist eine Etage tiefer

Das STRLEN Makro ist lokal nur in dieser Klasse gültig;

Bin ich der einzige, den es stört, daß "Makro" und "lokal in der Klasse" in einem Satz erwähnt werden?

@inline: Von C++ Compilern erwartet man, daß sie selber entscheiden, ob sie eine Funktion tatsächlich inlinen (und bei extrem großen Funktionen verzichten sie idR freiwillig drauf). Warum sollen da C-Compiler dümmer sein? (oder ist inline-Expansion in C vorgeschrieben?)

CStoll schrieb:

(oder ist inline-Expansion in C vorgeschrieben?)

Ja leider nicht. Aber das ist ein anderes Thema.

Undertaker

Tim schrieb:

CStoll schrieb:

(oder ist inline-Expansion in C vorgeschrieben?)

Ja leider nicht. Aber das ist ein anderes Thema.

C compiler, auch vor C99, haben oft #pragmas etc, mit denen man 'inline' erzwingen kann.

CodeFinder

Undertaker schrieb:

ein mindestmass an C-kenntnisssen musste schon voraussetzen

Naja, darum gehts ja bei dem Beispiel nicht, glaube es ist jedem klar, dass man es so nicht schreiben darf, deswegen ja auch ein 'extremes' Beispiel... . CStoll hat das Problem, worauf ich hinweisen wollte, schon perfekt auf den Punkt gebracht :

CStoll schrieb:

Das Problem bei dem Makro ist aber, daß der Aufruf 'STRLEN(5)' anstandslos durch den Compiler kommt - und zur Laufzeit mächtig auf die Nase fallen wird.