Mi aspetto un errore di collegamento perché sarà in conflitto con l'implementazione standard esistente.
L'aspettativa non è corretta: la maggior parte delle implementazioni di libc UNIX supporta l'utilizzo di altri malloc. A tal fine, inseriscono malloc
, realloc
, free
ecc. In un file oggetto separato o in un file oggetto.
Il linker è quindi libero di sostituire malloc.o
in libc.a
con la vostra implementazione. È possibile leggere l'algoritmo utilizzato dal linker here. Una volta compreso l'algoritmo, dovrebbe essere chiaro il motivo per cui il collegamento del proprio malloc
e free
non causa un errore di collegamento.
Le librerie condivise UNIX sono progettate esplicitamente per emulare le librerie di archivi, quindi mentre i dettagli del perché non si ottiene un errore di collegamento quando si collega con libc.so
sono diversi, lo spirito è lo stesso.
Tuttavia, non hai finito. Il collegamento di qualsiasi programma moderatamente complicato con la tua implementazione sarà probabilmente in crash, perché quando si sostituisce malloc
, è necessario implementare realloc
e probabilmente calloc
e memalign
e posix_memalign
. Altrimenti, otterrai una combinazione di implementazioni e quando qualcuno passa il puntatore realloc
al tuo free
, le cose probabilmente esploderanno.
fonte
2013-06-17 00:51:20
Penso che sia considerata prassi accettabile per "sovrascrivere" le routine in questo modo utilizzando l'ordine dei collegamenti in modo che non vi sia alcun errore/avviso di collegamento per impostazione predefinita. –
Collega, ma esegue effettivamente il tuo codice? GCC ha malloc e builtins gratuiti che potrebbero scavalcare i tuoi. – idoby
@IBY: buon punto - OP potrebbe aver bisogno di '-fno-builtin' o' -fno-builtin-malloc -fno-builtin-free' per assicurarsi che le sue routine vengano chiamate. –