if (val & ~0xff) ist doch immer false?

ihoernchen

Im Source von git, sha1_file.c:

int get_sha1_hex(const char *hex, unsigned char *sha1)
{
	int i;
	for (i = 0; i < 20; i++) {
		unsigned int val = (hexval(hex[0]) << 4) | hexval(hex[1]);
		if (val & ~0xff)
			return -1;
		*sha1++ = val;
		hex += 2;
	}
	return 0;
}

Der Ausdruck

if (val & ~0xff)

ist doch immer false, oder?

Da
0xff = 1111 1111
~0xff = 0000 0000

und irgendwas bitweise verundet mit 0 ist immer 0?
Welchen Sinn hat diese Zeile?

Oder hätte ich einfach nur mehr schlafen sollen heute Nach?

rüdiger

val ist ein unsigned int und ist sehr wahrscheinlich größer als 8 Bit. Entsprechend prüft der Ausdruck ob Bits oberhalb der 8 Bits gesetzt sind.

(Bsp für 16 Bit, LE)
0xff = 0000 0000 1111 1111
~0xff = 1111 1111 0000 0000

hustbaer

vielleicht gibt hexval(x) ja z.B. -1 zurück wenn x keine hex-digit ist? dann würde es nämlich sinn machen.

ihoernchen

Rüdiger hat es ja erklärt.
Ich habe nicht besonders gut nachgedacht und das 0xff auf 0xffff erweitert (bzw. alles 1).
Das war das Problem. Jetzt ist es klar

ihoernchen schrieb:

Ich habe nicht besonders gut nachgedacht und das 0xff auf 0xffff erweitert (bzw. alles 1).

stell dir einfach vor was ~1, ~2, ~3, usw. sein könnte, also nicht 0. warum sollte ~255 da eine ausnahme machen?

ihoernchen

Das hab ich nicht verstanden.
~255 ist null, sofern ich einen 8 bit Datentyp hab.

Mache ich das auf einen Datentyp > 8 bit habe ich eine Zahl > 255 (bei einem Startwert von 255).
Mein Problem war, dass ich das 0xff in Gedanken auf 0xffff erweitert habe und nicht auf 0x00ff.

ghorst

mal eine ganz dummer frage: wofür brauchst du das?

ihoernchen schrieb:

Das hab ich nicht verstanden.
~255 ist null, sofern ich einen 8 bit Datentyp hab.

und ~1 ist null, wenn du einen 1-bit datentyp hast. also hast du's ja doch verstanden.

ghorst schrieb:

mal eine ganz dummer frage: wofür brauchst du das?

fricky schrieb:

ihoernchen schrieb:

Das hab ich nicht verstanden.
~255 ist null, sofern ich einen 8 bit Datentyp hab.

und ~1 ist null, wenn du einen 1-bit datentyp hast. also hast du's ja doch verstanden.

Also die Definition des Komplements sollte folgendem entsprechen x - ~x = 0, sonst wäre es ja nicht das Komplement, somit wäre bei einem 1-Bit Typ das Komplement gerade der Wert selbst.

Äh?? schrieb:

Also die Definition des Komplements sollte folgendem entsprechen x - ~x = 0, sonst wäre es ja nicht das Komplement, somit wäre bei einem 1-Bit Typ das Komplement gerade der Wert selbst.

da kann irgendwas nicht stimmen. woher ist diese definition?

ghorst

Äh?? schrieb:

Also die Definition des Komplements sollte folgendem entsprechen x - ~x = 0,

x**+**~x=0

.filmor

Nur im Einerkomplement.

hustbaer

~ flippt einfach alle bits, was das für auswirkungen auf die zahl hat schreibt der standard AFAIK nicht vor.

normalerweise wird two's complement verwendet, also -x == ~x + 1 wenn ich mich jetzt nicht irre

hustbaer schrieb:

~ flippt einfach alle bits, was das für auswirkungen auf die zahl hat schreibt der standard AFAIK nicht vor.

normalerweise wird two's complement verwendet, also -x == ~x + 1 wenn ich mich jetzt nicht irre

So siehts aus, dann ist nämlich a - b == a + ~b + 1.

if (val &amp; ~0xff) ist doch immer false?

if (val & ~0xff) ist doch immer false?