|
|
|
|
Strumenti |
02-10-2017, 12:11 | #1 |
Member
Iscritto dal: Oct 2009
Messaggi: 70
|
[C] porting e gestione carattere \0
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 |
02-10-2017, 12:47 | #2 | |
Member
Iscritto dal: Oct 2009
Messaggi: 70
|
Quote:
Grazie |
|
02-10-2017, 13:35 | #3 |
Member
Iscritto dal: Oct 2009
Messaggi: 70
|
|
02-10-2017, 16:43 | #4 |
Senior Member
Iscritto dal: Nov 2005
Messaggi: 2095
|
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: Codice:
struct my_struct *x; x = NULL; printf("%d\n", x->vai_in_core);
__________________
Cosmos C# Open Source Managed Operating System Cosmos Thread Ufficiale Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat! |
02-10-2017, 16:58 | #5 | |
Member
Iscritto dal: Oct 2009
Messaggi: 70
|
Quote:
|
|
02-10-2017, 17:51 | #6 |
Member
Iscritto dal: Oct 2009
Messaggi: 70
|
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 |
02-10-2017, 18:21 | #7 |
Senior Member
Iscritto dal: May 2001
Messaggi: 12580
|
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 Codice:
char s[] = "pippo"; char *s1 = "pluto"; Ultima modifica di WarDuck : 02-10-2017 alle 18:26. |
02-10-2017, 18:38 | #8 | |
Senior Member
Iscritto dal: Nov 2005
Messaggi: 2095
|
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...
Quote:
@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
__________________
Cosmos C# Open Source Managed Operating System Cosmos Thread Ufficiale Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat! |
|
02-10-2017, 19:47 | #9 | |
Member
Iscritto dal: Oct 2009
Messaggi: 70
|
Quote:
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 |
|
02-10-2017, 22:01 | #10 |
Member
Iscritto dal: Oct 2009
Messaggi: 70
|
|
03-10-2017, 08:28 | #11 | |
Senior Member
Iscritto dal: Nov 2005
Messaggi: 2095
|
Quote:
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
__________________
Cosmos C# Open Source Managed Operating System Cosmos Thread Ufficiale Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat! |
|
03-10-2017, 10:18 | #12 |
Member
Iscritto dal: Oct 2009
Messaggi: 70
|
come controllo con sicurezza se l'array termina con '\0'?
trovo varie versioni grazie |
03-10-2017, 11:07 | #13 |
Member
Iscritto dal: Oct 2009
Messaggi: 70
|
|
03-10-2017, 12:09 | #14 |
Senior Member
Iscritto dal: Aug 2017
Messaggi: 469
|
|
08-10-2017, 11:45 | #15 | ||
Senior Member
Iscritto dal: May 2001
Messaggi: 12580
|
Quote:
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. Quote:
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. Ultima modifica di WarDuck : 08-10-2017 alle 12:00. |
||
10-10-2017, 09:02 | #16 |
Senior Member
Iscritto dal: Nov 2005
Messaggi: 2095
|
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"
__________________
Cosmos C# Open Source Managed Operating System Cosmos Thread Ufficiale Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat! |
10-10-2017, 15:00 | #17 | |
Moderatore
Iscritto dal: Nov 2006
Messaggi: 20827
|
Quote:
__________________
"WS" (p280,cx750m,4790k+212evo,z97pro,4x8GB ddr3 1600c11,GTX760-DC2OC,MZ-7TE500, WD20EFRX) Desktop (three hundred,650gq,3800x+nh-u14s ,x570 arous elite,2x16GB ddr4 3200c16, rx5600xt pulse P5 1TB)+NB: Lenovo p53 i7-9750H,64GB DDR4,2x1TB SSD, T1000 |
|
10-10-2017, 16:39 | #18 |
Senior Member
Iscritto dal: Nov 2005
Messaggi: 2095
|
Sì trovo Cyclone piuttosto interessante in effetti peccato abbia avuto poca diffusione
__________________
Cosmos C# Open Source Managed Operating System Cosmos Thread Ufficiale Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat! |
10-10-2017, 16:46 | #19 | |
Moderatore
Iscritto dal: Nov 2006
Messaggi: 20827
|
Quote:
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à
__________________
"WS" (p280,cx750m,4790k+212evo,z97pro,4x8GB ddr3 1600c11,GTX760-DC2OC,MZ-7TE500, WD20EFRX) Desktop (three hundred,650gq,3800x+nh-u14s ,x570 arous elite,2x16GB ddr4 3200c16, rx5600xt pulse P5 1TB)+NB: Lenovo p53 i7-9750H,64GB DDR4,2x1TB SSD, T1000 |
|
11-10-2017, 08:45 | #20 |
Senior Member
Iscritto dal: Nov 2005
Messaggi: 2095
|
[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!)
__________________
Cosmos C# Open Source Managed Operating System Cosmos Thread Ufficiale Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat! |
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 04:42.