[c] String functies

[Verwijderd]

Ik gebruikt strcat om twee strings aan elkaar te zetten, maar dat gaat niet helemaal goed, dit is mijn code:

char str[100];
bzero (str);
strcat (str, "test");
strcat (str, "\n");

Op een of andere manier geeft dit een segmentation fault. Als ik die laatste strcat weghaal dan gaat het wel goed.

[Verwijderd]

code:

bzero(str);

Wat doet deze functie???

Wil toch zeggen dat str 0 wordt... oftwel NULL ??
Lijkt me niet de bedoeling.

Al doet ie dat niet en veranderd deze functie de inhoud. Hoe moet die dan weten wanneer hij klaar is...

edit:
ik vond via google de bzero terug en nu snap ik 'm, had dus wel een size_t n...

code:

void bzero(void *s, size_t n);

[Feyd-Rautha]

ik kan mij vergissen, maar moet de functie strcat geen twee referenties binnenkrijgen. Als je een tabel meegeeft geeft hij problemen dacht ik.

dan zou volgende code misschien wel moeten lukken

code:

char* tekst = "hallo"
strcat(tekst, " testje"

[-FoX-]

Ik snap de bedoeling niet echt van die laatste strcat, er zijn toch andere manieren om zoiets op te lossen..

[Pooh]

bzero krijgt volgens mij 2 argumenten, namelijk een void* en een size_t. Wat hij doet mij 1 argument is mij een beetje onduidelijk, maar volgens mij niks... (met size_t als argument vult hij je string(geheugen) met 0-en).

Dat betekent dus dat je str nog steeds ongedefinieerd gevuld is, waardoor strcat inderdaad gekke resultaten kan opleveren.

[Soultaker]

Op dinsdag 11 juni 2002 20:34 schreef -Avalanche- het volgende:
dan zou volgende code misschien wel moeten lukken

code:

char* tekst = "hallo"
strcat(tekst, " testje"

Just for the record: dit kan ABSOLUUT NIET (los van de 'vergeten' haakjes en puntkomma's).

[Feyd-Rautha]

Op dinsdag 11 juni 2002 21:02 schreef Soultaker het volgende:

[..]

Just for the record: dit kan ABSOLUUT NIET (los van de 'vergeten' haakjes en puntkomma's).

[bijleermode]
waarom dan niet?
[/bijleermode]

[Pooh]

Op dinsdag 11 juni 2002 21:10 schreef -Avalanche- het volgende:

[..]

[bijleermode]
waarom dan niet?
[/bijleermode]

Omdat je eens moet kijken wat er staat?

char* tekst = "hallo"

Dat is dus een pointer naar een char, die noem je 'tekst'. Die pointer ('tekst') moet dus een geheugenadres toegewezen krijgen, maar wat doe jij, je propt er een const string (of const char[]) in.

[.oisyn]

Op dinsdag 11 juni 2002 21:10 schreef -Avalanche- het volgende:

[..]

[bijleermode]
waarom dan niet?
[/bijleermode]

tekst is een pointer die wijst naar een buffertje van chars. Alleen is deze buffer niet beschrijfbaar omdat je m laat wijzen naar een constante string

En al was ie wel beschrijfbaar: wie garandeert dat er genoeg ruimte is om de 2e string erachter te plakken?

dit werkt wel:

code:

char tekst[32] = "hallo";
strcat (tekst, " daar");

Dominique: misschien is het handiger om sprintf te gebruiken, zodat je in een keer veel strings aan elkaar kunt plakken (zorg wel dat je buffer groot genoeg is!!). Of doe het zo:

code:

char str[100];
strcpy (str, "test");
strcat (str, "\n");

dan hoef je m iig niet leeg te maken, aangezien strcpy gewoon de string "test" eroverheen zet
strcat plakt vervolgens de "\n" erachter

[Creepy]

Gromz.. ik moet echt beter opletten..
hier stond iets doms

[Verwijderd]

Het gaat er eigenlijk om dat die string over een tcp connectie wordt verzonden. Om een enter te krijgen moet je \n\r erbij stoppen. Nu kan ik wel mijn functie om data te verzenden veranderen, maar dan moet ik ook mijn gehele prog aanpassen.

Wat dus de uiteindelijk bedoeling is:

Creeer een string en roep de functie write_message (char *msg) aan. Er moet dus voor string meegegeven worden als parameter.

BTW Zo goed kan ik nou ook weer niet C, strcat leek mij toch wel makkelijk, maar uiteindelijk leidde dat tot een segmentation fault. Andere opties zijn dus ook welkom...

[Soultaker]

Op dinsdag 11 juni 2002 21:28 schreef Dominique het volgende:
Creeer een string en roep de functie write_message (char *msg) aan. Er moet dus voor string meegegeven worden als parameter.

BTW Zo goed kan ik nou ook weer niet C, strcat leek mij toch wel makkelijk, maar uiteindelijk leidde dat tot een segmentation fault. Andere opties zijn dus ook welkom...

Als je nou lering zou trekken uit hetgeen door diverse mensen gesuggereerd is, dan zouden wij ook weer het idee hebben dat we nuttig bezig zijn.

Ik zal het nog één keer voor je uitspellen. In elk geval moet die aanroep naar bzero helemaal weg. Verder heb je globaal drie mogelijken.

1. Eerste karakter van je buffer op \0 zetten en vervolgens alle strings erin strcat'en.

2. Voor de eerste aanroep strcpy gebruiken en voor de overige aanroepen strcat, aangezien voor strcpy de buffer niet geinitialiseerd hoef te worden.

3. sprintf() gebruiken om op een degelijke manier een string te formatteren.

In alle drie de gevallen geldt dat je de lengte van je buffer niet controleert, wat potentieel gevaarlijk is (zeker als je via een netwerk gaat communiceren en derden dus misschien invloed hebben op hetgeen in de buffer komt te staan). In de eerste twee gevallen zul je daarom strncat en strncpy moeten gebruiken om in ieder geval te kunnen garanderen dat je binnen de gereserveerde bufferruimte blijft.

(En tenslotte: dat je geen C kan betekent niet dat je wordt vrijgesteld van het lezen van reacties of manuals.)

[.oisyn]

Op dinsdag 11 juni 2002 21:28 schreef Dominique het volgende:
Om een enter te krijgen moet je \n\r erbij stoppen.

misschien is het hier een typefout, maar dat moet dus \r\n zijn

[Verwijderd]

De lengte van de strings wordt wel degelijk gecontroleerd, er wordt echt geen overbodige informatie over het netwerk/internet verzonden. Daar hoef je niet over in te zitten. Het probleem was dan ik \n er niet aan kon catten.

Ik heb geen problemen met het lezen van reacties/manuals, maar als ik de strcat manual lees, dan gaat er in mijn code niet zoveel fout. De code is geschreven in Linux en ik heb het net ff uit m'n hoofd overgetypt in Windows, daardoor stonden er fouten (bzero).

BTW Ik snap niet helemaal hoe een derde ooit invloed kan uitoefenen op de buffer, een derde kan toch niet zomaar ff andere instructies uitvoeren om mijn eigen geschreven code?

BTW 2, ik haal de nuttige informatie er wel degelijk uit en ga uiteindelijk toch alles wel in elkaar prutsen. Mijn vorige post was geen kritiek, maar een nadere uitleg waarom ik bepaalde dingen deed en wat de uiteindelijke bedoeling is.

[Verwijderd]

\n\r of \r\n, maakt dat zoveel uit? In ieder geval in mijn originele code staat het goed, het geheel draait al. Ik zal ff naar jullie raad luisteren en mijn code aanpassen.

[Soultaker]

Op dinsdag 11 juni 2002 21:47 schreef Dominique het volgende:
De lengte van de strings wordt wel degelijk gecontroleerd, er wordt echt geen overbodige informatie over het netwerk/internet verzonden. Daar hoef je niet over in te zitten.

Ik zat meer in over beveiliging/stabiliteit. Als je buiten je buffers schrijft, zou willekeurige data in je codesegment terecht kunnen komen. In het gunstigste geval crasht je computer dan, in een ongunstig geval kan een buitenstaander locaal code uitvoeren.

Het probleem was dan ik \n er niet aan kon catten.

Waarom niet?

BTW Ik snap niet helemaal hoe een derde ooit invloed kan uitoefenen op de buffer, een derde kan toch niet zomaar ff andere instructies uitvoeren om mijn eigen geschreven code?

Het hangt er vanaf in hoeverre je gegevens van derden bij het vullen van lokale buffers gebruikt. Dat kan ik zo niet beoordelen, maar ik kan het principe wel illustreren.

Stel je voor dat je een chatserver bouwt, waarin de gebruiker zijn nickname kan instellen. Bij het wijzigen van de nickname moet je deze nickname naar de andere chatters sturen, omdat ze anders niet kunnen weten dat 'ie gewijzigd is. Dit bericht wordt eerst in een lokale buffer geconstrueerd en in deze buffer komt onder andere de door mij opgegeven nickname voor. Als ik nu een nickname kies, die bestaat uit een heleboel NOP instructies gevolgd door wat 'evil' code, kan het zomaar gebeuren dat ik een deel van jou code overschrijf, waardoor op een gegeven moment mijn 'evil' code op jou syteem wordt uitgevoerd.

Bovenstaande exploit werkt natuurlijk alleen als de programmeur nalatig is, maar het is geen slecht gebruik om 'defensief' te programmeren. Ervoor zorgen dat je nooit buiten door jou gereserveerd geheugen schrijft is daar een basisonderdeel van. De overhead van een operatie als strncpy ten opzichte van strcpy is in de gemiddelde applicatie verwaarloosbaar en als het er dus voor kan zorgen dat je kunt aantonen dat je programma daarop niet zal crashen, dan is die overhead de moeite waard.

[.oisyn]

Op dinsdag 11 juni 2002 21:49 schreef Dominique het volgende:
\n\r of \r\n, maakt dat zoveel uit?

op zich niet, maar \r\n is de algemene standaard voor text-based internet protocollen

Ook kan het best dat een \n\r werkt op standaard protocollen, maar dat komt door de achterliggende software... Het is niet volgens de standaard, dus zal het best wel kunnen dat andere software die met dat zelfde protocol werkt je end of lines ineens niet accepteert

[Verwijderd]

Het werkt nu, iedereen bedankt voor zijn/haar hulp.

\n catten lukte niet omdat de buffer niet omdat de buffer waarschijnlijk zijn eigen grootte overschreedt.

\n is een linefeed en \r is een carriage return, mij lijkt dat het niets uitmaakt als je een linefeed en dan een carriage return gebruikt of andersom.

[Soultaker]

Op dinsdag 11 juni 2002 22:04 schreef .oisyn het volgende:
Ook kan het best dat een \n\r werkt op standaard protocollen, maar dat komt door de achterliggende software... Het is niet volgens de standaard, dus zal het best wel kunnen dat andere software die met dat zelfde protocol werkt je end of lines ineens niet accepteert

Als ik me niet vergis, staat juist expliciet in het telnet protocol beschreven dat zowel CR-LF als LF-CR als newline beschouwt dient te worden. Software die met een op telnet gelayerd protocol werkt, dient LF-CR dan ook te herkennen. Het kan best zo zijn dat er software is die dit niet doet, maar in dat geval ligt de fout dus bij die software en niet de applicatie van de topicstarter.

Nu moet ik zeggen dat ik nog nergens in deze thread de term telnet tegengekomen ben, dus het zou best kunnen dat het om een heel ander protocol gaat. Daar kunnen we geen van beiden iets over zeggen, natuurlijk.

[.oisyn]

Op dinsdag 11 juni 2002 22:23 schreef Soultaker het volgende:

[..]

Als ik me niet vergis, staat juist expliciet in het telnet protocol beschreven dat zowel CR-LF als LF-CR als newline beschouwt dient te worden. Software die met een op telnet gelayerd protocol werkt, dient LF-CR dan ook te herkennen. Het kan best zo zijn dat er software is die dit niet doet, maar in dat geval ligt de fout dus bij die software en niet de applicatie van de topicstarter.

oh, dat wist ik niet... ik weet wel dat het bij HTTP, IRC en volgens mij ook FTP een /r/n moet zijn

[Verwijderd]

Ik test het inderdaad op telnet, maar het is de bedoeling dat het uiteindelijk met een ander programma (geschreven door een mede student) communiceert.

[farlane]

Op woensdag 12 juni 2002 09:46 schreef Dominique het volgende:
Ik test het inderdaad op telnet, maar het is de bedoeling dat het uiteindelijk met een ander programma (geschreven door een mede student) communiceert.

In dat geval ben je natuurlijk vrij om je formaat te definieren zoals jij en je medestudent dat wilt. Toch lijkt het me handig om het op een gangbaar protocol te baseren. Daarin zijn vaak al wat valkuilen ontweken waarin jij anders ongetwijfeld nog zult gaan trappen.

[igmar]

Op dinsdag 11 juni 2002 20:27 schreef Dominique het volgende:
Ik gebruikt strcat om twee strings aan elkaar te zetten, maar dat gaat niet helemaal goed, dit is mijn code:

char str[100];
bzero (str);
strcat (str, "test");
strcat (str, "\n");

Op een of andere manier geeft dit een segmentation fault. Als ik die laatste strcat weghaal dan gaat het wel goed.

bzero() slikt 2 argumenten : void *, size_t
Een beter alternatief is memset(), wat de 'opvolger' is van bzero()

Hetgeen wat ik krijg bij het compilen is een error die zegt dat bzero() 2 argumenten slikt. Voor de rest is de code goed.