Newsgroup: it.comp.lang.c
Titolo: settare echo

Nel seguente ( semplicissimo ) codice come faccio ad ottenere come echo dei
caratteri '*' per quanto riguarda l'immissione della password ???
Ho pensato ad un getche ( o getch ?!? ) dentro ad un ciclo che va poi a
riempire un array che comporrà la stringa ma mi sembra un metodo poco
efficente ( almeno per me che vengo da java )...
#include <stdio.h>
#include <string.h>
char login[33]="";
char password[8]="";
int com=0;
char comLog[]="pippo";
char comPw[]="pluto";
int chkString(char x[], int y);
int main (void)
{
 printf("======================\n");
 printf(" Password check V0.01\n");
 printf("======================\n\n\n");
 printf("      Login : ");
 scanf("%33s", &login);
 printf("\n   Password : ");
 scanf("%8s", &password);
 com=chkString(login,33);
 if (com!=0) return 0;
 chkString(password,8);
 if (com!=0) return 0;
 if ((strcmp(login, comLog)==0) && (strcmp(password, comPw)==0))
  printf("Login correct %s",login);
 else
  printf("\n\nAccess Denyed");
 return 0;
}
int chkString(char x[], int y)
{
 if (strlen(x)>y)
 {
  printf("\n\nAccess Denyed");
  return 1;
 }
 else
 return 0;
}
Grazie

efficente ( almeno per me che vengo da java )...
Non esiste un metodo portabile per fare cio' che chiedi, in quanto
bisognerebbe avere il controllo della tastiera, il che va oltre le
possibilita' dello standard del linguaggio.
Le funzioni getch()/getche() non sono portabili e dipendono dalla tua
particolare implementazione.

Ciao!
Io a scuola per "proteggere i miei capolavori", ;-)) ho fatto cosi':
Senza la login, ma basta aggiungerla=)
Sicuramente qualcuno ha fatto di meglio, pero' dal piccolo della mia
conoscienza in c ho deciso di postarlo;-))))
La password in questo caso č passout....
#include <stdio.h>
#include <conio.h>
#include <string.h>
#include <stdlib.h>
main()
{
 char p[8];
 printf("Inserisci la password:")
 for(i=1;i<=7;i++)
 {
  p[i]=getch();
  printf("*");
 }
 if(p[1]=='p' && p[2]=='a' && p[3]=='s' && p[4]=='s' && p[5]=='o' &&
p[6=='u' && p[7]=='t')
 {
    (*corpo del programma*)
 }
else
{
 printf("Password scorretta!");
}
--
 Byez By Roby "Offear" '82
 Visit my personal Home-Page:
 
http://surf.to/HPOffear
 And Sign My Guestbook!

 Io a scuola per "proteggere i miei capolavori", ;-)) ho fatto cosi':
Solo due osservazioni: il sorgente che hai mandato è pieno di piccoli
errori (basta provare a compilarlo) ed inoltre utilizza la funzione
getch() che non fa parte dello standard.
EMG

p[6=='u' && p[7]=='t')
ti sembra un modo efficiente di confrontare due stringhe ???


ICQ #34602650

 ti sembra un modo efficiente di confrontare due stringhe ???
Efficiente non lo so ma sicuramente è scomodo da scrivere. :-)
EMG

 p[6=='u' && p[7]=='t')
[...]
Non mi sembra una grande idea, almeno si dovrebbe bufferizzare tutto
l'input e poi confrontarlo con la password; come hai fatto tu anche la
password "passoutPIPPO" funziona: potrebbe non essere un problema, ma
non e' proprio il massimo...
Ciao, Luca.
P.S. Adesso che ci penso, anche la versione di Linux che ho installato
(Mandrake 5.3 senza KDE) ha lo stesso problema con la password...
-- 
*******************************************************
       "Dio non e' morto.
        E' vivo e sta lavorando
        a un progetto
        meno ambizioso"
				    graffito anonimo
  Reply to 
bia...@maganet.net
*******************************************************

 (Mandrake 5.3 senza KDE) ha lo stesso problema con la password...
Cmq prendetela come volonta' di imparare a programmare sempre meglio;-)))))


 getch() che non fa parte dello standard.
Per i piccoli errori ho gia' spiegato il perchè(copia e incolla
frettoloso...)
Io utilizzo il getch perchè a scuola utilizziamo il c della borland...
Gia' che ci sono...mi potreste fare una panoramica generale dell diversita'
ecc.
E che cos'è DGJJP o qualcosa del genere?
Mille thanx;-)


 Oddio... davvero confronti così due stringhe? :-)
Lo so che c'è la strcmp, ma avevo usato questo metodo perchè non accettava
il confonto tra l'array e la stringa...pero' non ricordo esattamente perchè
avevo fatto cosi'=))))
Se qualcuno conosce un metodo migliore, e sicuramente c'è, lo potrebbe
gentilmente postare?
Grazie;-)


il ciclo;-)))
Scusami, ma se p e' lungo 8 caratteri, perche' non ne puoi inserire
piu' di 7 ?

avevo fatto cosi'=))))
if (strcmp(p, "passout") == 0) ...
e' il confronto corretto...

E che cos'è DGJJP o qualcosa del genere?
E' il porting per DOS del compilatore GNU C.

valore 0 che funge da simbolo terminale.
Ma lui non usa una stringa. Usa un vettore di caratteri, e nella posizione
zero ci puo' mettere qualsiasi cosa (o nulla). Cosi' come non deve mettere
lo zero alla fine, se non usa strcmp e le altre funzioni di string.h
Marco

 E che cos'è DGJJP o qualcosa del genere?
DJGPP è il porting per DOS del compilatore GCC della GNU.
EMG

lo zero alla fine, se non usa strcmp e le altre funzioni di string.h
Secondo me e' un utilizzo distorto dei vettori di caratteri.

 lo zero alla fine, se non usa strcmp e le altre funzioni di string.h
Anche questo non è vero.
Il vettore contiene 8 caratteri, ma supponi che la password sia più
corta di 8 caratteri. Come fai a sapere dove finiscono i dati
significativi?


 avevo fatto cosi'=))))
Beh, ma perchè ti ostini a non usare le stringhe quando gli oggetti che
utilizzi sono a tutti gli effetti delle stringhe? 



Direi sempre inelegante.
Il C permette tante belle cosine, a volte molto ineleganti. E' bello anche e
sopratutto per questo.
Marco

significativi?
Nel programma lui legge i caratteri e li mette in posizione da 1 a 8 nel
vettore. Non ci sono scritture in zone di memoria non allocate, dunque va
tutto bene.
Ricordate che il C nasce proprio per dare liberta' al programmatore. Senno'
oggi scriveremmo tutti in Cobol.
Marco

Ovvio che nemmeno io lo farei, ma il C non lo vieta.
Cerchiamo di intenderci.
Il giudizio di correttezza di un determinato programma e' influenzato
dal modo in cui le specifiche del programma vengono soddisfatte.
D'accordo, il C non vieta di utilizzare gli array di caratteri a quel
modo, ma se la richiesta da parte del programma e' quella di una
stringa di caratteri all'utente, la cosa va fatta in modo corretto.
Ovvero salvando i dati richiesti nel formato stringa supportato dal C.
Che senso ha salvare i dati in un vettore di caratteri che parte da 1
nella numerazione degli elementi, se poi non posso confrontarlo in
modo corretto ?
Ammetterai che il modo di confrontare una password carattere per
carattere non e' proprio corretto, non solo "poco elegante".

 Ricordate che il C nasce proprio per dare liberta' al programmatore. 
C'è libertà e libertà. 


 piu' di 7 ?
Il ciclo for va da 1 a 7 compresi, quindi legge sette caratteri. Forse
non gli piaceva il fatto che il primo elemento di un array ha indice 0


 
Si chiama DJGPP ed e' il compilatore C del gnu per Dos
Ciao, Luca.


oggi scriveremmo tutti in Cobol.
Il C non nasce per questo motivo !
Tant'e' vero che tante di quelle liberta' che il programmatore aveva
sono state riviste nel moderno C++, rendendolo un linguaggio piu'
sicuro e robusto.
Oggi, poi, il Cobol, a dispetto delle apparenze, e' usato moltissimo
;)

carattere non e' proprio corretto, non solo "poco elegante".
Indicami la pagina dello standard ansi dove si afferma che e' scorretto.
Secondo te i controlli sulle password si fanno solo con strcmp?
Marco

"comportarsi altrimenti".
Tu dici?
Marco

;)
Poveracci... non li invidio proprio.. ;-)

utilizzato.
Io credo che ci sia un fraintendimento di fondo nei nostri rispettivi
modi di affrontare la questione : io parlo di scorrettezza
PROGETTUALE, mentre tu parli di scorrettezza FUNZIONALE.
Che il programma cosi' scritto funzioni puo' anche essere vero, non ho
mai detto che non funziona (anche perche' non l'ho compilato), ma e'
evidente e credo che tu sia d'accordo che dal punto di vista della
progettazione non e' corretto.
Cioe' quello che voglio dire, spiegandomi piu' chiaramente, e che se
io avessi compiuto la manutenzione di quel codice, l'avrei certamente
modificato in meglio e questo processo per me si intende come una
"correzione".
Ovviamente, poi, dal punto di vista funzionale, puo' fare la
stessissima cosa.

Poveracci... non li invidio proprio.. ;-)
Perche' ? 
Lo conosci il COBOL ??
E' facile e, tra l'altro, prova a scrivere un gestionale in C.

 Secondo me e' un utilizzo distorto dei vettori di caratteri.
Forse ho capito male io ma ritengo che l'utilizzo di array di caratteri
come tali (quindi senza il '\0' finale) e come stringhe siano due
tecniche diverse ed altrettanto corrette.
EMG

Perfettamente d'accordo.

E' facile e, tra l'altro, prova a scrivere un gestionale in C.
Mille volte meglio. Anche perche' oggi mi verrebbe piu' semplice, con tutte
le librerie create nel corso di anni. No, guarda. Preferisco anche il Basic
al cobol...

 e, tra l'altro, prova a scrivere un gestionale in C.
Su questo sono d'accordo. Meglio scegliere uno strumento piů moderno del
COBOL e piů adeguato del C.
EMG

 Tu dici?
Eh, dico si.
Finchè si tratta di giocare con il linguaggio posso fare le cose più
sporche e senza senso. Quando invece si tratta di scrivere un programma
le cose cambiano decisamente. Prendendo l'esempio specifico, se io uso i
vettori a partire dal secondo elemento senza una ragione plausibile,
ottengo un risultato carino: il nome del vettore rappresenta in un
lvalue non modificabile il puntatore al primo elemento del vettore, nel
caso riportato invece è un puntatore ad un dato insignificante. Siccome
in C si fa spesso uso dei puntatori e della loro aritmetica, la volta
successiva che metto le mani su quel programma mi devo *ricordare* che
quel vettore non punta ai dati ma all'elemento precedente (o forse due,
tre o quindici elementi prima dei dati interessanti, perchè il C da la
massima libertà al programmatore, giusto?). Se poi qualcun'altro deve
mettere le mani sul mio programma devo comprare un ombrello per pararmi
dagli accidenti (sia dei programmatori, sia degli utilizzatori per i bug
che costringo ad introdurre con il mio modo di programmare scorretto e
imprevedibile).
La libertà del C non va certo intesa in questo senso. Tra l'altro questa
storia dei vettori nulla vieta possa essere applicata anche agli altri
linguaggi, che so... decidere che nel basic i vettori iniziano
dall'elemento 2... 
La "libertà" del C (che tradotta non è altro che l'assunzione che il
programmatore sa quello che sta facendo) si manifesta quando la sintassi
ti da strumenti non controllati per la gestione della memoria, per cui
il compilatore non controlla (ad esempio) dove vai a leggere e scrivere.


Eh, dico si.
E' evidente che non hai capito. Il "tu dici" era riferito al fatto che "io
non abbia idea..", non al fatto che conseguenze deleterie ci siano. Evitiamo
comunque inutili polemiche.
Chiariamo: non sto dicendo che utilizzare i vettori dal secondo elemento e'
cosa buona e giusta. Sto dicendo che non e' SBAGLIATO, ossia che il prg., se
non ci sono errori, realizza la funzione richiesta e dunque va bene. Ma
rimane scritto male.
Riguardo al discorso sulla manutenibilita' del codice ovviamente sono
d'accordo: non mi pare di aver mai affermato il contrario.
E ora due parole sugli standard, che mi sembra vengano un po' troppo
enfatizzati.
Su questo aspetto anzi gradirei avere il parere di qualcun'altro.
Presumo che molti partecipanti al ng di programmazione ci vivano, e non
siano solo hobbysti. L'hobbysta si puo' studiare tutti gli standard che
vuole, anzi fa bene a farlo. Per cui ora mi rivolgo ai programmatori.
A costoro chiederei di quanto in effetti si preoccupano di uno standard. E
per evitare flames chiarisco subito.
Se vi viene commissionato un lavoro per Win95 glielo realizzate in modalita'
console per rimanere fedeli allo standard ANSI?
Ma anche sotto DOS: mai utilizzato gotoxy? o textcolor?
Ovviamente mi riferisco a progetti piccoli, non mi riferisco a grossi
sistemi informatici. Ad esempio un semplice programma di fatturazione.
A ben guardare credo che nessuno dei prodotti commerciali rispetti appieno
lo standard. Semmai si cerca di scrivere codice il piu' possibile portabile,
evidenziando e isolando le parti dipendenti dall'architettura o
dall'implementazione. Altrimenti non si potrebbe fare nemmeno l'edit del
DOS, scrivendo in C ANSI.
Inoltre lo standard in se' non implica la portabilita'. A me una volta e'
capitato di dover mettere le mani su del codice scritto proprio in ANSI.
Quel codice compilato con un compilatore che rispetta l'ANSI su una macchina
diversa NON funzionava. Ovviamente il motivo era la diversa dimensione della
parola sulle due macchine, cosa che comportava overflow non previsti e
amenita' simili, oltre al fatto che lo standard non fa nessuna assunzione
sulla quantita' di memoria statica allocabile, per cui su linux posso
dichiarare char v[1048576] e su DOS no.
Insomma, scrivere codice standard e portbile che sia anche vendibile mi
sembra abbastanza difficile. Dalle vostre esperienze lavorative cosa vi
risulta?
Saluti,
Marco

 risulta?
E' fondamentale rispettare lo standard.  Se no, quando arrivera' la
prossima versione del tuo compilatore (non parlo nemmeno di portare
l'applicazione in un altro ambiente) cominceranno a saltar fuori core
dumps da tutte le parti e si capira' il perche' solo quando gli utenti
staranno per linciarti.
-- 
Maurizio Loreti                      
http://wwwcdf.pd.infn.it/~loreti/mlo.html
Un. of Padova, Dept. of Physics - Padova, Italy          
lor...@padova.infn.it

 dichiarare char v[1048576] e su DOS no.
Infatti è un altro elemento di non portabilità che ho ben presente.
EMG

 sulla quantita' di memoria statica allocabile, 
La memoria è una caratteristica del sistema. Se lo standard facesse una
tale assunzione, vorrebbe dire che si preoccupa di standardizzare i
sistemi e non il linguaggio. E infatti questo NON è un argomento
contemplato dallo standard (giustamente, visto che pretendere un
programma che richiede un certo quantitativo di ram giri su una macchina
che non ha questo quantitativo non è standardizzare, ma fare miracoli).


staranno per linciarti.
E lo so... da quando sono passato a 32 bit che devo ricompilare tutto il
lavoro fatto prima non ti dico le madonne. E meno male che ci avevo pensato
prima per minimizzare il lavoro di conversione (tutte le funzioni non
standard... OPS!! .. non portabili sono impacchettate, riscritte quelle il
grosso e' fatto).
Ma purtroppo mi e' capitato di dover convertire codice dove c'e' char
v[1048576] e portarlo sotto DOS a 16 bit. Come si fa in questo caso?
Marco
PS grazie a tutti per le risposte. E' un argomento molto interessante,
secondo me.

 staranno per linciarti.
Nei programmi "normali" (a parte nicchie come la tua) questo
semplicemente non è possibile, purtroppo.
EMG

 non e' portabile.
Va beh, difendiamo un po' anche lo standard: eccoti uno stralcio dalle
faq:
1.1:    Come decidere quale tipo intero utilizzare?
R:      Se si ha bisogno di valori elevati (sopra 32767 o sotto -32767)
usare i
        long. Altrimenti, se lo spazio è molto importante (se ci sono
array
        grandi o molte strutture), usare gli short. Altimenti usare gli
int.
Quindi nel primo caso puoi utilizzare int o short mentre nel secondo
long.
EMG

 Infatti и un altro elemento di non portabilitа che ho ben presente.
Quella dichiarazione и fatta assumendo che la macchina abbia a
disposizione uno stack di almeno un mega. Ci sono macchine che non hanno
nemmeno un mega di ram. In questi termini anche questo programma non и
scritto in modo portabile. Il seguente invece:
char *v;
v = malloc(1048576L*sizeof(char));
if(v==NULL) {
printf("Non c'и abbastanza memoria");
exit(EXIT_FAILURE);
}
и perfettamente portabile. 


 v[1048576] e portarlo sotto DOS a 16 bit. Come si fa in questo caso?
Io non dichiarerei MAI un vettore statico di un mega, questo perchè lo
stack è molto limitato rispetto all'heap (è uno spreco immane) su gran
parte dei sistemi. Dimmi la ragione per cui non allochi il vettore
nell'heap, poi magari potrò darti una risposta.


 è perfettamente portabile.
Già, ma purtroppo chi usa i programmi ha il brutto difetto di volerli
funzionanti. Vai a dire al cliente che quel programma è "perfettamente
portabile" anche se tutto il suo output consiste in "Non c'è abbastanza
memoria"... :-))
EMG

 memoria"... :-))
Eh, ho capito! Ma se non c'è non c'è :-) Questo mica è un problema di
portabilità: è un problema che non dipende dalla piattaforma ma da una
condizione specifica, la "penuria" di risorse. 
Infatti questo è quello che non capisco: cosa vi aspettate da un
programma portabile? Che funzioni in tutte le condizioni?


 le condizioni?
  Portabilita` e` sviluppare su Solaris ed utilizzare su Vic 20. :)
	Alla prossima,
		Marco

nell'heap, poi magari potrò darti una risposta.
A prescindere dall'allocarlo su stack o heap, sotto dos a 16 bit in entrambi
i casi non ci entra. Come si risolve?
Marco

 programma portabile? Che funzioni in tutte le condizioni?
Assolutamente no. Solo che mi piacerebbe vedere una certa coerenza nel
discorso. Se lo Standard si prende la responsabilità di dichiarare
standard un aspetto del linguaggio, ci deve essere qualche altra
differenza con uno non standard che non la sola citazione nel documento
ANSI/ISO. Per lo meno mi aspetto che sia effettivamente portabile e non
portabile con riserve. Altrimenti a cosa serve standardizzare?
EMG

   Portabilita` e` sviluppare su Solaris ed utilizzare su Vic 20. :)
Si, non pretendo tanto ma il senso è quello. A me sembra che la
portabilità attuale sia molto addomesticata e riservata ai sistemi con
più successo di mercato. Insomma, l'informatica perde sempre più le
caratteristiche di una scienza per diventare semplicemente un business.
Infatti quanti dei "nuovi" concetti di cui si sente parlare oggi servono
solo per far vendere di più?
EMG

 a girare, e quindi si scrivono programmi non del tutto portabili.
Sono d'accordo.
EMG

portabile con riserve. Altrimenti a cosa serve standardizzare?
Chiarisco il mio pensiero. Il seguente codice:
long *ptr;
long i;
ptr = malloc(1000000L*sizeof(long));
if(ptr==NULL) {
    printf("Memoria insufficiente");
    exit(EXIT_FAILURE);
}
for(i=0; i<1000000L; i++) {
    ptr[i]=i;
}
Io sostengo che questo programma è scritto in modo portabile e *funziona* in
tutte le condizioni. Se io faccio girare il programma in un vecchio 286 non
riuscirebbe ad allocare il blocco e non avrei il risultato auspicato, ma
*non* *è* *vero* che per questo il programma non funziona in un 286. Il
programma *è* portabile su un 286. Il controllo sul puntatore e l'uscita
condizionata è parte integrante del programma ed è esattamente quello che io
(programmatore) voglio fare nel caso in cui non riesca ad allocare la
memoria.
Questi aspetti non sono volutamente contemplati dallo standard ANSI/ISO per
la semplice ragione che non riguardano il linguaggio. Se lo standard volesse
entrare in merito dovrebbe a quel punto definire che un programma non può
allocare più di X byte di memoria (dove X è un numero molto basso, visto il
largo ventaglio di sistemi su cui è applicato il C) oppure dire che i
sistemi devono mettere a disposizione Y byte di memoria. Cioè, dovrebbe
entrare in merito a delle questioni che c'entrano nulla con la definizione
del linguaggio.
Lo standard garantisce che il programma è portabile dal punto di vista del
linguaggio, non garantisce certo che le tue implementazioni abbiano lo
stesso esito su tutti i sistemi. Questo è ovviamente impossibile. Se la tua
implementazione ha bisogno (per i cavoli suoi) di allocare X mega di ram e
la macchina non ha X mega di ram, il programma non può portare a termine il
suo compito anche se, torno a ripetere, non significa che il programma non
funzioni.

 far vendere di più?
  Questo e` indubbio e, per quanto deprecabile sotto molti aspetti,
inevitabile. E` paradossale che uno standard, tendenzialmente volto ad
omogeneizzare le caratteristiche dei prodotti, venga usato invece per
differenziarne le prestazioni. E` il *mercato* che vuole questo.
	Alla prossima,
		Marco

 esserlo la standard malloc()?
Perchè non è vero che se la macchina non dispone di memoria malloc non
funziona; malloc restituisce NULL.


 		Marco
Secondo me il fatto di sviluppare su Solaris e utilizzare su Vic20 piu` 
cheun
problema di portabilita` del codice e` un problema di scarsa attenzione al
ciclo di vita del software cosi` come definito dall'ingegneria del software.
Cioe` quando si deve scrivere un programma sarebbe bene fare una raccolta
dei requisiti, una analisi dei requisiti e uno studio di fattibilita` (da
cui potrebbe anche risultare che i requisiti sono irrealizzabili!). 
Se i requisiti prevedono espressamente che il programma deve funzionare sia
su Solaris che su Vic20 puo` darsi che uno studio di fattibilita` 
dimostri che il programma non puo` essere realizzato ne' seguendo gli
standard
ne' in altri modi (dipende da cosa deve fare il programma).
Marco Guidi

 ptr = malloc(1000000L*sizeof(long));
Probabilmente non avrebbero dovuto inserire la malloc() tra le funzioni
standard. Altrimenti perché non inserire anche funzioni per la gestione
della GUI che è oggi una cosa (almeno per me) essenziale nella
realizzazione di qualsiasi prodotto? Infatti con lo stesso identico
ragionamento che hai fatto si può dire che un sistema che non disponga
di GUI non può certo far girare quel programma che rimarrebbe comunque
standard e portabile (basta visualizzare un messaggio tipo: "This
program requires Microsoft Windows"). Non sei d'accordo?
EMG

 definito dall'ingegneria del software.
  Ovviamente, era un /joke/. ;)
	Alla prossima,
		Marco


Volevo solo dire che non mi sembra che tutti i problemi elencati siano
problemi relativi alla portabilita` del codice in senso stretto.
Marco Guidi.

Enrico Maria Giordano wrote:

Diciamo che il ragionamento andrebbe "rigirato". Potrebbe essere
definito uno standard anche per la grafica, quindi una libreria di
funzioni per la grafica (in fondo Java l'ha fatto, in qualche modo).
Questo in effetti potrebbe avvenire, anche se lo stnadard C non
considera "storicamente" questo aspetto per scelta progettuale.
Direi però che definire uno standard per la grafica non è proprio uguale
a definire uno standard per la gestione della memoria. 


 problemi relativi alla portabilita` del codice in senso stretto.
E' quello che sostengo io, nella sostanza.


   Ovviamente, era un /joke/. ;)
Si, era un joke... ma non è che fosse una questione del tutto fuori dal
seminato. In linea di principio le problematiche sono quelle.


 dal seminato. In linea di principio le problematiche sono quelle.
  Vallo a spiegare a quelli della Sun, che veramente pretendono di
sviluppare su Solaris quello che poi girera` su una lavatrice. :)
	Alla prossima,
		Marco

 non e' portabile.
c'e' ben di peggio, ad esempio:
strlen(NULL)  
a seconda del compilatore utilizzato da' come risultato 0 oppure l'errore 
Segmentation Fault. 
Sapendolo la soluzione e' che le stringhe non vanno annullate con NULL
ma con una stringa vuota "" o '\0'. Anche se questo metodo comporta
il non poter utilizzare if(str==NULL) ma un piu' pesante
if(strcmp(str, "") ==0)    o   if(str[0] == '\0')  
O ancora realizzare delle funzioni
(magari inline) tipo:
int new_strlen(char *s)
{
    long i=0;
    char *c;
    if(s!=NULL) 
	for(c=s; *c!='\0'; c++, i++);
    return i;
} 
e questo per tutte le funzioni che trattano stringhe!!!.
Questo piccolo problema mi ha costretto una volta 
a modificare pesantemente un programma scritto
"tentando" di essere portabile (per quanto possibile).
E sarebbe secondo me il caso di scriverlo grosso
come una casa negli standard.
Per quanto riguarda la polemica (non so come
altro descriverla) riguardante la possibilita'
o l'impossibilita' di realizzare progetti importanti
mantenendosi negli standard e portabile. 
Vorrei far osservare che ci sono parecchi 
software prodotti vedi gnu gcc e simili
funzionanti su diverse macchine e SO.
Anche il software che mi ha creato quei problemi
(gestione di un apparato sperimentale di fisica
nucleare) e' stato compilato con successo su
diverse macchine da PC a workstation Unix
con successo.
                                       Andrea Zaghi

 con successo.
Immagino che funzioni rigorosamente in console-mode. Ma dico, non vi
sembra un po' arretrato uno standard che ancora oggi considera non degna
d'attenzione la problematica dell'interattività, del rapporto tra utenti
e programmi?
EMG

 (magari inline) tipo:
Se proprio uno considera giusto lo 0 come lunghezza di una stringa NULL
(cosa che non condivido in quanto per me una stringa NULL è una
non-stringa quindi non ha senso valutare la lunghezza, comunque è
opinione personale) io farei qualcosa del tipo:
len = (str==NULL?0:strlen(str));
Fermo restando che, per quello che è il mio stile di programmazione, non
arriverei al punto di valutare la lunghezza di una stringa NULL (o
comunque non passerei oltre facendo finta che sia zero). Per me un
puntatore a NULL è un puntatore non valido (come nella semantica del
linguaggio) e come tale lo considero.


hhmmm.... questa risposta e' in contraddizione con quella di Marco (Sarti)
subito sotto.
Cioe' le FAQ dicono che quel codice NON e' standard, Marco dice di si.
Chi ha ragione?
Marco


Bhe, ma povero cliente... Se su tutte le macchine gli esce quel messaggio
che gliene frega che è perfettamente portabile? :-) A questo punto è meglio
che funzioni da qualche parte e da altre no, senza mantenere la
portabilità...
San Vegeta

 Marco
Alla precedente... :-)
San Vegeta

p[6=='u' && p[7]=='t')
Pero` se ci pensate in un eseguibile scritto cosi` (a parte l'indice 0/1) la
password non č direttamente leggibile nel codice (grep "passout" non dovrebbe
trovarla), invece se scrivere char *passw="passout"...
_mirko_
--
Knowledge is power.
"ciucciati.il.calzino" is antispam.

 trovarla), invece se scrivere char *passw="passout"...
E' vero. Stavo pensando la stessa cosa in quanto tanto tempo fa ebbi un
problema analogo.
EMG

 trovarla), invece se scrivere char *passw="passout"...
Ho dei dubbi che si possa fare una grep su un eseguibile, ma anche se si
potesse fare, si presuppone che chi fa la grep conosca gia' la
password....
-- 
*******************************************************
       "Dio non e' morto.
        E' vivo e sta lavorando
        a un progetto
        meno ambizioso"
				    graffito anonimo
  Reply to 
bia...@maganet.net
*******************************************************

 printlines - 7 3
       strings  -  print  the  strings of printable characters in
       files
Ciao ciao,
Andrea
-- 
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and 
 the Ugly)."
(by Matt Welsh)

 semplicemente non è possibile, purtroppo.
Definire "programma normale", prego ... :-/
No, la questione e' differente: DEVI acquistare la mentalita' di chi
vuole rispettare lo standard.  Se non sei abituato, non lo fai; e, se
non lo fai, prima o poi ti puoi trovare a malpartito.  (Se abiti in un
paese con traffico quasi inesistente, perche' non prendere l'abitudine
di guidare sulla sinistra?  Tanto...)
"Nicchie" come queste, BTW, sono la norma nel mondo della ricerca.
-- 
Maurizio Loreti                      
http://wwwcdf.pd.infn.it/~loreti/mlo.html
Un. of Padova, Dept. of Physics - Padova, Italy          
lor...@padova.infn.it


Io sarei d'accordo sul fatto che si deve rispettare lo standard, ma mi sembra
che in alcuni casi, come quello dei sistemi real-time, questo sia praticamente
impossibile.
In questi sistemi e` fondamentale avere a disposizione "qualcosa" che
permetta di creare dei task che abbiano una priorita` e ai quali
possa essere allocata una quantita` predefinita di stack.
Non credo che lo standard ANSI/ISO preveda niente del genere ma se mi sbaglio
sarei lieto di avere informazioni in proposito. A me capita di utilizzare
il sistema operativo VxWorks che mette a disposizione la primitiva seguente
ma credo che non faccia parte di alcuno standard.
 
   long taskSpawn (char *name,
                 int priority,
                 int options,
                 int stackSize,
                 FUNCPTR entryPt,
                 long arg1,
                 long arg2,
                 long arg3,
                 long arg4,
                 long arg5,
                 long arg6,
                 long arg7,
                 long arg8,
                 long arg9,
                 long arg10);
Mi e` anche capitato di dover in qualche modo simulare in ambiente FreeBDS
un sistema a memoria condivisa. Il modo che e` stato scelto e` stato
l'uso del multithreading ma credo che anche questo non faccia parte di
alcuno standard, nemmeno dello standard POSIX che gia` offre qualcosa in
piu` rispetto allo standard ISO/ASCII.
Ritengo che, almeno in parte, un discorso simile si possa fare anche
per la programmazione di rete.
Immagino che un discorso simile valga anche per la realizzazione delle
interfacce grafiche, anche se non ho molte conoscenze in materia.
Se qualcuno conosce della documentazione in merito (cioe` relativa a cio`
che e` previsto dagli standard in relazione ai sistemi real-time e 
agli altri argomenti citati) sarei grato se postasse un messaggio
con i relativi riferimenti.
Marco Guidi.

 Marco Guidi.
 

 "Nicchie" come queste, BTW, sono la norma nel mondo della ricerca.
Infatti. Ma ammetterai che la ricerca stessa (pur essendo di gran lunga,
almeno per me, l'attività umana più importante) non può essere
considerata un settore a diffusione capillare (purtroppo).
EMG

 
Fico :-o ; questa non la sapevo. Non si finisce mai di imparare!
Ciao, Luca.
