Nullptr

smalldragon

il 11 dic 2017, 16:12

32 risposte

32 Risposte - Pagina 2

J
jj2007
Utente Attivo
Iscritto da
set, 2015
Messaggi:
112
Re: Nullptr
14 dic 2017, 18:31
jj2007 ha scritto:
oregon ha scritto:
In realtà non esiste alcun metodo affidabile.
Ma cosa fa il handler se lo stack tocca il fondo...?
Era una domanda retorica; se esp va sotto un certo livello, per es 93000h in Windows 7-64, SEH fallisce clamorosamente. Anche un handler ha bisogno di un po' di stack

Insomma, invece di fidarsi di qualche trucco per determinare se il puntatore è valido, meglio scrivere codice che non produce puntatori invalidi.
S
smalldragon
Molto attivo
Iscritto da
nov, 2008
Messaggi:
895
Re: Nullptr
14 dic 2017, 19:04
Anche se scrivi codice che non produce puntatori invalidi.
devi pur sempre verificare che essi siano validi o no ?
nel senso che o lo fai prima nel programma che produce i puntatori o lo fai dopo nel programma che riceve i puntatori
il controllo lo devi pur fare!
normalmente il controllo va fatto nel programma che produce i puntatori.
ma un controllo anche in chi li riceve non guasta mai!
meglio sprecare +-5 byte ed essere sicuri che risparmiarli e restare con il dubbio e magari ritrovarsi con errori di non facile identificazione.
J
jj2007
Utente Attivo
Iscritto da
set, 2015
Messaggi:
112
Re: Nullptr
14 dic 2017, 19:44
smalldragon ha scritto:
Anche se scrivi codice che non produce puntatori invalidi.
devi pur sempre verificare che essi siano validi o no ?
Non ho esperienza con Linux & Mac, ma in Windows devi verificare se un WinAPI call è riuscito.

Se no, devi informare lo user che il file non esiste o che HeapAlloc non è stato gentile ecc, ma MAI passeresti un puntatore invalido al codice seguente che ha bisogno di un puntatore valido. Anche semplicemente perché quel codice, come discusso sopra da me ed Oregon, non può verificare se un puntatore è valido. Ha solo la scelta fra "nullptr" (cioè: 0) e "qualcos'altro che potrebbe essere valido".
S
smalldragon
Molto attivo
Iscritto da
nov, 2008
Messaggi:
895
Re: Nullptr
15 dic 2017, 04:03
La gestione errori e un altra cosa e normale che se si verifica un errore di sistema avvisi l'user.
ma la verifica di un puntatore non è, quasi mai, necessaria per causa di un errore di sistema.
ma è sempre necessaria quando lo devi calcolare " a mano"
comunque per me il problema e stato risolto.
J
jj2007
Utente Attivo
Iscritto da
set, 2015
Messaggi:
112
Re: Nullptr
15 dic 2017, 08:56
smalldragon ha scritto:
la verifica di un puntatore ... è sempre necessaria quando lo devi calcolare " a mano"
Interessante. Ne hai un esempio?
S
smalldragon
Molto attivo
Iscritto da
nov, 2008
Messaggi:
895
Re: Nullptr
15 dic 2017, 10:57
Per esempio nei vettori, matrici, liste, alberi binari.
trattali in assembly e poi vedi se non ti serve sapere se un puntatore e null o meno!
J
jj2007
Utente Attivo
Iscritto da
set, 2015
Messaggi:
112
Re: Nullptr
15 dic 2017, 13:43
smalldragon ha scritto:
Per esempio nei vettori, matrici, liste, alberi binari.
trattali in assembly e poi vedi se non ti serve sapere se un puntatore e null o meno!
Se il codice è corretto, non vedo il problema. Lo faccio ogni giorno. Dammi un solo esempio dove nasce un puntatore invalido senza che il programmatore abbia introdotto un piccolo bug...
S
smalldragon
Molto attivo
Iscritto da
nov, 2008
Messaggi:
895
Re: Nullptr
15 dic 2017, 14:17
Senza bug mi vengolo in mente le seguenti situazioni:
l'ultimo elemento di una lista o un nuovo ramo di un albero binario dove i puntatori dell'ultimo record sono settati, giustamente a nullptr.
oppure nelle liste a doppio link non ordinate sequenzialmente.
dove o conservi il numero dell'ultimo elemento o dovrai scorrere finchè non trovi il nullptr al fine di eseguire l'operazione.
da non dimenticare che il pluricitato confronto serve appunto per evitare i bug o quantomeno a gestirli!
J
jj2007
Utente Attivo
Iscritto da
set, 2015
Messaggi:
112
Re: Nullptr
15 dic 2017, 15:04
smalldragon ha scritto:
il pluricitato confronto serve appunto per evitare i bug o quantomeno a gestirli!
Dobbiamo distinguere le seguenti situazioni:
1. A passa a B un ptr valido - OK.
2. A passa a B un nullptr:
a) è previsto, B sa cosa fare con un nullptr (.if esi ... .endif)
b) non è previsto, licenziare programmatore di A
3. A passa a B una roba che non è zero, forse punta a memoria valida, forse no: vedi 2.b)
S
smalldragon
Molto attivo
Iscritto da
nov, 2008
Messaggi:
895
Re: Nullptr
15 dic 2017, 16:23
L'esempio e calzante
alla fine che sia previsto o meno per prendere una decisione comunque lo devi fare!
J
jj2007
Utente Attivo
Iscritto da
set, 2015
Messaggi:
112
Re: Nullptr
15 dic 2017, 17:25
2.a)

include \masm32\MasmBasic\MasmBasic.inc ; download
S
smalldragon
Molto attivo
Iscritto da
nov, 2008
Messaggi:
895
Re: Nullptr
15 dic 2017, 18:11
Mi dispiace ma l'esempio non è calzante perchè cosi azzeri semplicemente un registro.
Questo e il classico esempio di bug che fanno i novellini nella gestione delle stringhe!
e centra poco o nulla con quello di cui stavamo parlando.
di solito i puntatori sono presi dallo stack oppure da valori di variabili
e quasi sempre vengono caricati in un registro ad esempio esi e vengono usati [reg]
ecco perchè in precedenza parlavo di
```
mov esi,Arg1 ; qui assegno l'indirizzo della variabile Arg1 che sta sullo stack.
cmp dword ptr [esi],0 ; qui piglio il valore dalla locazione di memoria di esi alias puntatore
je puntatore a nullptr
avrei anche potuto fare
cmp dword ptr [Arg1],0
je puntatore a nullptr
ma è buona norma quando si ha a che fare con lo stack di passare prima per un registro. 
```
J
jj2007
Utente Attivo
Iscritto da
set, 2015
Messaggi:
112
Re: Nullptr
16 dic 2017, 02:51
smalldragon ha scritto:
Questo e il classico esempio di bug che fanno i novellini nella gestione delle stringhe!
No, è il caso 2a:
2. A passa a B un nullptr:
a) è previsto, B sa cosa fare con un nullptr (.if esi ... .endif)

Infatti, Inkey (e Print) sa cosa fare con uno zero: Lo tratta come se fosse una stringa di lunghezza zero. Nessun problema, quindi.

Ma nel momento quando passi un qualsiasi valore non-zero ad una routine come Inkey o Print, quest'ultima deve fidarsi che il valore è un puntatore valido; perché se ricevi un puntatore non-zero, non c'è modo affidabile per determinare se è valido o meno.
S
smalldragon
Molto attivo
Iscritto da
nov, 2008
Messaggi:
895
Re: Nullptr
16 dic 2017, 23:13
In teoria un sistema ci sarebbe per stabirlo per le proprie applicazioni.
il sistema sarebbe quello di farsi una tabella con l'inizio e la fine di ogni routine e della memoria allocata.
e poi verificare se il puntatore passato rientra in una di quelle elencate in tabella
se c'è allora ok altrimenti e invalido
ma in pratica non conviene sia per il tempo di elaborazione che per la memoria.
poi pensa se una strategia del genere venisse applicata ad ogni puntatore di routine di una applicazione media.
l'operatore diventerebbe matusalemme prima che l'applicazione terminasse.
J
jj2007
Utente Attivo
Iscritto da
set, 2015
Messaggi:
112
Re: Nullptr
17 dic 2017, 02:21
In teoria... ma scrivi giustamente che non conviene. In pratica, puntatori:
- o puntano nella sezione .data o data?,
- o vengono da HeapAlloc ecc.,
- o sono calcolati in base ad un puntatore iniziale ed un indice, tipo mov eax, [edi+8*ecx]

In un'applicazione che non ha dei gravi bug, un puntatore può essere valido o zero. Non c'è una terza categoria...

Se hai un'applicazione media, e un sospetto che c'è un bug ben nascosto: RichMasm ha l'opzione OPT_Debug 1:
```
include \masm32\include\masm32rt.inc	; OPT_Debug 1
.code
start:
  mov edi, alloc(20)		; un puntatore valido
  mov ecx, 42			; guai...
  rep stosb
  inkey "ok...?"
  exit
end start
```
Se premi un tasto vedendo "ok...?", appare un messaggio d'errore molto preciso:
```
## HEAP[NewMasm32.exe]:
## HEAP: Free Heap block 2861a0 modified at 2861d0 after it was freed
```

Devi accedere o registrarti per scrivere nel forum

32 risposte