Le funzioni di una libreria C dovrebbero sempre aspettarsi la lunghezza di una stringa?

Attualmente sto lavorando a una libreria scritta in C. Molte funzioni di questa libreria prevedono una stringa come char*o const char*nei loro argomenti. Ho iniziato con quelle funzioni aspettandomi sempre la lunghezza della stringa in size_tmodo che non fosse richiesta la terminazione nulla. Tuttavia, quando si scrivono i test, ciò ha comportato un uso frequente di strlen(), in questo modo:

const char* string = "Ugh, strlen is tedious";
libFunction(string, strlen(string));

Fidarsi che l'utente passi stringhe correttamente terminate porterebbe a un codice meno sicuro, ma più conciso e (secondo me) leggibile:

libFunction("I hope there's a null-terminator there!");

Allora, qual è la pratica sensata qui? Rendere l'API più complicata da usare, ma costringere l'utente a pensare al proprio input o documentare il requisito per una stringa con terminazione null e fidarsi del chiamante?

Sicuramente e assolutamente portare la lunghezza in giro . La libreria C standard è stata notoriamente rotta in questo modo, il che non ha causato fine al dolore nel gestire gli overflow del buffer. Questo approccio è al centro di così tanto odio e angoscia che i compilatori moderni avvertiranno, piagnucoleranno e si lamenteranno quando usano questo tipo di funzioni standard della libreria.

È così brutto che se mai ti imbatti in questa domanda durante un'intervista - e il tuo intervistatore tecnico sembra avere qualche anno di esperienza - il puro zelo può far finire il lavoro - puoi davvero andare molto avanti se puoi citare il precedente di sparare a qualcuno che implementa API in cerca del terminatore di stringhe C.

Lasciando da parte l'emozione di tutto ciò, c'è molto che può andare storto con quel NULL alla fine della tua stringa, sia nella lettura che nella manipolazione - inoltre è davvero una violazione diretta di concetti di design moderni come la difesa in profondità (non necessariamente applicato alla sicurezza, ma alla progettazione dell'API). Esempi di API C che portano la lunghezza abbondano - es. l'API di Windows.

In realtà, questo problema è stato risolto negli anni '90, il consenso emergente di oggi è che non dovresti nemmeno toccare le corde .

Modifica successiva : questo è un dibattito piuttosto vivo, quindi aggiungerò che fidarsi di tutti sotto e sopra di te per essere gentile e usare le funzioni str * della libreria va bene, fino a quando vedi cose classiche come output = malloc(strlen(input)); strcpy(output, input);o while(*src) { *dest=transform(*src); dest++; src++; }. Riesco quasi a sentire la Lacrimosa di Mozart in sottofondo.

In C, il linguaggio è che le stringhe di caratteri sono terminate con NUL, quindi ha senso attenersi alla pratica comune - in realtà è relativamente improbabile che gli utenti della libreria dispongano di stringhe senza terminazione NUL (poiché queste hanno bisogno di ulteriore lavoro per stampare usando printf e usalo in un altro contesto). L'uso di qualsiasi altro tipo di stringa è innaturale e probabilmente relativamente raro.

Inoltre, date le circostanze, il tuo test mi sembra un po 'strano, dal momento che per funzionare correttamente (usando strlen), stai assumendo in primo luogo una stringa terminata con NUL. Dovresti testare il caso di stringhe non terminate con NUL se intendi che la tua libreria funzioni con esse.

Il tuo argomento di "sicurezza" non regge. Se non ti fidi che l'utente ti consegni una stringa con terminazione nulla quando questo è ciò che hai documentato (e qual è "la norma" per la semplice C), non puoi davvero fidarti della lunghezza che ti danno (che probabilmente strlenlo farai usando esattamente come stai facendo se non lo hanno a portata di mano, e ciò fallirà se la "stringa" non era una stringa in primo luogo).

Esistono motivi validi per richiedere una lunghezza: se vuoi che le tue funzioni lavorino su sottostringhe, è probabilmente molto più semplice (ed efficiente) passare una lunghezza piuttosto che far fare all'utente un po 'di copia magica avanti e indietro per ottenere il byte null nel posto giusto (e rischiano errori off-by-one lungo la strada).
Essere in grado di gestire codifiche in cui i byte null non sono terminazioni o essere in grado di gestire stringhe con null incorporati (apposta) può essere utile in alcune circostanze (dipende da cosa esattamente fanno le tue funzioni).
Essere in grado di gestire dati senza terminazione null (array a lunghezza fissa) è anche utile.
In breve: dipende da cosa stai facendo nella tua libreria e dal tipo di dati che prevedi vengano gestiti dagli utenti.

C'è anche forse un aspetto prestazionale in questo. Se la tua funzione ha bisogno di conoscere in anticipo la lunghezza della stringa e ti aspetti che i tuoi utenti sappiano almeno di solito già tali informazioni, farle passare (piuttosto che calcolarle) potrebbe radere alcuni cicli.

Ma se la tua biblioteca si aspetta normali stringhe di testo ASCII normali e non hai vincoli di prestazioni lancinanti e una buona comprensione di come gli utenti interagiranno con la tua biblioteca, l'aggiunta di un parametro di lunghezza non sembra una buona idea. Se la stringa non viene terminata correttamente, è probabile che il parametro length sia altrettanto falso. Non penso che guadagnerai molto con esso.

No. Le stringhe sono sempre nulle per definizione, la lunghezza della stringa è ridondante.

I dati dei caratteri non terminati con null non devono mai essere chiamati "string". L'elaborazione (e il lancio di lunghezze) dovrebbe in genere essere incapsulata all'interno di una libreria e non parte dell'API. Richiedere la lunghezza come parametro solo per evitare singole chiamate strlen () è probabilmente un'ottimizzazione precoce.

Fidarsi del chiamante di una funzione API non è pericoloso ; un comportamento indefinito è perfettamente accettabile se non sono soddisfatte le condizioni documentate.

Naturalmente, un'API ben progettata non dovrebbe contenere insidie ​​e dovrebbe facilitarne l'uso corretto. E questo significa solo che dovrebbe essere il più semplice e diretto possibile, evitando licenziamenti e seguendo le convenzioni del linguaggio.

Dovresti sempre mantenere la tua lunghezza. Per uno, i tuoi utenti potrebbero voler contenere NULL in essi. E in secondo luogo, non dimenticare che strlenè O (N) e richiede di toccare l'intera cache ciao ciao. E in terzo luogo, facilita il passaggio tra i sottoinsiemi, ad esempio, potrebbero fornire meno della lunghezza effettiva.

È necessario distinguere tra il passaggio di una stringa e il passaggio di un buffer .

In C, le stringhe sono tradizionalmente terminate con NUL. È del tutto ragionevole aspettarselo. Pertanto, di solito non è necessario passare per la lunghezza della stringa; può essere calcolato strlense necessario.

Quando si passa attorno a un buffer , in particolare a quello in cui è stato scritto, è necessario passare assolutamente la dimensione del buffer. Per un buffer di destinazione, ciò consente al chiamante di assicurarsi che non trabocchi il buffer. Per un buffer di input, consente al chiamante di evitare la lettura oltre la fine, specialmente se il buffer di input contiene dati arbitrari provenienti da una fonte non attendibile.

C'è forse un po 'di confusione perché potrebbero essere sia le stringhe che i buffer char*e perché molte funzioni di stringa generano nuove stringhe scrivendo nei buffer di destinazione. Alcune persone concludono quindi che le funzioni di stringa dovrebbero richiedere lunghezze di stringa. Tuttavia, questa è una conclusione inaccurata. La pratica di includere una dimensione con un buffer (sia che quel buffer sia usato per stringhe, matrici di numeri interi, strutture, qualunque cosa) è un mantra più utile e più generale.

(Nel caso di lettura di una stringa da una fonte non attendibile (ad esempio una presa di rete), è importante fornire una lunghezza quanto l'ingresso potrebbe non essere NUL-terminato. Tuttavia , si dovrebbe non considera l'ingresso come una stringa. È dovrebbe trattarlo come un buffer di dati arbitrario che potrebbe contenere una stringa (ma non lo sai fino a quando non lo convalidi effettivamente), quindi questo segue ancora il principio che i buffer dovrebbero avere dimensioni associate e che le stringhe non ne hanno bisogno.)

Se le funzioni vengono utilizzate principalmente con i letterali stringa, il dolore di gestire lunghezze esplicite può essere ridotto al minimo definendo alcune macro. Ad esempio, data una funzione API:

void use_string(char *string, int length);

si potrebbe definire una macro:

#define use_strlit(x) use_string(x, sizeof ("" x "")-1)

e quindi invocarlo come mostrato in:

void test(void)
{
  use_strlit("Hello");
}

Mentre potrebbe essere possibile trovare cose "creative" per passare quella macro che verrà compilata ma non funzionerà effettivamente, l'uso di ""su entrambi i lati della stringa nella valutazione di "sizeof" dovrebbe catturare tentativi accidentali di usare il carattere puntatori diversi dai letterali di stringa decomposti [in assenza di quelli "", un tentativo di passare un puntatore a carattere darebbe erroneamente la lunghezza della dimensione di un puntatore, meno uno.

Un approccio alternativo in C99 sarebbe quello di definire un tipo di struttura "puntatore e lunghezza" e definire una macro che converte una stringa letterale in un letterale composto di quel tipo di struttura. Per esempio:

struct lstring { char const *ptr; int length; };
#define as_lstring(x) \
  (( struct lstring const) {x, sizeof("" x "")-1})

Si noti che se si utilizza un tale approccio, è necessario passare tali strutture per valore anziché passare attorno ai loro indirizzi. Altrimenti qualcosa di simile:

struct lstring *p;
if (foo)
{
  p = &as_lstring("Hello");
}
else
{
  p = &as_lstring("Goodbye!");
}
use_lstring(p);

potrebbe fallire poiché la vita dei letterali composti terminerebbe alla fine delle loro dichiarazioni allegate.