C++ Jedi Wanted

Experienced C++ Developers wanted for multiple interesting projects.

Ping us for details!

Vegre egy hirdetes, amely kiemelkedik a szokasos szurkesegbol :D

Arra egyebkent meg nem jottem ra, hogy Mickey Mouse hogy jon a kepbe, de aki igen, ossza meg velem :D

Hogy inicializal egy pointervaltozot, ami a "n" sztringre mutat. Majd erre a (ha jol tudom veremben lefoglalt) memoriateruletre scanf-fel az STDIN-rol beolvas a felhasznalotol egy sztringet, ami optimalis esetben ugye "y" vagy "n", e mi van akkor, ha e helyett az van benne, hogy "a ghsdj gsfgjh dkfghshfgls hlghsljhgshlfgsld fgs" (es igy tovabb). Ez szerintem felulirja vermet, es ide azert lehet rakni fentinel "hasznosabb" adatot is.

Igazabol jobban belegondolva mar ott kezdodik a gond, hogy a char answer[]="n"; elore, implicite meghatarozza a tomb meretet 1-re (plusz zaro \0). Ettol fuggetlenul VS2012-ben egy par karaktert meg megenged tarolni benne (errol korabban is voltak emlekeim, valamiert nem koveteli meg a pontos meretegyezest), de lenyegesen tobb utan mar kiirja, hogy Access violation executing location 0x66666666. Ha meg debug-ot forditok, van kedves, es mar 2 eseten is szol, hogy Stack around the variable 'ans' was corrupted (%s es %c eseten is). Ha ez a "stack overflow", akkor Zahy talalt.

Érdekes, nálam %c esetén rohadtul nem ezt csinálja. Akkor az van (mellesleg fejből is ezt válaszoltam volna, azért leellenőriztem), hogy kiolvas az stdin bufferből egy karaktert és értékül adja a változónak. Ha a bufferben maradtak még karakterek, legközelebb ha scanf-et hívsz, akkor nem fog tőled beolvasni semmit, hanem olvassa a bufferben maradt karaktereket. Ugyanez van, ha a buffer tartalma nem felel meg a formátumstringnek, akkor a buffer nem kerül ürítésre. Ez gondolom azért jó, mert lehet scanf fákat építeni, cserébe figyelni kell a visszatérési értékre, hogy szükség esetén "kézzel" üríthesd a buffert.

Btw nem azért enged többet beolvasni, mert architektúra bitszámához igazítja a lefoglalt terület nagyságát (hogy is mondják ezt szépen)?

Valoban, %c eseten az van, amit irtal. Valamit beneztem.

#include <stdio.h>
#include <cstdlib>

int main()
{
  char ans[] = "n";
  scanf ("%c", ans);
  printf ("ans1: %s\n", ans);
  scanf ("%c", ans);
  printf ("ans2: %s\n", ans);
  system ("PAUSE");
}

Ez rendben van. Ez nem:

#include <stdio.h>
#include <cstdlib>

int main()
{
  char ans[] = "n";
  scanf ("%s", ans);
  printf ("ans1: %s\n", ans);
  scanf ("%s", ans);
  printf ("ans2: %s\n", ans);
  system ("PAUSE");
}

Btw nem azért enged többet beolvasni, mert architektúra bitszámához igazítja a lefoglalt terület nagyságát (hogy is mondják ezt szépen)?

Nem tudom, de en nem latok benne raciot. Egy char az egy byte, nekem meg megette 8 karakterig. Miert kene egy char[2]-nek epp int64 meretunek lennie Win32 targeten? Szerintem egyszeruen valamifele engedekenysegrol van szo, mint mondtam, sokszor fordult mar ilyen elo, hogy tudtam, hogy ennek nem kene belefernie, de megis mukodott - altalaban. Ezert is volt nehez az ilyen bugokat kiszurni.

( uid_7086 | 2013. 08. 27., k – 20:34 )

"Come_To_The_Dark_Side();"

Ez még akkor sem érdekelne, ha értenék a C++-hoz... :D