Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Attenti a Poco F7: può essere il best buy del 2025. Recensione
Attenti a Poco F7: può essere il best buy del 2025. Recensione
Poco F7 5G, smartphone che punta molto sulle prestazioni grazie al processore Snapdragon 8s Gen 4 e a un display AMOLED da ben 6,83 pollici. La casa cinese mantiene la tradizione della serie F offrendo specifiche tecniche di alto livello a un prezzo competitivo, con una batteria generosissima da 6500 mAh e ricarica rapida a 90W che possono fare la differenza per gli utenti più esigenti.
Recensione Samsung Galaxy Z Fold7: un grande salto generazionale
Recensione Samsung Galaxy Z Fold7: un grande salto generazionale
Abbiamo provato per molti giorni il nuovo Z Fold7 di Samsung, un prodotto davvero interessante e costruito nei minimi dettagli. Rispetto al predecessore, cambiano parecchie cose, facendo un salto generazionale importante. Sarà lui il pieghevole di riferimento? Ecco la nostra recensione completa.
The Edge of Fate è Destiny 2.5. E questo è un problema
The Edge of Fate è Destiny 2.5. E questo è un problema
Bungie riesce a costruire una delle campagne più coinvolgenti della serie e introduce cambiamenti profondi al sistema di gioco, tra nuove stat e tier dell’equipaggiamento. Ma con risorse limitate e scelte discutibili, il vero salto evolutivo resta solo un’occasione mancata
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 04-02-2014, 14:59   #1
Oceans11
Senior Member
 
L'Avatar di Oceans11
 
Iscritto dal: Sep 2005
Città: Torino
Messaggi: 606
[C] confronto tra puntatori & ISO

Per esercizio, sto tentando di implementare le varie funzioni di string.h.
Ho dei problemi con memmove.
Partiamo da memcpy, caso particolare di memmove in cui i puntatori passati come parametro non puntano ad oggetti in memoria che si sovrappongono:

Codice:
void *memcpy(void *dest, const void *src, size_t n) {
    unsigned char *d = dest;
    const unsigned char *s = src;
    while (n--) {
        *d++ = *s++;
    }
    return dest;
}
codice non testato, anche se sembra abbastanza semplice. Qui l'unico dubbio è nell'uso di "unsigned": io l'ho usato, ma non saprei dire se va bene, se ci vuole "signed" e quali sono (se ci sono) differenze.

Memmove, invece, dovrebbe coprire anche il caso in cui gli oggetti sorgente e destinazione overlappano.
Dalla pagina di manuale:
Quote:
The memmove() function copies n bytes from memory area src to memory
area dest. The memory areas may overlap: copying takes place as
though
the bytes in src are first copied into a temporary array that
does not overlap src or dest, and the bytes are then copied from the
temporary array to dest.
Codice:
void *memmove(void *dest, const void *src, size_t n) {
	// dest < src, then copy from the beginning
		return memcpy(dest, src, n);
	}
	// otherwise copy from the end
	unsigned char *d = dest;
	const unsigned char *s = src;
	s += n;
	d += n;
	while (n--) {
		*--d = *--s;
	}
	return dest;
}
Leggendo in rete, trovo un riferimento ad un paragrafo dello standard (in realtà è un documento che si avvicina allo standard ISO/IEC 9899:TC2 WG14/N1124) che riporto per intero:
Quote:
6.5.8.5 When two pointers are compared, the result depends on the relative locations in the address space of the objects pointed to. If two pointers to object or incomplete types both point to the same object, or both point one past the last element of the same array object, they compare equal. If the objects pointed to are members of the same aggregate object, pointers to structure members declared later compare greater than pointers to members declared earlier in the structure, and pointers to array elements with larger subscript values compare greater than pointers to elements of the same array with lower subscript values. All pointers to members of the same union object compare equal. If the expression P points to an element of an array object and the expression Q points to the last element of the same array object, the pointer expression Q+1 compares greater than P. In all other cases, the behavior is undefined.
e qui nascono i problemi, per tutti i casi non citati (ossia oltre a puntatori allo stesso array, struct o union)
1) cosa si intende per "object"?
2) cosa significa "relative locations in the address space"
3) perchè non posso confrontare i 2 puntatori come 2 interi per verificare se le regioni si sovrappongono?
__________________
"Se proprio dovete piratare un prodotto, preferiamo che sia il nostro piuttosto che quello di qualcun altro." [Jeff Raikes]
"Pirating software? Choose Microsoft!"

Ultima modifica di Oceans11 : 04-02-2014 alle 19:12. Motivo: chiarimento
Oceans11 è offline   Rispondi citando il messaggio o parte di esso
Old 07-02-2014, 08:43   #2
sottovento
Senior Member
 
L'Avatar di sottovento
 
Iscritto dal: Nov 2005
Città: Texas
Messaggi: 1722
Quote:
Originariamente inviato da Oceans11 Guarda i messaggi

Codice:
void *memcpy(void *dest, const void *src, size_t n) {
    unsigned char *d = dest;
    const unsigned char *s = src;
    while (n--) {
        *d++ = *s++;
    }
    return dest;
}
E' corretta, ma si potrebbe ottimizzare. Ricordo che il problema era stato affrontato anni fa in questo forum. Ma immagino che il tuo problema non fosse quello di ottimizzare questo codice, giusto?

Quote:
Originariamente inviato da Oceans11 Guarda i messaggi
codice non testato, anche se sembra abbastanza semplice. Qui l'unico dubbio è nell'uso di "unsigned": io l'ho usato, ma non saprei dire se va bene, se ci vuole "signed" e quali sono (se ci sono) differenze.
Va benissimo, non preoccuparti. Devi preoccuparti dell'uso di "signed/unsigned" quando inavvertitamente potresti fare delle estensioni del segno e cambiare il risultato atteso.
per esempio: se leggi dalla memoria un byte alla volta e poi vuoi processare questo byte come un intero, allora potresti avere risultati ben diversi a seconda dell'uso di signed/unsigned, poiche' se il byte letto da memoria e', poniamo
byteVal=F8,
allora se fai
Codice:
int iVal = (int)byteVal;
unsigned int uVal = (unsignedbyteVal;
otterrai
iVal=-8
uVal=4294967288


Quote:
Originariamente inviato da Oceans11 Guarda i messaggi
e qui nascono i problemi, per tutti i casi non citati (ossia oltre a puntatori allo stesso array, struct o union)
1) cosa si intende per "object"?
2) cosa significa "relative locations in the address space"
3) perchè non posso confrontare i 2 puntatori come 2 interi per verificare se le regioni si sovrappongono?
Da quanto ho capito io, e' corretto ed il tuo codice lo e' altrettanto.
1) Oggetto sembra indicare, in questo contesto, qualsiasi tipo di dato strutturato;
2) significa che sei giovane . Con l'avvento delle MMU (una delle tante sigle, usata soprattutto per i processori Motorola, per indicare il "Memory Management Unit", vale a dire l'unita' di memoria virtuale) ogni processo ha a disposizione uno "spazio di indirizzamento virtuale" o piu' semplicemente "address space".
Address space e' piu' generico poiche' fa rientrare anche il caso dei processori che la MMU non ce l'hanno.
Detto semplicemente: quando assegni un valore ad un puntatore, esso e' valido nel tuo spazio di indirizzamento. In una specifica pero' devono parlare in maniera generica e formale.
3) Non preoccuparti, puoi confrontari. La specifica che hai riportato non dice che non puoi confrontarli, ma specifica dei casi in cui il confronto deve avere senso, lasciando indeterminati tutti gli altri casi.
Da quanto scritto nella specifica sappiamo che le strutture dovranno essere allocate in memoria in modo tale che gli elementi dichiarati prima abbiano indirizzo minore di quelli dichiarati dopo, che i vettori seguono piu' o meno lo stesso criterio, ...

A rigor di logica si potrebbe pensare ad un sistema in cui questo non e' valido, ma sarebbe un processore progettato apposta per far fallire il tuo codice. Per quanto riguarda la mia umile esperienza, non ho mai visto nulla del genere ma magari il contributo di qualcuno puo' portare un esempio reale.
__________________
In God we trust; all others bring data

Ultima modifica di sottovento : 07-02-2014 alle 08:46.
sottovento è offline   Rispondi citando il messaggio o parte di esso
Old 07-02-2014, 09:41   #3
Daniels118
Senior Member
 
L'Avatar di Daniels118
 
Iscritto dal: Jan 2014
Messaggi: 852
L'unica cosa che ci si avvicina è la gestione dello stack sui processori x86: le istruzioni di push non incrementano lo stack pointer ma lo decrementano, per cui gli elementi inseriti dopo hanno un indirizzo minore di quelli inseriti prima, ma parliamo di elementi appartenenti a strutture diverse, quindi siamo ancora conformi alla specifica.
Forse i processori giapponesi funzionano al contrario... scherzo!
Daniels118 è offline   Rispondi citando il messaggio o parte di esso
Old 07-02-2014, 10:30   #4
Oceans11
Senior Member
 
L'Avatar di Oceans11
 
Iscritto dal: Sep 2005
Città: Torino
Messaggi: 606
Quote:
Originariamente inviato da sottovento Guarda i messaggi
E' corretta, ma si potrebbe ottimizzare. Ricordo che il problema era stato affrontato anni fa in questo forum. Ma immagino che il tuo problema non fosse quello di ottimizzare questo codice, giusto?
Giustissimo, ho molte lacune da colmare prima di poter pensare all'ottimizzazione. Ad ogni modo farò una ricerca più approfondita qui sul forum

Quote:
Originariamente inviato da sottovento
Va benissimo, non preoccuparti. Devi preoccuparti dell'uso di "signed/unsigned" quando inavvertitamente potresti fare delle estensioni del segno e cambiare il risultato atteso.
per esempio: se leggi dalla memoria un byte alla volta e poi vuoi processare questo byte come un intero, allora potresti avere risultati ben diversi a seconda dell'uso di signed/unsigned, poiche' se il byte letto da memoria e', poniamo
byteVal=F8,
allora se fai
Codice:
int iVal = (int)byteVal;
unsigned int uVal = (unsignedbyteVal;
otterrai
iVal=-8
uVal=4294967288
Ok. Mi era venuto il dubbio perchè in alcune pagine di manuale c'è scritto esplicitamente come deve essere trattato il dato (e.g. memchr)



Quote:
Originariamente inviato da sottovento
Da quanto ho capito io, e' corretto ed il tuo codice lo e' altrettanto.
1) Oggetto sembra indicare, in questo contesto, qualsiasi tipo di dato strutturato;
2) significa che sei giovane . Con l'avvento delle MMU (una delle tante sigle, usata soprattutto per i processori Motorola, per indicare il "Memory Management Unit", vale a dire l'unita' di memoria virtuale) ogni processo ha a disposizione uno "spazio di indirizzamento virtuale" o piu' semplicemente "address space".
Address space e' piu' generico poiche' fa rientrare anche il caso dei processori che la MMU non ce l'hanno.
Detto semplicemente: quando assegni un valore ad un puntatore, esso e' valido nel tuo spazio di indirizzamento. In una specifica pero' devono parlare in maniera generica e formale.
3) Non preoccuparti, puoi confrontari. La specifica che hai riportato non dice che non puoi confrontarli, ma specifica dei casi in cui il confronto deve avere senso, lasciando indeterminati tutti gli altri casi.
Da quanto scritto nella specifica sappiamo che le strutture dovranno essere allocate in memoria in modo tale che gli elementi dichiarati prima abbiano indirizzo minore di quelli dichiarati dopo, che i vettori seguono piu' o meno lo stesso criterio, ...

A rigor di logica si potrebbe pensare ad un sistema in cui questo non e' valido, ma sarebbe un processore progettato apposta per far fallire il tuo codice. Per quanto riguarda la mia umile esperienza, non ho mai visto nulla del genere ma magari il contributo di qualcuno puo' portare un esempio reale.
Mi aiuti a chiarire il 3) punto? Ci sono sui casi in cui i puntatori appartengono allo stesso array/struct/union, tutto ha perfettamente senso.
Ma che succede nel caso confronto 2 puntatori a 2 oggetti diversi?
Behavior undefined sta per machine e compiler dependent?
Se in questo caso non sono interessato all'aritmetica dei puntatori, proprio in virtù dello spazio virtuale di indirizzamento (che dovrebbe darmi un livello maggiore di astrazione, uniformando la "vista" degli indirizzi in ram/cache/paging file etc) perchè dovrebbe essere indefinito il comportamento di un confronto tra entità che si potrebbero trattare come interi?

@Daniels: in effetti ci avevo sbadatamente pensato anche io allo stack che cresce verso il basso.
__________________
"Se proprio dovete piratare un prodotto, preferiamo che sia il nostro piuttosto che quello di qualcun altro." [Jeff Raikes]
"Pirating software? Choose Microsoft!"
Oceans11 è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Attenti a Poco F7: può essere il best buy del 2025. Recensione Attenti a Poco F7: può essere il best buy...
Recensione Samsung Galaxy Z Fold7: un grande salto generazionale Recensione Samsung Galaxy Z Fold7: un grande sal...
The Edge of Fate è Destiny 2.5. E questo è un problema The Edge of Fate è Destiny 2.5. E questo ...
Ryzen Threadripper 9980X e 9970X alla prova: AMD Zen 5 al massimo livello Ryzen Threadripper 9980X e 9970X alla prova: AMD...
Acer TravelMate P4 14: tanta sostanza per l'utente aziendale Acer TravelMate P4 14: tanta sostanza per l'uten...
TSMC produrrà a 2 nm anche in Ari...
Tesla vuole Musk a tutti i costi: propos...
Spotify aumenta i prezzi: da 10,99 a 11,...
Prezzi folli su AliExpress con Choice Da...
IA ed etica: Fastweb+Vodafone fra le pri...
Pannelli solari nuovi o riciclati? Quest...
Instagram cambia le regole per i Live: n...
Windows 11 SE addio: Microsoft stabilisc...
Kali Linux più facile su macOS gr...
È la fine per le antenne 5G? Al l...
WhatsApp, una taglia da 1 milione di dol...
Sembrava spacciato, poi una bici elettri...
Apple Watch Series 1 diventa obsoleto: a...
ho. Mobile, upgrade a 250 GB senza sovra...
Reddit non avrà post a pagamento,...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 01:26.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Served by www3v