[C] porting e gestione carattere \0

[chicco19811]

sto facendo un porting di un software in C da HPUX a Linux (premetto che di C conosco poco)

un codice del genere (semplice esempietto da me creato)

char string1[4];
string1[0]='s';
string1[1]='d';
string1[2]='d';
string1[3] = '\0';

char string2[1];
string2[0] = 'a';
printf("\n%s\n", string2);

char string3[2];
string3[0] = 'a';
string3[1] = '\0';
printf("\n%s\n", string3);

sotto LINUX genera

asdd
a

mentre sotto HPUX

a
a

come se sotto Linux, la mancanza del carattere '\0' in string2 "sporcasse" la stessa stringa con il contenuto di string1, cosa che non accade sotto HPUX; quando invece si chiude con '\0' come nel caso di string3, il comportamento è uguale

che mi consigliate?
visto che ho trovato nel codice degli array non chiusi con \0

Grazie

[chicco19811]

Originariamente inviato da Bellaz89

Di mettere \0. Chi ha scritto il codice originario ha scritto codice buggato. Nelle funzioni che accettano stringhe senza specificare la lunghezza delle stesse si dovrebbe SEMPRE passare stringhe NULL terminated.
E anche se il codice su HP-UX 'funziona' c'e' il rischio che questa cattiva programmazione renda il codice scritto insicuro e soggetto ad attacchi che sfruttano il buffer overflow.

quali sono i problemi che si possono avere?
Grazie

[chicco19811]

Originariamente inviato da Bellaz89

Buffer Overflow. L'hai visto anche te. c'e' il rischio che le funzioni utilizzino piu' dati rispetto a quelli del buffer passato.

grazie

[fano]

Sistema Operativi più "serii" come VxWorks e HP / UX credo "paddassero" automaticamente la memoria con '\0' e quindi questi bug non uscivano fuori... quando facemmo il porting del nostro software da VxWorks a Linux furono dolori visto che andava in SEGFAULT / sbordava di continuo.

Il codice come dice Bellaz89 è bacato visto che la definizione di "stringa" in C è "array di caratteri con '\0' in fondo" però sembra che quei sistemi preferissero coprire questo porcate per permettere a software magari "mission critical" di funzionare comunque...

VxWork per dire non fa una piega nemmeno con questo:

struct my_struct *x;

x = NULL;

printf("%d\n", x->vai_in_core);

il valore stampato era probabilmente "bratta" però sopravviveva, Linux ovviamente ci restava secco

[chicco19811]

Originariamente inviato da fano

Sistema Operativi più "serii" come VxWorks e HP / UX credo "paddassero" automaticamente la memoria con '\0' e quindi questi bug non uscivano fuori... quando facemmo il porting del nostro software da VxWorks a Linux furono dolori visto che andava in SEGFAULT / sbordava di continuo.

Il codice come dice Bellaz89 è bacato visto che la definizione di "stringa" in C è "array di caratteri con '\0' in fondo" però sembra che quei sistemi preferissero coprire questo porcate per permettere a software magari "mission critical" di funzionare comunque...

VxWork per dire non fa una piega nemmeno con questo:

struct my_struct *x;

x = NULL;

printf("%d\n", x->vai_in_core);

il valore stampato era probabilmente "bratta" però sopravviveva, Linux ovviamente ci restava secco

grazie

[chicco19811]

chiedo un'altra cosa: sui 2 sistemi operativi i tipi di dati differiscono per alcuni aspetti

non potrebbe causare problema questa cosa?
intendo per l'aggiunta (magari anche da parte di alcune funzioni) del '\0'

grazie e scusate se ho scritto boiate

[WarDuck]

Le stringhe in C sono per definizione array di caratteri terminati con 0.

Il linguaggio C è uno standard, per cui c'entra poco il sistema operativo utilizzato.

Quello che può cambiare in generale può essere:
1) l'implementazione della libreria C (funzioni come printf, strncpy e compagnia bella...)
2) le chiamate di sistema (generalmente wrappate dalla libc)

Se il sistema operativo rispetta lo standard POSIX (adesso SUS) e il programma è scritto per utilizzare funzioni POSIX, non dovrebbero sussistere problemi di portabilità.

@fano: VxWorks, a detta di qualcuno che ha visto il codice sorgente non è proprio da prendere come esempio .

Il fatto che non fa una piega in un contesto in cui:
1) viene de-referenziato un puntatore NULL (quindi errore palese)
2) dovrebbe essere generata una TRAP

La dice MOOOLTO LUNGA .

Anzi mi fa pensare in un bug del compilatore, bisognerebbe vedere l'assembly generato.

Evitiamo di dire castronerie e portare ad esempio situazioni palesemente errate in cui per PURA FORTUNA le cose funzionano (MALE).

PS: se uno fa assegnazioni del tipo

char s[] = "pippo";
char *s1 = "pluto";

Il terminatore '\0' viene aggiunto in automatico (in genere questo è vero per tutte le stringhe letterali).

[fano]

Originariamente inviato da Antonio23

non ho capito, chi padda cosa?

Così come è possibile per esempio configurare Visual Studio per settare la memoria non usata con valori speciali tipo "0x0BADCAFE" è possibile che HP/UX azzerasse tutta la memoria...

Originariamente inviato da Antonio23

sarei curioso di sapere come... a me sembra una casualita'.

NULL è uguale all'indirizzo 0x00 è una "convenzione" che NON si possa usare, per la CPU non è un "trap", non succede proprio niente se ci scrivi qualcosa o leggi qualcosa da lì, ma di nuovo lo standard C prevede che il programma termini in maniera anomala (SEGFAULT di solito).

@WarDuck
Cerchiamo di capirci non stavo dicendo che VxWork e HP / UX siano dei gioiellini tecnologi per permettere a sti bug di passare inosservati anzi sono pura e semplice bratta!
Ho passato una "vita" con quel m*rdaio di VxWorks che quando "per sbaglio" rilevava un errore andava in "Bus Error" uccidendo l'intero kernel (e via di "bottonata").
E` però evidente che siano stati scritti con filosofie differenti, Linux / libc vanno in core per qualsiasi c*zzata dai...

Purtroppo il nostro amico chicco19811 ora passerà un periodo nel tentativo di trovare tutte le stringhe non tappate "been here, done that"... converrebbe quasi "perdere i sorgenti" e riscrivere tutto da capo in questi casi

[chicco19811]

Originariamente inviato da fano

Purtroppo il nostro amico chicco19811 ora passerà un periodo nel tentativo di trovare tutte le stringhe non tappate "been here, done that"... converrebbe quasi "perdere i sorgenti" e riscrivere tutto da capo in questi casi

e difatti ho dei bei ORA-01480 (trailing null missing from STR bind value) e, cercando, leggo che "In Pro*C and ORA-01480 may be caused by a lack of the trailing NULL character"

pur da totale ignorante in materia, penso che potrebbe essere un problema collegato

[chicco19811]

Originariamente inviato da Bellaz89

Mi sa che è l'ora di imparare ad usare gdb

lo so già un minimo usare, domani procedo al debug :-)

ho già individuato dove potrebbe essere l'errore guardando il codice

[fano]

Originariamente inviato da Antonio23

NULL (o 0x0) semplicemente non e' mappato su nessuna pagina associata a nessun processo (almeno nei sistemi operativi mainstream win/linux/osx con supporto alla paginazione). non mi risulta che lo standard C prescriva nulla riguardo 0x0, tant'e' che nei sistemi embedded (senza MMU, e singolo spazio d'indirizzi) con processore ARM e' in genere l'indirizzo da dove leggere il valore di inizalizzazione dello stack pointer. anzi, probabilmente vxworks continuava proprio per qualche motivo simile.

Credo tu abbia ragione la mia versione di VxWorks girava su Motorola 68000 probabilmente senza MMU... infatti è di solito una convenzione che si vada in SEGFAULT.

Io credevo fosse x86 ad andare in fault, ma quest'estate per un bug in Cosmos scrivevamo / leggevamo da 0x00 (null) e correttamente il nostro check segnalava "null pointer exception", ma disabilitando il check apparentemente tutto funzionava la CPU non faceva una piega

[chicco19811]

come controllo con sicurezza se l'array termina con '\0'?
trovo varie versioni

grazie

[chicco19811]

Originariamente inviato da Bellaz89

Temo che senza sapere a priori la lunghezza della stringa stessa tu non possa vedere se e' terminata.

e conoscendo la lunghezza?
grazie

[Mursey]

Originariamente inviato da chicco19811

e conoscendo la lunghezza?
grazie

Si controlla l'ultimo elemento dell'array.

[WarDuck]

Originariamente inviato da fano

E` però evidente che siano stati scritti con filosofie differenti, Linux / libc vanno in core per qualsiasi c*zzata dai...

Non mi sembra propriamente un'argomentazione tecnica la tua, quanto una sparata .
Dimmi in quale caso, l'accesso ad una regione di memoria non valida, come nel caso di un NULL pointer dereference, potrebbe essere gestito di default in maniera diversa dalla terminazione del processo.

Nota poi che su Linux il signale SIGSEGV può essere gestito configurando l'apposito signal handler (quindi per esempio potrei pensare di stampare un backtrace).

In generale il problema è di chi scrive codice MALE. Tanto per la cronaca, mi risulta che in tutti i linguaggi anche di alto livello sia considerato un errore un null pointer dereference.

Si può piuttosto discutere del fatto che chi programma dovrebbe attenersi a dei pattern, come ad esempio il pattern RAII, per evitare errori di questo tipo e rendere il codice più leggibile evitando controlli ridondanti.

Ad esempio in C++ posso assumere che il costruttore di un oggetto venga sempre invocato prima di tutti i metodi, quindi se alloco qualcosa lì e l'allocazione va a buon fine, non ho bisogno di controllare in ogni metodo che stia accedendo ad un puntatore non-NULL, perché questa è una invariante di classe.

Originariamente inviato da Antonio23

mi ero perso questo commento. In realta' in C "NULL Pointer dereferencing" e' undefined behaviiour, quindi non c'e' niente. che prescriva che questo errore debba generare una trap a runtime (o equivalenti). Il compilatore sta funzionando a dovere, come il sistema operativo funziona come dovrebbe funzionare, semplicemente non c'e' nessun componente hardware che genera un fault.

È chiaro che l'indirizzo 0 viene mappato dall'MMU su una pagina non valida o con i flag di protezione tali che venga generato un fault ad accedervi. Ma è coerente con il resto del linguaggio, in particolare ad esempio le funzioni di allocazione della memoria come malloc() restituiscono 0 in caso di errore. Quindi si presume che tu debba controllare che l'indirizzo sia comunque diverso da NULL.

In generale poi proprio perché è undefined behavior, dovrebbe essere considerato sempre e comunque un errore a livello logico.

Nei sistemi senza MMU è comunque di solito presente una MPU che può essere configurata opportunamente per avere un comportamento coerente con quello che si aspetta un programmatore C.

Comunque non prendiamocela con gli strumenti quando gli errori vengono introdotti dagli esseri umani.

PS: riguardo l'inizializzazione delle variabili, in genere questo viene fatto a runtime. In particolare la sezione .bss su Linux ad esempio viene azzerata, dunque le variabili che cadono in questa sezione (come ad esempio le variabili globali non inizializzate) assumono valore 0. In generale comunque non si dovrebbe contare troppo su questo fatto.

Variabili sullo stack non inizializzate in particolare possono assumere valori "pseudo-casuali" dovuti a precedenti invocazione a funzione.

[fano]

Magari possiamo giungere a un compromesso dicendo che il C rende più "facile" scrivere codice brutto e pasticciato... per esempio il fatto che manchi un tipo stringa vero e proprio e che molte funzioni della libc che operano sulle stringhe non rispettino esse stesse il "contratto" che ci deve essere sempre il '\0' in fondo... fa pensare "ma perché io mi devo sbattere?"

Per esempio per essere sempre certo che la stringa sia tappata NON si deve usare mai strcpy() (o strncpy() che di tappi ne mette troppi), ma sprintf() o meglio ancora snprintf()!
Oppure se usi gets() vai nell'inferno dei programmatori

Di fatto l'unica "soluzione" vera è di scriversi un sacco di funzioncine wrapper per rendere il C più safe.. ovvero se volete rendere il C "managed"

[!fazz]

Originariamente inviato da fano

Magari possiamo giungere a un compromesso dicendo che il C rende più "facile" scrivere codice brutto e pasticciato... per esempio il fatto che manchi un tipo stringa vero e proprio e che molte funzioni della libc che operano sulle stringhe non rispettino esse stesse il "contratto" che ci deve essere sempre il '\0' in fondo... fa pensare "ma perché io mi devo sbattere?"

Per esempio per essere sempre certo che la stringa sia tappata NON si deve usare mai strcpy() (o strncpy() che di tappi ne mette troppi), ma sprintf() o meglio ancora snprintf()!
Oppure se usi gets() vai nell'inferno dei programmatori

Di fatto l'unica "soluzione" vera è di scriversi un sacco di funzioncine wrapper per rendere il C più safe.. ovvero se volete rendere il C "managed"

e fu così che si reinventò cyclone

[fano]

Sì trovo Cyclone piuttosto interessante in effetti peccato abbia avuto poca diffusione

[!fazz]

Originariamente inviato da fano

Sì trovo Cyclone piuttosto interessante in effetti peccato abbia avuto poca diffusione

Io per nulla, dal mio punto di vista va benissimo che c/c++ non controlli nulla in quanto questo mi permette di avere un codice più veloce il che lavorando su MCU spesso è vitale in quanto sono sempre tirate per il collo all'inverosimile. questo mi permette di mettere i controlli solo dove necessario

se voglio un linguaggio più avanzato sicuramente c non è la scelta migliore se devo utilizzare un accrocchio che mette pezze su pezze snaturando completamente il linguaggio tanto vale utilizzare un linguaggio che prevede nativamente queste funzionalità

[fano]

[quote=!fazz;45086879
se voglio un linguaggio più avanzato sicuramente c non è la scelta migliore se devo utilizzare un accrocchio che mette pezze su pezze snaturando completamente il linguaggio tanto vale utilizzare un linguaggio che prevede nativamente queste funzionalità
[/QUOTE]

Su questo concordo assolutamente se sei nella "bratta" e devi programmare un processore a 8 bit con 64 KB di RAM beh C magari è fin troppo... quasi il caso di pensare ad assembler

Per il resto meglio convertirsi a cosa più moderne tipo Rust o C#

Resto dell'idea che almeno K & R ad un vero tipo stringa avrebbero dovuto pensarci niente di complesso o "esotico" semplicemente come fatto in Pascal una struttura con un size_t seguito da un void * / char * e un'intera classe di bug sarebbero "magicamente" spariti.
(Operare sulle stringhe sarebbe stato MOLTO più efficiente pure!)