Sto sempre da tapatalk.Le immagini io le vedo tranquillamente, credo sia un problema del tuo pc![:\](/forum/data/assets/smilies/mhhae.gif "Mhhae :\")
All'inizio le vedevo tranquillamente, ora no :/
Su Tapatalk c'è un'impostazione che non consente di visualizzare le immagini, prova a controllare tra i settaggiSi, avevo intuito.
Quando avrò bisogno di visionarle aprirò da browser, grazie
Non la trovo :/Su Tapatalk c'è un'impostazione che non consente di visualizzare le immagini, prova a controllare tra i settaggi
vai nella home di tapatalk (quindi fuori dal forum), clicca in alto a destra sui tre puntini-->impostazioni. Scorri fino a: preferenze di caricamento delle immagini e assicurati che sia tutto spuntato, controlla anche preferenze di caricamento con connessione lenta, non si sa mai
A me è tutto spuntato, ma le immagini non le vedo lo stesso. Alla fine basta aprire il menu in alto e andare su visualizzazione web per aprire la pagina nel browser
Una cosa da non fare mai e poi mai che secondo me andrebbe aggiunta alla lista è quella di scrivere programmi che fanno affidamento su undefined behavior perchè finchè si compila tutto senza ottimizzazioni si va piuttosto tranquilli, ma quando si compila con -O2 o -O3 si rischia che il compilatore cancelli porzioni di codice introducendo falle di sicurezza.
Ad esempio supponiamo di avere una variabile int chiamata "x" e di volere aggiungere a questa variabile un valore numerico, diciamo 1000, tuttavia vogliamo anche controllare che non avvenga nessun overflow, con un codice tipo "if (x+1000<x)".
Questo funzionerebbe (e funziona, senza ottimizzazioni) sulla stragrande maggioranza delle architetture dove gli overflow causano semplicemente un wrap around e quindi ci si ritrova con un risultato negativo e minore di x, ma per coprire tutti i casi lo standard C definisce l'integer overflow come undefined behavior.
A questo punto il compilatore è autorizzato ad assumere che una condizione come "if (x+1000<x)" sarà sempre falsa perchè nell'unico caso in cui è vera è autorizzato dallo standard a fare quello che vuole ed eliminare completamente l'if (e il blocco di codice da eseguire nel caso sia vero).
Un'esempio real life è tratto dal kernel di linux:
Visto che il puntatore tun è dereferenziato prima del !tun che controlla che non sia null il compilatore assume che il puntatore non sia null, perchè il dereferenziamento di un puntatore null è undefined behavior ed elimina completamente l'if, creando potenziali falle di sicurezza.
Qua lo ho spiegato molto alla svelta, traendo informazioni da questo articolo che consiglio di leggere per una spiegazione pi# precisa e completa http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf
Ad esempio supponiamo di avere una variabile int chiamata "x" e di volere aggiungere a questa variabile un valore numerico, diciamo 1000, tuttavia vogliamo anche controllare che non avvenga nessun overflow, con un codice tipo "if (x+1000<x)".
Questo funzionerebbe (e funziona, senza ottimizzazioni) sulla stragrande maggioranza delle architetture dove gli overflow causano semplicemente un wrap around e quindi ci si ritrova con un risultato negativo e minore di x, ma per coprire tutti i casi lo standard C definisce l'integer overflow come undefined behavior.
A questo punto il compilatore è autorizzato ad assumere che una condizione come "if (x+1000<x)" sarà sempre falsa perchè nell'unico caso in cui è vera è autorizzato dallo standard a fare quello che vuole ed eliminare completamente l'if (e il blocco di codice da eseguire nel caso sia vero).
Un'esempio real life è tratto dal kernel di linux:
Codice:
struct tun_struct *tun = ...;
struct sock *sk = tun->sk;
if
(!tun)
return POLLERR;
/* write to address based on tun */Visto che il puntatore tun è dereferenziato prima del !tun che controlla che non sia null il compilatore assume che il puntatore non sia null, perchè il dereferenziamento di un puntatore null è undefined behavior ed elimina completamente l'if, creando potenziali falle di sicurezza.
Qua lo ho spiegato molto alla svelta, traendo informazioni da questo articolo che consiglio di leggere per una spiegazione pi# precisa e completa http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf
Ce ne sarebbero anche altri...ma in questo periodo non ho tempo. Lo riprenderò in futuro.
3) Evitare di chiedere cosa evitare, è da principianti X'D
Ammettere di essere principianti magari, o comunque aver desiderio di imparare di più su un certo argomento, ti rende sicuramente una persona più responsabile. Avere (spesso) l'arroganza di conoscere tutto su un certo argomento porta a errori in egual misura.
Se non si sa qualcosa meglio chiedere che rimanere nel dubbio ed eventualmente fare errori che si protrarrebbero per chissà quanto, no?
Ammettere di essere principianti magari, o comunque aver desiderio di imparare di più su un certo argomento, ti rende sicuramente una persona più responsabile. Avere (spesso) l'arroganza di conoscere tutto su un certo argomento porta a errori in egual misura.
Se non si sa qualcosa meglio chiedere che rimanere nel dubbio ed eventualmente fare errori che si protrarrebbero per chissà quanto, no?
Hai interpretato male il messaggio, la mia era semplice ironia. Comunque, il tuo discorso non fa una piega.
Anche con la risata finale sì, purtroppo devo aver male interpretato.
Purtroppo l'internet è un brutto posto spesso, quindi conveniva fare un discorso generale comunque. DISCUSSIONI SIMILI
-
- 2
-
- 212