Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Alessandro Pellizzari Newsgroups: it.comp.os.linux.development Subject: Re: Spreco di memoria e minaccia alla sicurezza Date: Mon, 12 Jun 2017 17:14:49 +0100 Lines: 51 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net U8B0sSat3TRVOgil2XR5lAOILfMXCNDO48RCFEw5kyLKNhfAs= Cancel-Lock: sha1:5ppbKIrlCsF/v1cWdzVXnAVyCJ8= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 In-Reply-To: Content-Language: en-US Xref: csiph.com it.comp.os.linux.development:68 On 12/06/17 15:57, guido84 wrote: > Il 12/6/2017 16:01:23 Alessandro Pellizzari scrisse: >> Ma gia` se provi a fare > >> char pippo[1]; >> char pluto[1]; > >> Scrivendo oltre il limite di pippo rischi di sovrascrivere pluto. > > TNX! questa me la faccio piu' tardi, voglio fargli sovrascrivere > pluto (ma 4k sono veramente moltissmi, glieli daro' da file). No, in questo caso non serve che allochi 4k. Ti basta scrivere 2 caratteri dentro pippo, e il secondo te lo trovi in pluto. Questo presupponendo che la memoria venga allocata in ordine. Non so se le versioni recenti di gcc o del kernel rispettino questa regola o randomizzino la memoria apposta per evitare buffer overflow. > Per fare il 3 (tralasciando per il momento che non so fargli > distinguere "-" da qualsiasi altro carattere diverso da cifre), > non posso (mi sembra!) usare malloc, perche' scanf() non me lo > puo' dire quanto e' lunga prima di riceverla. E per riceverla > deve avere un posto-vettore dove metterla... insomma: il gatto > che si mangia la coda. Percio' ho trovato l'escamotage di pippo[0] > (adesso ho visto che prende anche lo zero). In questo caso devi bufferizzare l'input, manualmente o tramite qualche libreria. Prepari un buffer di (diciamo) 4k. Provi a leggere 4k. Se l'input finisce prima, ti fermi e analizzi quello che hai, altrimenti allochi altri 4k, continui a leggere nel nuovo buffer, ecc. ecc. finche` non raggiungi la fine dell'input. A quel punto sai quanto hai letto e lo processi. In alternativa allochi 4k, provi a leggere, se non basta usi realloc per allargare il buffer (di solito si raddoppia ogni volta), e vai avanti finche` l'input non e` finito. Il tuo prossimo problema e` che atoi va in overflow superati i 9 miliardi di miliardi (una ventina di cifre, su architettura 64bit), quindi leggere piu` di 20-25 bytes e` comunque inutile, e dobresti usare una libreria come bcmath. Hai voluto lavorare a basso livello? E adesso pedala! ;D Bye.