La stampa di puntatori nulli con% p è un comportamento indefinito?

È un comportamento indefinito stampare puntatori nulli con l'identificatore di %pconversione?

#include <stdio.h>

int main(void) {
    void *p = NULL;

    printf("%p", p);

    return 0;
}

La domanda si applica allo standard C e non alle implementazioni C.

Questo è uno di quegli strani casi d'angolo in cui siamo soggetti alle limitazioni della lingua inglese e alla struttura incoerente nello standard. Quindi, nella migliore delle ipotesi, posso fare una controargomentazione convincente, poiché è impossibile dimostrarlo :) ¹

Il codice nella domanda mostra un comportamento ben definito.

Poiché [7.1.4] è la base della domanda, iniziamo da lì:

Ognuna delle seguenti affermazioni si applica a meno che non sia diversamente specificato nelle descrizioni dettagliate che seguono: Se un argomento di una funzione ha un valore non valido ( come un valore al di fuori del dominio della funzione, o un puntatore al di fuori dello spazio degli indirizzi del programma, o un puntatore nullo , [... altri esempi ...] ) [...] il comportamento è indefinito. [... altre dichiarazioni ...]

Questo è un linguaggio goffo. Un'interpretazione è che gli elementi nell'elenco sono UB per tutte le funzioni di libreria, a meno che non vengano sovrascritti dalle singole descrizioni. Ma l'elenco inizia con "come", a indicare che è illustrativo, non esaustivo. Ad esempio, non menziona la corretta terminazione nulla delle stringhe (fondamentale per il comportamento di eg strcpy).

Quindi è chiaro che lo scopo / ambito di 7.1.4 è semplicemente che un "valore non valido" porta a UB ( se non diversamente specificato ). Dobbiamo guardare alla descrizione di ogni funzione per determinare cosa conta come un "valore non valido".

Esempio 1 - strcpy

[7.21.2.3] dice solo questo:

La strcpyfunzione copia la stringa a cui punta s2(incluso il carattere null di terminazione) nell'array a cui punta s1. Se la copia avviene tra oggetti che si sovrappongono, il comportamento è indefinito.

Non fa menzione esplicita di puntatori nulli, ma non fa nemmeno menzione di terminatori nulli. Invece, si deduce da "stringa puntata da s2" che gli unici valori validi sono le stringhe (cioè i puntatori a matrici di caratteri con terminazione null).

In effetti, questo modello può essere visto in tutte le descrizioni individuali. Alcuni altri esempi:

• [7.6.4.1 (fenv)] memorizza l'ambiente in virgola mobile corrente nell'oggetto puntato daenvp

• [7.12.6.4 (frexp)] memorizza il numero intero nell'oggetto int puntato daexp

• [7.19.5.1 (fclose)] lo stream puntato dastream

Esempio 2 - printf

[7.19.6.1] dice questo su %p:

p- L'argomento deve essere un puntatore a void. Il valore del puntatore viene convertito in una sequenza di caratteri di stampa, in un modo definito dall'implementazione.

Null è un valore di puntatore valido e questa sezione non menziona esplicitamente che null è un caso speciale, né che il puntatore deve puntare a un oggetto. Quindi è definito comportamento.

_{1. A meno che non si faccia avanti un autore di standard, oa meno che non riusciamo a trovare qualcosa di simile a un documento razionale che chiarisca le cose.}

La risposta breve

Sì . La stampa di puntatori nulli con l'identificatore di %pconversione ha un comportamento indefinito. Detto questo, non sono a conoscenza di alcuna implementazione conforme esistente che si comporterebbe male.

La risposta si applica a qualsiasi standard C (C89 / C99 / C11).

La lunga risposta

Lo %pspecificatore di conversione si aspetta che un argomento di tipo pointer sia void, la conversione del puntatore in caratteri stampabili è definita dall'implementazione. Non afferma che è previsto un puntatore nullo.

L'introduzione alle funzioni della libreria standard afferma che i puntatori nulli come argomenti alle funzioni (della libreria standard) sono considerati valori non validi, a meno che non sia esplicitamente dichiarato diversamente.

C99 / C11 §7.1.4 p1

[...] Se un argomento di una funzione ha un valore non valido (come [...] un puntatore nullo, [...] il comportamento è indefinito.

Esempi di funzioni (libreria standard) che prevedono puntatori nulli come argomenti validi:

• fflush() usa un puntatore nullo per scaricare "tutti i flussi" (che si applicano).
• freopen() utilizza un puntatore nullo per indicare il file "attualmente associato" al flusso.
• snprintf() permette di passare un puntatore nullo quando 'n' è zero.
• realloc() usa un puntatore nullo per allocare un nuovo oggetto.
• free() permette di passare un puntatore nullo.
• strtok() utilizza un puntatore nullo per le chiamate successive.

Se prendiamo il caso per snprintf(), ha senso consentire il passaggio di un puntatore nullo quando 'n' è zero, ma questo non è il caso per altre funzioni (libreria standard) che consentono uno zero simile 'n'. Ad esempio: memcpy(), memmove(), strncpy(), memset(), memcmp().

Non è specificato solo nell'introduzione alla libreria standard, ma anche nell'introduzione a queste funzioni:

C99 §7.21.1 p2 / C11 §7.24.1 p2

Dove un argomento dichiarato come size_tn specifica la lunghezza dell'array per una funzione, n può avere il valore zero in una chiamata a quella funzione. A meno che non sia esplicitamente dichiarato diversamente nella descrizione di una particolare funzione in questo sottoclausola, gli argomenti del puntatore su tale chiamata devono ancora avere valori validi come descritto in 7.1.4.

È intenzionale?

Non so se l'UB di %pcon un puntatore nullo sia in realtà intenzionale, ma poiché lo standard afferma esplicitamente che i puntatori nulli sono considerati valori non validi come argomenti per le funzioni di libreria standard, quindi va e specifica esplicitamente i casi in cui un nullo puntatore è un argomento valido (snprintf, libero, ecc), e poi va e ancora una volta si ripete l'obbligo per gli argomenti siano valide anche in zero 'n' casi ( memcpy, memmove, memset), quindi penso che sia ragionevole supporre che la Il comitato per gli standard C non si preoccupa troppo di avere queste cose indefinite.

Gli autori dello standard C non hanno fatto alcuno sforzo per elencare in modo esaustivo tutti i requisiti comportamentali che un'implementazione deve soddisfare per essere adatta a uno scopo particolare. Invece, si aspettavano che le persone che scrivono compilatori esercitassero una certa dose di buon senso indipendentemente dal fatto che lo Standard lo richiedesse o meno.

La questione se qualcosa invoca UB è raramente utile di per sé. Le vere domande importanti sono:

1. Qualcuno che sta cercando di scrivere un compilatore di qualità dovrebbe farlo comportarsi in modo prevedibile? Per lo scenario descritto la risposta è chiaramente sì.

2. I programmatori dovrebbero avere il diritto di aspettarsi che compilatori di qualità per qualcosa di simile a piattaforme normali si comportino in modo prevedibile? Nello scenario descritto, direi che la risposta è sì.

3. Potrebbero alcuni ottusi scrittori di compilatori estendere l'interpretazione dello Standard in modo da giustificare il fatto di fare qualcosa di strano? Spero di no, ma non lo escludo.

4. I compilatori disinfettanti dovrebbero lamentarsi del comportamento? Ciò dipenderebbe dal livello di paranoia dei loro utenti; un compilatore disinfettante probabilmente non dovrebbe lamentarsi per impostazione predefinita di tale comportamento, ma forse fornire un'opzione di configurazione da fare nel caso in cui i programmi possano essere portati su compilatori "intelligenti" / stupidi che si comportano in modo strano.

Se un'interpretazione ragionevole dello Standard implicherebbe la definizione di un comportamento, ma alcuni autori di compilatori estendono l'interpretazione per giustificare il fatto di fare diversamente, è davvero importante quello che dice lo Standard?