Newsgroup: it.comp.lang.c
Titolo: cast e malloc

Ho letto più volte dell'inutilità di fare il cast del valore di ritorno 
della malloc.
Tuttavia, mi chiedevo se si possa considerare una buona pratica di 
programmazione.
Considerate questo codice:
double* s;
....
....
s = malloc(sizeof(float)*len);
Ovviamente è un bel casino, ovvio pure che è un errore stupido però 
capita e il compilatore non protesta.
Invece:
double* s;
....
....
s = (float*)malloc(sizeof(float)*len);
Consente al compilatore di segnalare il piccolo ma seccante errore.
Pensate che il vantaggio valga la pena della piccola perdita di succintezza?
Saluti,
Giuseppe

 ha scritto nel messaggio
news:fik0ub$mk0$1...@aioe.org...

Il modo migliore è senza dubbio:
s = malloc(sizeof (*s) * len);
Totalmente parametrizzato!
Infatti
s = (double *)malloc(sizeof (float) * len);
secondo te va bene (anche senza il warning) ?
Direi di no.
--
Giorgio Silvestri
DSP/Embedded/Real Time OS   Software Engineer

 Direi di no.
Certo che no ma almeno spunta fuori il warning, nel primo caso passa 
tutto sotto silenzio.
Comunque la tua soluzione è certamente più generale. Grazie del consiglio,
Giuseppe

 tutto sotto silenzio.
Non viene fuori nessun warning. Una volta che hai castato, la frittata è
fatta.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


beh li' sta ai tuoi gusti secondo me.
Intendo dire che i warning servono per ricordarsi di possibili
porcate, ma se compilo e ho 1000 warning magari mi da' fastidio (che
so 900 riguardano
parte gia' testate e solo ricompilate e 100 nuovo codice).
Io cerco di toglierli, ma solo dopo la prima volta che lo trovo.
per capirci, la prima volta scrivo senza cast;compilo e ho il warning;
a quel punto  lo sistemo e da li' non lo avro' piu'
ciao davide

 a quel punto  lo sistemo e da li' non lo avro' piu'
Non capisco che vuoi dire.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 



ok, sono stato un po' frettoloso nella spiegazione.
Quando scrivo una malloc, non mi preoccupo in quel momento di fare un
cast; alla prima compilazione verra' fuori quindi. A quel punto, di
solito,
faccio un cast, in modo da non avere piu' il warning. Cioe' il primo
warning me lo tengo come avviso, poi pero' non ne voglio piu' vedere
di warning sulla
stessa istruzione e lo sistemo!
Chiaro?

 cast; alla prima compilazione verra' fuori quindi. 
Non viene fuori un bel niente. Il compilatore non ti dà alcun warning se
non usi il cast, perché la pratica corretta è *proprio* quella di non
usare il cast. Il cast in C non è necessario e non va usato.


 
Il cast in C è necessario e va usato quando è appropriato usarlo !!!
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   Registered Linux user #337974  < 
http://giovanni.homelinux.net/
 >

 Il cast in C è necessario e va usato quando è appropriato usarlo !!!
Il cast in C *NON E' NECESSARIO NEL CASO SPECIFICO E NON VA USATO*.
E' stato detto migliaia (milioni?) di volte sia qui dentro che su
comp.lang.c.
Prima di dire scemenze sei pregato di informarti.


 Prima di dire scemenze sei pregato di informarti.
Mi sono più che informato. Ho scritto qualche programma ;-)



Concordo ;-)
A meno di non volere una pletora di Warnings o forzare la 
disabilitazione di *tutti* i warning
level. Questo, e' chiaro, vale per tutti i compilatori, ad esclusione di 
quelli usati da particolari
individui ;-)
Brix

 Mi sono più che informato. Ho scritto qualche programma ;-)
Non ne hai scritti abbastanza per sapere come stanno realmente le cose.
E hai ancora molto da imparare. 


 Questo, e' chiaro, vale per tutti i compilatori
Non vale per *nessun* compilatore.



Laforgia ha sicuramente i suoi limiti di comunicazione e  a volte tende 
ad essere pedante. Ma tu e Giovanni state cercando di sostenere l' 
insostenibile. Cast della malloc *necessario* ? *va usato* ? 
Riferimenti, please.
Non c'e' un solo rigo dello standard che dica qualcosa del genere e 
basterebbe guardare il prototipo di malloc (ritorna un void *)  per 
capire che affermazioni del genere non stanno ne'  in cielo ne'  in terra.
Se  poi lavori con compilatori che danno warning,  ho solo due suggermenti:
1)  controlla che il warning non dipenda dall'  aver omesso l' 
inclusione  di stdlib.h  (che poi è  il principale motivo a favore dell' 
omissione del cast).
2)  controlla che usi un compilatore C e  non uno C++.
Giorgio

 Laforgia ha sicuramente i suoi limiti di comunicazione
Pastore, i limiti di comunicazione ce li avrai tu.


 E hai ancora molto da imparare. 
Come al solito tu avresti *MOLTO* da imparare se invece di limitarti a 
leggere il manuale avessi fatto anche qualche lavoro più complesso che 
qualche esercizio scolastico.


Giorgio Pastore ha scritto:

Mi spiego: la malloc ritorna un void* quindi non e' necessario fare un 
cast esplicito.
Su questo sono d'accordo, anche se io preferico comunque tipizzare il 
ritorno.
Il discorso mi sembrava un po' piu' generale: il cast in C c'e' e quando 
serve va usato.
Nel particolare di funzioni con ritorno void* non è necessario, ma 
secondo me
e' preferibile indicare comunque il tipo.
Ad ogni moodo, *vecchi* compilatori C prototipano char* come ritorno di 
malloc:
ovvio che non e' piu' la norma, ma c'e' sempre da fare manutenzione....
Spero di avere chiarito (al news, non all' individuo sopracitato, a cui 
non rispondo)
brix

 leggere il manuale 
Ci vuole un bel coraggio per ribattere nel modo in cui stai facendo,
gettando merda sugli altri, quando sei *PALESEMENTE* nel torto. Ci vuole
davvero un bel coraggio. Vergognati idiota.


> usare il cast. Il cast in C non è necessario e non va usato.
------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
O forse non scrivi in Italiano?


 ovvio che non e' piu' la norma, ma c'e' sempre da fare manutenzione....
Che bel modo di arrampicarsi sugli specchi. Il codice pre-ANSI da
manutenere non esiste più in giro da un bel pezzo.


 O forse non scrivi in Italiano?
O forse sei incapace di leggere e capire di cosa si sta parlando?
Il discorso segue un filo logico che parte dal topic principale del
thread: cast e malloc. Leggi come si intitola una discussione, prima di
buttarti a capo fitto agganciandoti all'ultimo messaggio di una catena.
Chiunque abbia un briciolo di cervello capirebbe che il mio messaggio si
aggancia al discorso precedente sul cast sul valore di ritorno di
malloc(). E' di quello che si sta parlando.
p.s.: "italiano" si scrive minuscolo, in italiano.


>>> usare il cast. Il cast in C non è necessario e non va usato.
--------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Rileggi cosa ha scritto Andrea  Il 3D si riferisce alla malloc() ma 
leggendo il post non mi sembra che così sia scritto nell'ultima frase.


 cast; alla prima compilazione verra' fuori quindi.
Non viene fuori un bel niente. Il compilatore non ti dà alcun warning se
non usi il cast, perché la pratica corretta è *proprio* quella di non
usare il cast. Il cast in C non è necessario e non va usato."
Quando dico "il cast in C non è necessario" mi riferisco esattamente a ciò
di cui si sta dibattendo: il valore di ritorno di malloc.


   
Ovvio che sai tutto di questo, neeeeh???
Il codice pre ANSI *esiste* ed e' ancora manutenuto con gli stessi 
vecchi compilatori,
come esistono vecchi microcotrollori ancora usati e manutenuti.
Purtroppo in certi ambienti bisogna garantire anche 20 anni o piu' di 
ricambi
hardware e software *certificati*.
 In certi ambienti *non* si cambia una virgola di quello che e' il 
processo di generazione
del software e gli strumenti usati a *meno* di rivalidare tutto e 
prendersene l' onere.
In certi ambienti anche per cambiare una *virgola* o uno statement 
bisogna rivalidare
il tutto con mesi di test e costa.
brix
NB:
 "certi ambienti", vedi applicazioni militari, per aereospaziale, 
medicale e ambientini
simili ....devo dedurne che all' individuo in questione manca una certa 
esperienza?
Non sia mai!

 vecchi compilatori,
<snip>
Non è di questo che si stava parlando.


 
Stronzetto presuntuoso,  Se tu avessi solo un poco di educazione 
avresti capito che scrivere programmi è diverso dal leggersi il solo 
standard ANSI e che in questo NG si parla del linguaggio C come 
implementato dai vari compilatori non di quello che vorresti imporre tu.


 
Solo gli ignoranti come te nl scrivono in minuscolo.


   
"Il codice pre-ANSI da manutenere non esiste più in giro da un bel pezzo."
Andrea Laforgia, sempre su 
www.aforismi.net
 o su www.insulto.og

 "Il cast in C non è necessario e non va usato."
Inutile. Sei un idiota.


 
*Tutti*  li abbiamo. Tu  a volte fai dichiarazioni avventate (non 
dimostrabili o  false ) per puro spirito polemico. Rilassati. Non è  che 
ti pagano di meno se provi ad essere meno brusco.
Giorgio

 e' preferibile indicare comunque il tipo.
Laforgia ti ha spiegato come mai è preferibile NON mettercelo. Hai letto 
i suoi post?
E.

 implementato dai vari compilatori non di quello che vorresti imporre tu.
Tu non lo sai di che cosa si parla in questo ng, perché non hai la minima
idea di che cosa significhi programmare correttamente in C. Non hai
competenza tecnica, non hai preparazione, eppure ti arroghi il diritto di
parlare, accusare, puntare il dito e farti sonore risate. Vergognati.
In questo ng si parla di C, e quando si dice "C" si intendi il C standard,
ratificato da un comitato ISO. Quando si scende nello specifico di certe
implementazioni, esistono ng appositi. Tu puoi continuare a battere i
piedi quanto vuoi, poi, sull'argomento di cui si sta dibattendo: sei nel
torto.
Rassegnati.


 dimostrabili o  false ) per puro spirito polemico.
Dimostrami quale affermazione falsa io abbia fatto in questo thread.


 i suoi post?
Lascia perdere. E poi sarei io ad avere il "puro spirito polemico". 
ROTFL.


> Solo gli ignoranti come te nl scrivono in minuscolo.
Lemma  	italiano
Sillabazione/Fonetica 	[i-ta-lià-no]
Definizione 	agg. dell'Italia: popolo italiano; civiltà, lingua
italiana | all'italiana, alla maniera degli italiani, secondo il
costume degli italiani: mangiare, vestire all'italiana
¶ s. m.
1 [f. -a] abitante, nativo dell'Italia
2 lingua romanza parlata in Italia: scrivere, parlare in buon italiano
| la lingua e la letteratura italiana, in quanto materia
d'insegnamento nelle scuole: professore, esame d'italiano
§ italianamente avv. alla maniera degli italiani, secondo il carattere
e lo spirito degli italia

 
È solo uno stronzetto presuntuoso.
:-( Povera scuola Italiana, nemmeno ha imparato a rileggersi :-(
Ma vedo che siamo in buona compagnia.
http://tinyurl.com/29qqk2


On 4 Dic, 16:24, brix99luftballons <brix99luftball...@hotmail.invalid>
wrote:

2 precisazioni:
ho mescolato 2 argomenti; uno era il discorso dei warning ricorrenti
( enn c'entra con le malloc);
la'altro era la malloc in C++ che mi da' giustamente dei warning.
Nn so perche' ho mischiato ste 2 cose, sorry :)

 
Leggi più  attentamente. Non ho scritto "in questo thread". In quello 
intitolato "virgola mobile e fissa", tra molte cose giuste, preso dalla 
foga  hai scritto: "La dimensione dei tipi fondamentali *NON* è fissata, 
il che lascia libero qualsiasi implementatore di usare quella che più lo 
aggrada; l'implementazione *NON* è fissata, quindi qualsiasi 
implementatore può attuare quella che vuole.".
E'  falso  perché  in realtà  lo standard, anche se non prescrive dei 
valori, pone dei vincoli,  ma si capisce che ti è  scappato nella foga 
polemica. Non sminuisce l'  opinione che chi segue questo NG si può 
fare di te. Tuttavia dovrebbe farti riflettere sul fatto  che *tutti* 
possiamo scrivere qualcosa di sbagliato e non per questo le reazioni 
devono essere brusche.
Giorgio

 Rassegnati.
Si!  Oramai sono rassegnato.  È impossibile trattare con te.
Mi sono accorto di essere in compagnia:
http://tinyurl.com/29qqk2


 ti pagano di meno se provi ad essere meno brusco.
Eh eh, forse vuole solo dimostrare di essere all'altezza
http://www.mat.uniroma3.it/membri/homepage.php?persona=17
 ;-)
Se poi è veramente la persona presentata nel link sopra ....
Povera Italia!  Capisco perché il livello universitario è caduto così 
in basso.


 >Laforgia ti ha spiegato come mai è preferibile NON mettercelo. Hai 
letto i suoi post?
No, grazie a K&R, i profeti preferisco evitarli... ;-)
Il cast puo' limitare il type check del compilatore e *non* va usato a 
stracazzo,
ma solo quando serve e a ragion veduta, ma quando serve, va usato.
Questo non lo decide LF (Logic Fake, componente "ab libitum" di ogni 
mondo possibile)
ma chi scrive il codice tenendo presente ovviamente le buone regole e 
gli eventuali
standard aziendali.
Nel caso della malloc (e simili), faccio una eccezione perche':
1. Ritorna un void*, che comunque e' *ANYTYPE* come gia' osservato e
   appunto *non* da' warnings qualsiasi sia il tipo di puntatore 
destinatario..
   quindi niente type check del compilatore ;-)
2. Per il C *non* e' un errore fare il recast esplicito ;-)
3. preferisco castare il ritorno della malloc perche' e' piu' facile leggere
    il codice e mi dice subito che tipo di oggetto ho allocato.
   Questo è comodo usando tools di ricerca, specie se si hanno pletore 
di files,
   ed è comodo usando tools di documentazione automatica, tipo doxygen.
   Con scrip automatici e' possibile discriminare le allocazioni 
relative agli oggetti
   che interessano molto velocemente, specie se si lavora si centinaia 
di files, sparsi
   per il mondo su server diversi....
   Cercare (MY_TYPE*)malloc e' una opzione molto piu' comoda che cercare
   malloc  e basta.  Te lo assicuro!
   (Ovvio che un LF qualsiasi non ci penserebbe, ma forse non sedovesse 
lavorare
     piu' di 10..15 files alla volta.... :-)
4. Inoltre, in qualche caso, il cast al tipo opportuno *salva* la vita 
ed aumenta
   il type check del compilatore.
  Se si lavora in tanti su un progetto complesso o si deve modificare 
manutenere
  codice, a volte ci sono degli oggetti globali da istanzare che possono 
cambiare
  tipo, ed e' bello avere un warning di avviso, almeno per controllare...
  (Un LF a caso anche qui non ci arriverebbe)
5. Il porting in C++ poi e' piu' facile....
  (Ovvio che LF non cia ha mai pensato)
 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  e' solo un *esempio* limitato tanto per puntualizzare!!!!!!!!
 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
   typedef struct ppp{ int pippo; }PP_T;
   typedef struct ccc{int pluto; int pippo; }CC_T;
    PP_T*   obj;
 
   extern  PP_T*   obj;
   ....................
   obj  =  malloc( sizeof(PP_T) );  /* No warning  */
   obj->pippo=10;
    Se un domani qualcuno per qualsiasi ragione cambia il tipo dell' 
oggetto obj e decide
   che e' di tipo CC_T;
    CC_T*   obj;
...............................
   obj  =  malloc(sizeof(PP_T));  /* --->NO Warning ! Bad size.... */
   obj->pippo=10;  /* Casino */
   obj  =  (PP_T*)malloc(sizeof(PP_T));  /* --->Warning: obj è CC_T !!!!  */
 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
E' un esempio, ma ti assicuro che roba del genere (un po meno ovvia) ne ho
vista tanta. Inutile dire che bisogna programmare bene: bisogna usare 
*quello*
che c'e' e farlo funzionare meglio.
brix

    obj  =  (PP_T*)malloc(sizeof(PP_T));  /* --->Warning: obj è CC_T !!!!
*/
[...]
Non va bene per i motivi noti (.h assente ???).
Meglio come avevo scritto all'inizio:
obj  =  malloc(sizeof *obj);
Ti avverte del .h mancante e non devi cambiare nulla.
--
Giorgio Silvestri
DSP/Embedded/Real Time OS   Software Engineer

   
Lo so anch'io !!!!!!!!!!!!! Era solo un esempio !!!!!!!!!!!!

"brix99luftballons" <brix99lu...@hotmail.invalid> ha scritto nel
messaggio news:Xeg5j.277$8j3...@tornado.fastwebnet.it...

No, non lo sai.
Rileggi il tuo post.
"Nel caso della malloc (e simili), faccio una eccezione perche': ..."
ecc. ecc.
Seguono i casi dal (1) al (5) che cercano di giustificarti del perchè
farestì così.


brix99luftballons ha scritto:

Esempio sbagliato: non era convincente. Ritenta :)
ciao
-- 
Cybertoldo
Per rispondermi via email, sostituisci moc.liamg con 
gmail.com

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

 files, sparsi
Questo posso capirlo. Non sarebbe più sensato usare una macro, tipo:
#define MALLOC(x) (((x))malloc(sizeof(x)))
altrimenti hai comunque il problema di dover ripetere due volte la 
stessa informazione (il tipo dell'oggetto) con rischi di errore. Inoltre 
questa macro avrebbe una traduzione naturale in un template C++.
E.

 Questo e' un estratto di codice *reale* .....
qui, piu' o meno tutti scriviamo "codice *reale*"...


?manu* ha scritto:

Infatti, in genere faccio cosi' :-).
Tieni presente che non si lavora solo sul propriocodice, ma anche su altro,
di altre aziende con altre convenzioni a cui ci si deve adeguare..
brix

 qui, piu' o meno tutti scriviamo "codice *reale*"...
Mi pare di no, qualcuno 'scrive' (se lo scrive) software didattico....
brix

 
http://c-faq.com/malloc/mallocnocast.html
E per la precisione "the compiler will notice that you're seemingly 
assigning an integer to a pointer".
A 64bit questo funziona? Da quel poco che so a 64bit sono i puntatori 
ma gli int rimangono a 32 bit. A 64bit malloc torna ancora un intero e 
si sono inventati la malloc64?

 Mi pare di no, qualcuno 'scrive' (se lo scrive) software didattico....
Affermazione piuttosto gratutita.


 qui, piu' o meno tutti scriviamo "codice *reale*"...
io solo codice intero, grazie.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 di altre aziende con altre convenzioni a cui ci si deve adeguare..
Ovviamente tu non rispondi del codice che scrivono gli altri! Mi pare 
che usando la macro la controindicazione del cast cada completamente e 
mantieni i vantaggi di cui parlavi.
E.

 ha scritto nel messaggio
news:LwC5j.1619$8j3....@tornado.fastwebnet.it...

Quale controindicazione cade ?
Siamo punto e capo. Anche integrando il .h relativo (mancante nell'esempio)
ci possono sempre essere problemi.
Potrebbe essere eliminato per sbaglio ecc.


 Potrebbe essere eliminato per sbaglio ecc.
che cosa potrebbe essere eliminato per sbaglio?
E.


Idem come sopra.



Il file .h ovvio. Cosa altro ? Se i file sono grandi ci si può
tranquillamente
dimenticare di includere qualcosa o di rimuoverlo dopo tanto tempo.
Questo perchè non si ha tutta la visione del file nella sua interezza.
Meglio non rischiare.


 ha scritto nel messaggio
news:UrD5j.141$Pa5...@nntpserver.swip.net...

Non so se si capisce: quando dico "eliminare" per sbaglio intendo dire
la riga che include <stdlib.h>.
#ifndef H_FILE_H
#define H_FILE_H
...
...
#include <stdlib.h>   /* <-- la riga che potrei eliminare per sbaglio se il
file è grande */
...
...
#define MALLOC(P)   ...
...
#endif


   
Carina ...

   
gratis e' meglio
brix

Davide Quack ha scritto:

Dipende dall' architettura: se il size pointer e int coincidono, funziona
tutto, ma e' sempre un errore...gli int possono essere anche a 64bit
si macchine a 64bit. Alcuni compilatori permettono di determinare
il size dell' int (16/32/64)  in modo da limitare lo spreco di memoria.
brix

   
Non ha senso nel contesto, la struttura e' dinamica, infatti......va 
riallocata secondo le esigenze ;-)
Ritenta sarai piu' fortunato!
Brix

 riallocata secondo le esigenze ;-)
Hai tagliato il mio post dove dico la stessa cosa, cioè
che è comunque sbagliato.


   
Colpa mia: tutti quei pointer in realta' sono mantenuti in strutture a 
parte e non
si perde nulla: solo che sforbiciando parti di software qua e la per 
esemplificare capita ...
ma non era quello il punto della discussione, anche se la nota e' 
giustificata .
brix


Anche a me non piacciono le modalita' di espressione di Laforgia, ma
tu Giovanni sei in torto.
E' un dato di fatto che il cast sul ritorno della malloc e'
_SCONSIGLIATO_ ( dove sconsigliato != errato ).
Forse tu sei abituato a linguaggio con controllo forte sui tipi, ma il
C non lo e'. ( per questo le printf schiantano xD )
Daniele

 il C non lo e'. ( per questo le printf schiantano xD )
Ho cominciato a scrivere codice in PL/1 e sono passato al C nel '84 
(Lattice C per MS-DOS).  Se ti sembra che abbia fatto l'abitudine ai 
linguaggi tipizzati ..... :-)


 _SCONSIGLIATO_ ( dove sconsigliato != errato ).
Se non ti piacciono le modalità  di espressione di Laforgia,  non imitarlo.
Dato per scontato che anche per me il cast sul valore di ritorno della 
malloc è *sconsigliato*, non mi permetto di fare l'  equiparazione 
(indimostrabile)  tra sconsigliato e errato.
Questo atteggiamento è  molto diffuso in certi ambienti di 
programmatori, spesso ma non sempre  neofiti, ma secondo me riflette una 
  visione personale, miope ed integralista dell'  uso dei linguaggi di 
programmazione. La storia della computer science ne è piena.
Al  di là  delle opinioni (anche se condivisibili e supportate da solide 
argomentazioni),  resta il *fatto*  che il linguaggio permette certi 
costrutti e  quindi non si capisce l'  "errore"  dove sarebbe.
Di sicuro non è  errore della grammatica e sintassi del linguaggio e 
neanche della semantica. Si tratta di  un uso che una lunga esperienza 
rende sconsigliabile.  Tutto qui. Di  sicuro non è  equivalente ad 
assegnare valori tramite un puntatore non inizializzato.  Quello s'  che 
è  un errore perché  viola la semantica del linguaggio.
Alla fin fine,  io continuerò  a  non usare il cast ma mi ha interessato 
leggere le argomentazioni di chi trova più  utile farlo.
That's all. Non credo di dover dimostrare niente a nessuno e  non me ne 
viene niente a pretendere di convincere gli altri  che solo il mio uso è 
  quello giusto.
Giorgio

 wrote:

Leggila bene l'"equiparazione" che ho scritto. Sconsigliato != errato
( sconsigliato DIVERSO DA errato ).
Questo perche' se ne sconsiglia l'uso per tutti i vari motivi
affrontati in questo thread ( e che sarebbe ridondante ripetere ) ma
non e' errato perche' svariati compilatori lo permettono.
Inoltre basta dare dei neofiti a tutti quelli che si incontra solo per
dimostrare le proprie argomentazioni.
Daniele

 ( sconsigliato DIVERSO DA errato ).
...
Hai ragione. Ti devo delle scuse: non ho visto il !  e  ho equivocato.
Giorgio