Thema: memset();

[nnosdev]

Da ich mir nicht ganz sicher bin, ob man dieser Funktion vertrauen kann wollte ich
hier mal nachfragen.. Simuliert wird auf einem 32-Bit i386er.

Code: [Auswählen]

void* memset(void *ptr, uint32 value, size_t bytes)
{
if(bytes < 1)
return 0;

uint32 *pt = (uint32*) ptr;

// Last two bytes are going to be lost after the bit shift
uint32 carry = bytes & 0x3;

// Integer division by 4
bytes >>= 2;

while(bytes) {
*pt = value;
pt++;
bytes--;
}

if(carry) {
pt++;
*pt = value;
}

return ptr;
}

Kann man dieser Funktion vertrauen? ^^

[XanClic]

Nö, erstes müsste es in der ersten while-Schleife

Code: [Auswählen]

*pt = (value << 24) | (value << 16) | (value << 8) | value;heißen (oder ähnlich) und zweitens müsste das letzte if da noch eine Schleife sein, so ist es ziemlich falsch, aber das ist der Inhalt des ifs selbst auch. Sinnvoller wäre vielleicht

Code: [Auswählen]

uint8 *bpt = (uint8 *)pt;
while (carry--)
    *(bpt++) = value;
Prinzipiell spricht aber nichts dagegen, den ganz naiven Ansatz zu gehen:

Code: [Auswählen]

void *memset(void *ptr, uint32 value, size_t bytes)
{
    uint8 *pt = ptr;
    while (bytes--)
        *(pt++) = value;
    return ptr;
}
In der Annahme, dass du ein einigermaßen standardkonformes memset schreiben willst, das eben byteweise arbeitet und in der weiteren Annahme, dass deine uintXX-Typen den normalen uintXX_t-Typen entsprechen.

[nnosdev]

Hallo XanClic,

danke für die Antwort!

Also nach meinem Post hab ich mir eben gedacht, dass es wohl sinnvoller wäre,
jedes Byte einzeln zu setzen. Im Grunde sieht meine Funktion jetzt aus
wie die von dir gepostete.
Würdest du mir diese Implementierung empfehlen oder lieber eine andere?

Prinzipiell spricht aber nichts dagegen, den ganz naiven Ansatz zu gehen:

Code: [Auswählen]

void *memset(void *ptr, uint32 value, size_t bytes)
{
    uint8 *pt = ptr;
    while (bytes--)
        *(pt++) = value;
    return ptr;
}
In der Annahme, dass du ein einigermaßen standardkonformes memset schreiben willst, das eben byteweise arbeitet und in der weiteren Annahme, dass deine uintXX-Typen den normalen uintXX_t-Typen entsprechen.

Ad uintXX_t-Typen: Wofür steht eigentlich der Zusatz "_t"

[XanClic]

Ich würde dir auf jeden Fall die Implementierung empfehlen, da heutige C-Compiler gut genug sind, das ziemlich stark zu optimieren (ich denke, gcc erkennt da direkt, dass das ein memset werden soll und packt seinen eigenen Code rein, weiß ich aber nicht genau).

Bei den Typen… Pfiua. Ich denke mal, es steht für „type“ oder „typedef“. Macht man zumindest häufiger, dass an Typen von typedefs ein _t rankommt, bei mir ist es also mehr oder weniger Gruppenzwang.

[nnosdev]

Okay, dann werd ich sie so implementieren




Die Frage hab ich mir schon oft gestellt. Wie bei dir wärs bei mir eher der Gruppenzwang als das Wissen darum, weshalb man das so nennt ^^

[kevin]

Bei den Typen… Pfiua. Ich denke mal, es steht für „type“ oder „typedef“. Macht man zumindest häufiger, dass an Typen von typedefs ein _t rankommt, bei mir ist es also mehr oder weniger Gruppenzwang.

POSIX reserviert sich das übrigens. Wenn du also ein POSIX-konformes Programm schreiben willst, darfst du strenggenommen keine neuen *_t einführen.

[Sannaj]

Das "_t". Steht warscheinlich für types. Alle Datentypen, die irgentwo in der cstdlib auftrauchen, und die nicht zu den "echten" C-Datenypen (char,short,long,int,unsigned,signed,float,double,...) gehören, tragen diese Endung.

[kevin]

bool. Widerspruch, q.e.d. 

[LittleFox]

bool wurde aus C++ übernommen
stell dir vor du müsstest jedes Mal bool_t schreiben  *angst hab'*

man müsste also "Alle Datentypen ..." zu "Die meisten Datentypen ..." umbauen

[kevin]

Ja, nur ist die Aussage dann irgendwie wertlos.

va_list und FILE dürften auch noch als "unechte" Typen durchgehen. Wahrscheinlich gibt es auch noch mehr.

[LittleFox]

hmm - auch wieder wahr