Newsgroup: it.comp.programmare.win32
Titolo: ancora su banalita' C++

approfitto prima di tutto per ringraziare tutti quelli che mi hanno 
risposto, Luc, Fed, G.U. Lauri: grazie tante: e poi:
come faccio a trasformare una variabile numerica (es: Int mynumber;) in una 
stringa? (il corrispondente della funzione BASIC 
                        STR$(#variabile)
                                                ?
Lo scopo e' di ottenere successivamente la lunghezza della stringa colla 
funzione strlen() da string.h, in modo da adattare lo spazio delle colonne 
ai dati. 
e, per evitare di annoiarvi oltre, se conoscete qualche url per reperire 
documentazione C-C++ utile allo sporco niubbo, oltre a tutorialini che 
finora ho rastrellato,  datemela, e a voi andra' la mia imperitura 
riconoscenza !
ps: PROGRAMMARE IN PIEDI FA SCHIFO. vi suggerisco caldamente di non avere 
mai nulla a che fare coll' ernia del disko e coi neurochirurghi in 
generale. :-P
-- 
*********************************
*****    Stefano Jodice    *****
*Linux addiction may kill you*
*********************************

                                                 ?
potresti usare _itoa o wsprintf
Pela

 ha scritto nel messaggio
news:9t8s62$gkj$1...@lacerta.tiscalinet.it...


 writes:
j> Lo scopo e' di ottenere successivamente la lunghezza della stringa colla 
j> funzione strlen() da string.h, in modo da adattare lo spazio delle colonne 
j> ai dati. 
Hmmm,  invece di  usare itoa()  e  strlen() (lascia  perdere printf  e
derivate per questa operazione, che č peso inutile), puoi lavorare col
logaritmo  in  base  dieci  del  numero. Guardacaso  la  parte  intera
(troncamento) del logaritmo in base  10 aumentata di 1 č la dimensione
del numero in cifre.
Un  consiglio. Visto  che č  difficile perdere  le  cattive abitudini,
abituati a non usare mai un  array di caratteri locale come buffer per
printf() e derivate.
-- 
Gian  | main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}
Uberto|                        David Korn, 1987 ioccc best one liner 
Lauri |-------------------------------------------------------------------
(aka saint) >>Vedere X-Nospam nell'header - See X-Nospam field in Header<<

printf() e derivate.
Come mai ?
Se io devo visualizzare una MessageBox composta all'interno di una
funzione mi e' comodo l'uso di un buffer locale (che muore appena
finita la funzione) dove "scaricare" le operazioni con printf o
wsprintf. Mi sfugge qualcosa ? L'overhead (credo nullo) per allocare
pochi byte per il buffer ?
Ciao
Stefano "HappyMan" 
--
IABLA Sezione Lago Maggiore (NO)
Web 
http://happyman.n3.net
 [Foto salseri/e & I.A.B.L.A. Ring]
Email: 
happyman...@libero.it
 [Togliere nospam per scrivermi]

> printf() e derivate.
S\> Come mai ?
S\> Se io devo visualizzare una MessageBox composta all'interno di una
S\> funzione mi e' comodo l'uso di un buffer locale (che muore appena
S\> finita la funzione) dove "scaricare" le operazioni con printf o
S\> wsprintf. Mi sfugge qualcosa ? L'overhead (credo nullo) per allocare
S\> pochi byte per il buffer ?
No,  ti sfugge che  non viene  fatto alcun  test sulla  dimensione del
buffer  e   quindi  può  essere  possibile  portare   il  programma  a
comportarsi in maniera decisamente inaspettata andando a sovrascrivere
il return address della funzione.  999 volte questa precauzione non ti
servirà, ma alla  100 qualcuno la userà per  sfruttare il tuo servizio
come varco per inserirsi in un sistema...


come varco per inserirsi in un sistema...
Quindi questa precauzione è inutile se in qualche modo conosci già la
lunghezza della stringa che verrà mostrata?
-- 
Marco Barisione (ICQ 84277092)

> come varco per inserirsi in un sistema...
MB> Quindi questa precauzione è inutile se in qualche modo conosci già la
MB> lunghezza della stringa che verrà mostrata?
Se la  stringa la generi tu  senza interventi di input  esterni si. Ma
dato che le  mailing list di sicurezza sono  _piene_ di exploit basati
su questo tipo di debolezza...


                                                ?
Se vuoi usare il subset C, usa pure sprintf().
Un esempio:
<CODE>
#include <stdio.h>
char *mystr(char *s, int n)
{
     sprintf(s, "%d", n);
     return s;
}
int main()
{
    char s[256];
    puts(mystr(s, 54));
    getchar();
    return 0;
}
</CODE>
Assicurati che la stringa passata alla funzione mystr, abbia
abbastanza spazio per memorizzare il numero.
Se il tuo compilatore supporta snprintf(), valuta il suo
utilizzo al posto di sprintf().
-- 
The Follet

printf() e derivate.
Non c'e' nessun motivo per non utilizzare sprintf() se ci si
assicura che la dimensione del buffer sia sufficiente.
Nel 99% dei casi, assicurare una lunghezza di 64/128/256
caratteri al buffer, e' piu' che sufficiente.
Inoltre, il nuovo standard C99 del C supporta snprintf() che
serve ad evitare questi problemi in tutti i casi.
-- 
The Follet

Nel 99% dei casi,
Non intendo dire nel 99% dei casi in generale, ma in quelli
in cui si vuol trasformare un numero, come nel caso dell'OP.
-- 
The Follet

> printf() e derivate.
TF> Non c'e' nessun motivo per non utilizzare sprintf() se ci si
TF> assicura che la dimensione del buffer sia sufficiente.
TF> Nel 99% dei casi, assicurare una lunghezza di 64/128/256
TF> caratteri al buffer, e' piu' che sufficiente.
Con  questa idea  hanno  lavorato i  programmatori  che hanno  scritto
finger e tutta un'altra serie  di daemon che sono stati poi "sfondati"
con un buffer overflow (e arrivano sempre nuovi advisory).
Allocare un  array sullo stack è  sicuro solo se  hai la dimostrazione
che  nell'esecuzione non  arriverà  _mai_ alla  funzione  un input  di
dimensione maggiore del buffer.
Se hai un  input esterno allora è garantito  che qualcuno confezionerà
una "polpetta avvelenata"  per il tuo programma. E  nemmeno togliere i
permessi di  eseguibilità delle pagine  di memoria dello stack  ti può
salvare dato che c'è già stato un polacco che ha pubblicato la tecnica
per aggirare questa forma di difesa.
Mai seguita Bugtraq ?
Nota: è proprio per l'esistenza di questo problema nell'implementazione
di sprintf() che è stata introdotta snprintf:
(dal manuale di sprintf)
BUGS
       Because  sprintf  and  vsprintf assume an arbitrarily long
       string, callers must be careful not to overflow the actual
       space;  this  is often impossible to assure. Note that the
       length of the strings  produced  is  locale-dependent  and
       difficult  to predict.  Use snprintf and vsnprintf instead
       (or asprintf and vasprintf).
La cosa buffa è che:
       The  fprintf,  printf,  sprintf,  vprintf,  vfprintf,  and
       vsprintf functions conform  to  ANSI  X3.159-1989  (``ANSI
       C'')  and  ISO/IEC  9899:1999 (``ISO C99'').  The snprintf
       and vsnprintf functions conform to ISO/IEC 9899:1999.
       Concerning the return value of snprintf, the SUSv2 and the
       C99  standard  contradict  each  other:  when  snprintf is
       called with size=0 then SUSv2  stipulates  an  unspecified
       return  value less than 1, while C99 allows str to be NULL
       in this case, and gives the return value  (as  always)  as
       the  number  of characters that would have been written in
       case the output string has been large enough.
ABIPP :)

> Nel 99% dei casi,
TF> Non intendo dire nel 99% dei casi in generale, ma in quelli
TF> in cui si vuol trasformare un numero, come nel caso dell'OP.
O.K. così ha  senso. Tu sai a priori quale è  la dimensione massima di
un numero.  D'altro canto  se usi un  buffer allocato sullo  stack non
puoi usarlo per  tornare la stringa convertita (anche  se il programma
funzionerà fintanto  che tale stringa  venga utilizzata esclusivamente
prima della chiamata a funzione  successiva, ma questa è veramente una
porcata :>).


 puoi usarlo per  tornare la stringa convertita
Questa e' un'altra cosa, tutti (o quasi) sanno che e' 
una cosa che non va fatta.
-- 
Posted from  [80.105.34.80] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 di sprintf() che è stata introdotta snprintf:
Se passi a snprintf() un valore massimo di memorizzazione
sballato, hai perso ogni aspetto legato alla sicurezza.
Allora, dire: quando uso sprintf() devo assicurarmi che
il buffer che conterra' il valore trasformato abbia 
grandezza sufficiente e' esattamente equivalente a dire
che come numero di caratteri massimi memorizzabili con
snprintf() deve essere passato il valore giusto.


> di sprintf() che è stata introdotta snprintf:
TF> Se passi a snprintf() un valore massimo di memorizzazione
TF> sballato, hai perso ogni aspetto legato alla sicurezza.
Ehi, Edlinger, smettiamo di fare il mirrorclimbing :>
Se fai uso di snprintf() per limitare il numero di caratteri messi nel
buffer di  solito non indichi  _volontariamente_ un valore che  non ha
senso o sei mona o sei mona.
snprintf() è nata apposta per  permettere alla gente di programmare in
maniera "comoda" senza correre il rischi di fare puttanate.


 Ehi, Edlinger, smettiamo di fare il mirrorclimbing :>
Qui nessuno si arrampica sugli specchi, caro il mio Seldon
dagli occhi annebbiati, sei tu che dimostri, come al solito,
di avere le idee parecchio confuse.  Ho gia' detto in un 
altro messaggio che utilizzare male la snprintf() porta 
agli stessi pericoli del cattivo utilizzo di un buffer 
sottodimensionato rispetto a sprintf().


risultato sia sufficientemente grande.
Perché mi sembra che stiate dicendo le stesse cose?


 writes:
TF> Qui nessuno si arrampica sugli specchi, caro il mio Seldon
TF> dagli occhi annebbiati, sei tu che dimostri, come al solito,
YAWN!


> risultato sia sufficientemente grande.
MB> Perché mi sembra che stiate dicendo le stesse cose?
Sono le stesse cose infatti. L'è  che il grinch ha voglia di pestare i
tasti.

YAWN!
Ecco bravo, dormi ;)
-- 
The Follet

Perché mi sembra che stiate dicendo le stesse cose?
Ti assicuro che non e' cosi'.
-- 
The Follet