[C] Char leegmaken

[Servowire]

Ik heb een stuk code waarin een char steeds word gebruikt om een stukje text in op te slaan, maar nou overschrijf ik hem gewoon steeds (met strcpy) maar nou blijft de oude tekst, als deze langer is dan de nieuwe, half staan....

Is er een functie om een char leeg te mikken?

[whoami]

Je bedoeld dat je een char array hebt?

Je kan 'm misschien eerst op null zetten.

[curry684]

Servowire schreef op 06 januari 2004 @ 18:56:
Ik heb een stuk code[...knip...]

Handig dat je 'm ook laat zien Nu kunnen we tenminste direct aanwijzen wat je fout doet!

[Servowire]

code:

char      buffer[256];
strcpy(buffer,"woeptiedoe");

En dan moet hij gewoon weer leeg worden

[Creepy]

Je zou eens je string eens kunnen afsluiten met een \0. Hiermee geef je het daadwerkelijke einde van je string aan.

Uit de manpage van strcpy
The strcpy() function copies the string pointed to by src (including
the terminating `\0' character) to the array pointed to by dest. The
strings may not overlap, and the destination string dest must be large
enough to receive the copy.

[Glimi]

Servowire schreef op 06 januari 2004 @ 19:00:

code:

char      buffer[256];
strcpy(buffer,"woeptiedoe");

En dan moet hij gewoon weer leeg worden

Waarom? Je blijft toch altijd 256 characters gereserveerd hebben hoor?

Creepy schreef op 06 januari 2004 @ 19:06:
Je zou eens je string eens kunnen afsluiten met een \0. Hiermee geef je het daadwerkelijke einde van je string aan.

De code die hij geeft is toch een const char * met een \0 erbij?

[Verwijderd]

buffer[0] = '\0'

op de eerste positie het 'nul' karakter

[zeroxcool]

Verwijderd schreef op 06 januari 2004 @ 19:13:
buffer[0] = '\0'

op de eerste positie het 'nul' karakter

Ik meen dat het einde van een string ook een bit op zich nam .

Beetje overheen gekeken, that's should do the trick .

[ Voor 18% gewijzigd door zeroxcool op 06-01-2004 19:20 ]

[.oisyn]

Als je 'm echt helemaal leeg wilt dan kun je ook memset () oid gebruiken natuurlijk

[Creepy]

Glimi schreef op 06 januari 2004 @ 19:11:
De code die hij geeft is toch een const char * met een \0 erbij?

* Creepy schopt zichzelf. *auw*. Beter opletten volgende keer. _{Veel te lang geleden, dat C}

[ Voor 33% gewijzigd door Creepy op 06-01-2004 19:23 ]

[RickN]

strncpy()

[.oisyn]

RickN schreef op 06 januari 2004 @ 20:17:
strncpy()

Wat heb je daar aan strncpy kopieert maximaal n tekens, hij gaat niet de rest aanvullen met \0 als de \0 wordt tegengekomen voordat er n tekens gekopiëerd zijn

je zou hooguit kunnen zeggen dat het veiliger is ivm buffer overflows

[ Voor 23% gewijzigd door .oisyn op 06-01-2004 20:52 ]

[RickN]

Ja, ik had wel iets verboser kunnen zijn

STRCPY(3) Linux Programmer's Manual STRCPY(3)

NAME
strcpy, strncpy - copy a string

SYNOPSIS
#include <string.h>

char *strcpy(char *dest, const char *src);

char *strncpy(char *dest, const char *src, size_t n);

DESCRIPTION
The strcpy() function copies the string pointed to be src
(including the terminating `\0' character) to the array
pointed to by dest. The strings may not overlap, and the
destination string dest must be large enough to receive
the copy.

The strncpy() function is similar, except that not more
than n bytes of src are copied. Thus, if there is no null
byte among the first n bytes of src, the result wil not be
null-terminated.

In the case where the length of src is less than that of
n, the remainder of dest will be padded with nulls.

RETURN VALUE
The strcpy() and strncpy() functions return a pointer to
the destination string dest.

BUGS
If the destination string of a strcpy() is not large
enough (that is, if the programmer was stupid/lazy, and
failed to check the size before copying) then anything
might happen. Overflowing fixed length strings is a
favourite cracker technique.

CONFORMING TO
SVID 3, POSIX, BSD 4.3, ISO 9899

SEE ALSO
bcopy(3), memccpy(3), memcpy(3), memmove(3)

strncpy doet dus aan zeropadding. Ik maakte uit het verhaal van TS op dat hij dat wilde, maar kan me vergissen. Als je nu als laatste parameter van strncpy sizeof(dest) gebruikt, copieer je src naar dest en zeropad je de rest...

[.oisyn]

strncpy doet dus aan zeropadding

oh, blijkbaar toch wel. Dan heb ik mij vergist, I stand corrected (dat krijg je als je gewoon std::string gebruikt )

[Glimi]

Ik snap eigenlijk nog steeds niet waarom? Als je tot \0 leest, dan maakt het toch niet uit wat er verder in die buffer staat. Hell, waarschijnlijk staat er niet eens \0 in als je hem initialiseerd.

[RickN]

Glimi schreef op 06 januari 2004 @ 23:18:
Ik snap eigenlijk nog steeds niet waarom? Als je tot \0 leest, dan maakt het toch niet uit wat er verder in die buffer staat. Hell, waarschijnlijk staat er niet eens \0 in als je hem initialiseerd.

Ik heb hier ooit een thread over op de lkml gelezen.

Het is een (erg vergezocht) security risico. Het gedeelte achter de \0 kan ongeïnitialiseerde, of erger, nog vertrouwelijke data bevatten van het vorige gebruik van die buffer. Als je voorbij de \0 kan kopieren kun je daarmee perongeluk teveel data van b.v. een priviliged naar een unpriviliged user kopieren.

thread gevonden
Na een paar berichten gaat de thread over security.

[ Voor 5% gewijzigd door RickN op 07-01-2004 00:29 ]

[.oisyn]

Precies om die reden was er zo'n ophef over het opsturen van crash reports naar MS onder windows XP geloof ik. Er werd persoonlijke info meegestuurd. Niet met opzet, maar het punt was dat er in het report wat ongeinitialiseerd geheugen terecht kon komen, wat dus mogelijk persoonlijke info bevatte van wat ooit op dat geheugenadres stond.

[igmar]

.oisyn schreef op 06 januari 2004 @ 20:50:
je zou hooguit kunnen zeggen dat het veiliger is ivm buffer overflows

Ook niet helemaal. strncpy() terminate NIET met \0 als de buffer 'vol' is. Ik heb inmiddels de strlcpy() en strlcat() uit BSD 'geleend' die doen het namelijk wel

[RickN]

igmar schreef op 07 januari 2004 @ 09:20:
[...]


Ook niet helemaal. strncpy() terminate NIET met \0 als de buffer 'vol' is. Ik heb inmiddels de strlcpy() en strlcat() uit BSD 'geleend' die doen het namelijk wel

Maar die padden je buffer dan weer niet

[mvdejong]

In the case where the length of src is less than that of
n, the remainder of dest will be padded with nulls.

Dit is niet standaard (i.e. Kernighan and Richtie) C, voor zover functies dat al kunnen zijn. Het is een leuk feature, dat ik echter nog in geen andere compiler-/library-versie ben tegengekomen, en het zou zelfs een programma dat ik ooit heb geschreven kapot maken (nou was dat ook niet de mooiste truc ...).

"Normaal" gedrag van strncpy is :
- als de source-string < n : de gehele inhoud van de source-string wordt gekopieerd, gevolgd door een '\0' (dus er worden lengte(source-string) + 1 tekens in de destination string geplaatst);
- als de source-string >= n : er worden n tekens van de source-string gekopieerd, niet gevolgd door een '\0' (dus er worden n tekens in de destination-string geplaatst).

Voor de TS : zoals al aagegeven is memset is de juiste (en meest portable) functie om het beoogde effect te bereiken, daarmee vult je de hele string met het gewenste character :

code:

#define BUFLEN (256)
char      buffer[BUFLEN];
:
memset (buffer, '\0', BUFLEN);
strcpy(buffer,"woeptiedoe");
:

[RickN]

Ik kan geen enkele referentie vinden voor strncpy() waarbij niet expliciet wordt aangegeven dat de destination indien nodig tot n bytes wordt gepad.

Wat bedoel je met "geen andere compiler-/library-versie"? Voorzover ik zo snel kan zien geldt het iig voor alle grote *nix-en en *bsd's en ook voor alle versies van windows, zie MSDN. Verder wordt in elke referentie die ik heb gezien ANSI-C compatibiliteit geclaimt....

edit:

In die thread die ik eerder poste las ik nog wel dat de generieke versie van strncpy in linux momenteel buggy is en wellicht niet op alle architecturen (maar volgens de thread wel op x86) het bedoelde gedrag vertoont. Misschien werk je dus niet op x86 en werkt je code bij gratie van een bug in strncpy...

edit:
Als je kernel hacker bent zou dat wellicht de boel verklaren, de versie van strncpy die in de linux kernel gebruikt wordt (en dus niet in userspace zichbaar is) wijkt af van het normale gedrag en pad expliciet niet. Gelukkig heet deze functie ook gewoon strncpy om misverstanden te voorkomen

edit:
En als toegift:
ISO C Standard 9899:1999
Section 7.21.2.4

[ Voor 70% gewijzigd door RickN op 07-01-2004 11:29 ]

[igmar]

RickN schreef op 07 januari 2004 @ 09:23:
Maar die padden je buffer dan weer niet

Idd. Geen probleem hier, als de data gevoelig is memset ik 'm wel

[igmar]

RickN schreef op 07 januari 2004 @ 10:12:
Ik kan geen enkele referentie vinden voor strncpy() waarbij niet expliciet wordt aangegeven dat de destination indien nodig tot n bytes wordt gepad.

De meesten doen dat ook niet is mijn ervaring. Ik kan me een aantal situaties bedenken waar dit bij mij code problemen gaat geven. Mijn persoonlijke mening is dat dit aan de programmeur is, strncpy() moet gewoon copieeren, niet padden.

[Glimi]

RickN schreef op 07 januari 2004 @ 00:28:
Het is een (erg vergezocht) security risico. Het gedeelte achter de \0 kan ongeïnitialiseerde, of erger, nog vertrouwelijke data bevatten van het vorige gebruik van die buffer. Als je voorbij de \0 kan kopieren kun je daarmee perongeluk teveel data van b.v. een priviliged naar een unpriviliged user kopieren.

Dank u
Een klein gokje, maar ik denk dat de TS daar niet mee bezig is. Anderzijds, is het natuurlijk hartstikke mogelijk dat je passwords binnen een applicatie welke temp in een char buffer zitten ook wilt clearen

[.oisyn]

igmar schreef op 07 januari 2004 @ 09:20:
[...]


Ook niet helemaal. strncpy() terminate NIET met \0 als de buffer 'vol' is. Ik heb inmiddels de strlcpy() en strlcat() uit BSD 'geleend' die doen het namelijk wel

en dus gebruik je sizeof(buffer)-1 en laat je de laatste byte altijd op '\0' staan

mvdejong schreef op 07 januari 2004 @ 09:42:
[...]

Dit is niet standaard (i.e. Kernighan and Richtie) C, voor zover functies dat al kunnen zijn. Het is een leuk feature, dat ik echter nog in geen andere compiler-/library-versie ben tegengekomen, en het zou zelfs een programma dat ik ooit heb geschreven kapot maken (nou was dat ook niet de mooiste truc ...).

misschien moet je je docs nog eens doornemen, want alle C99 docs die ik gelezen heb melden idd dat strncpy zero-padden

dinkumware: http://www.dinkumware.com...=c/&h=string.html#strncpy
comeau: http://www.eskimo.com/~scs/C-faq/q13.2.html
man strncpy onder debian en freebsd 4.7 melden ook het zero-padden
netbsd 1.6: http://www.daemon-systems.org/man/strncpy.3.html (let ook op "The strcpy() and strncpy() functions conform to ISO/IEC 9899:1999 (``ISO C99'')"

K&R is natuurlijk ook een beetje outdated

[ Voor 58% gewijzigd door .oisyn op 07-01-2004 14:38 ]