Perché QCoreApplication chiama `setlocale (LC_ALL," ")` di default su Unix/Linux?

Question

Penso che sia sicuro dire che le localizzazioni C sono universalmente riconosciute come una cattiva idea.

Scrittura di un'applicazione che tenta di analizzare o scrivere formati di macchina basati su testo (cosa che accade abbastanza spesso) con le funzioni di libreria standard di C diventa quasi impossibile se si deve tenere conto dell'impostazione locale impostata su qualcosa di diverso da "C". Poiché la localizzazione è normalmente per processo (e setlocale spesso non è thread-safe), se stai scrivendo una libreria o hai un programma multithreading non è sicuro nemmeno fare setlocale(LC_ALL, "C") e ripristinarlo dopo aver fatto il tuo lavoro.

Ora, per questi motivi la regola è normalmente "evitare setlocale, punto"; ma: siamo stati morsi diverse volte in passato dal comportamento particolare di QCoreApplication e classi derivate; il documentation dice:

Su Unix/Linux Qt è configurato per utilizzare le impostazioni internazionali del sistema per impostazione predefinita. Ciò può causare un conflitto quando si utilizzano le funzioni POSIX, ad esempio, durante la conversione tra tipi di dati come float e stringhe, poiché la notazione potrebbe differire tra le impostazioni internazionali. Per ovviare a questo problema, chiamare la funzione POSIX setlocale(LC_NUMERIC,"C") subito dopo l'inizializzazione di QApplication o QCoreApplication per reimpostare le impostazioni locali utilizzate per la formattazione dei numeri su "C" -locale.

Questo comportamento è stato descritto in another question; la mia domanda è: quale potrebbe essere la logica di questo comportamento apparentemente sciocco? In particolare, cosa c'è di così peculiare su Unix e Linux che ha spinto tale decisione solo su queste piattaforme?

(Per inciso, sarà tutto rompersi se io faccio solo setlocale(LC_ALL, "C"); dopo aver creato il QApplication? Se va bene, perché non hanno semplicemente rimuovere il loro setlocale(LC_ALL, "");?)

Answer 1

Da indagini attraverso il codice sorgente di Qt condotti da @Phil Armstrong e me (vedi the chat log), sembra che la chiamata setlocale è là a partire dalla versione 1 per diversi motivi:

• XIM, almeno in antica volte, non ha "ottenuto" correttamente le impostazioni locali senza una tale chiamata.
• Su Solaris, si è persino arrestato in modo anomalo con le impostazioni internazionali C predefinite.
• Sui sistemi Unix, è usato (tra gli altri sistemi, in un complesso gioco di fallback) per "annusare" il "set di caratteri di sistema" (qualunque cosa significhi su Unix), e quindi essere in grado di convertire tra la rappresentazione QString e la codifica "locale" a 8 bit (questo è particolarmente critico per i percorsi dei file).

E 'vero che controlla già le variabili d'ambiente LC_*, come fa con QLocale, ma suppongo che possa essere utile avere nl_langinfo decodificare la corrente LC_CTYPE se l'applicazione in modo esplicito cambiato (ma per vedere se ci è un cambiamento esplicito, deve iniziare con i valori di default del sistema).

E 'interessante il fatto che hanno fatto un setlocale(LC_NUMERIC, "C") subito dopo il setlocale(LC_ALL, ""), ma this was removed in Qt 4.4. Il fondamento logico di questa decisione sembra risiedere nell'attività # 132859 del vecchio bugtracker Qt (che si è spostato tra TrollTech, Nokia e QtSoftware.com prima di scomparire senza lasciare traccia, nemmeno nello Wayback Machine), ed è referenziato in twobugs riguardo questo argomento. Penso che ci sia stata una risposta autorevole sull'argomento, ma non riesco a trovare un modo per recuperarla.

La mia ipotesi è che ha introdotto i bug sottili, in quanto l'ambiente sembrava incontaminata, ma in realtà era toccato dalla setlocale chiamata in tutti, ma la categoria LC_NUMERIC (che è il più evidente); probabilmente hanno rimosso la chiamata per rendere l'impostazione locale più evidente e gli sviluppatori di applicazioni agire di conseguenza.

Answer 2

Cosa c'è di così particolare sui sistemi POSIX (che include il Sistemi Unix/Linux menzionati) è che l'interfaccia del SO e l'interfaccia C sono confusi. La chiamata C setlocale interferisce in particolare con il sistema operativo.

Su Windows, in confronto, la locale è esplicitamente una proprietà per-thread (SetThreadLocale), ma ancora più importante, funzioni come GetNumberFormat accettano un parametro locale.

Nota che il tuo problema è abbastanza facile da risolvere: quando usi Qt, usa Qt. Quindi questo significa reading your text input into a QString, elaborarlo e quindi scriverlo di nuovo.

Answer 3

Qt chiama setlocale(LC_ALL, ""), perché è la cosa giusta da fare: ogni programma Unix standard da cat su chiamate setlocale(LC_ALL, ""). La conseguenza di tale chiamata è che il locale del programma è impostato su quello specificato dall'utente. Vedere la manpage setlocale():

All'avvio del programma principale, la locale "C" portatile è selezionata come come impostazione predefinita. Un programma può essere portabile su tutte le versioni locali chiamando:

setlocale(LC_ALL, "");

dopo l'inizializzazione del programma ...

Dato che Qt sia genera testo per essere letto dall'utente e analizza ingresso generati dall'utente, sarebbe molto ostile di rifiutare di consentire all'utente di comunicare con l'utente in modo loro specifici della locale. Da qui la chiamata a setlocale().

Mi auguro che essere facile da usare sarebbe senza controversie! Il problema, naturalmente, viene quando si tenta di analizzare i file di dati creati dal programma in esecuzione in una diversa localizzazione. Chiaramente, se si utilizza un formato basato su testo ad-hoc con un parser basato su sscanf e amici, piuttosto che un formato dati specificato con un parser "reale", allora questa è una ricetta per il danneggiamento dei dati se effettuata senza considerare il impostazioni locali. La soluzione è a) utilizzare una libreria di serializzazione reale che gestisce questa roba per te o b) impostare le impostazioni locali su qualcosa di specifico ("C" forse) durante la scrittura e la lettura dei dati.

Se la sicurezza del thread è un problema, sulle moderne implementazioni POSIX (o su qualsiasi sistema Linux con GNU libc version> = 2.3, che è praticamente "tutto di loro" in questo momento) è possibile chiamare uselocale() per impostare un locale locale thread per tutto l'I/O. In alternativa è possibile chiamare le versioni _l delle normali funzioni che accettano un oggetto locale come argomento supplementare.

Si interromperà tutto se chiami setlocale(LC_ALL, "C");? No, ma la cosa giusta è lasciare che l'utente imposti le impostazioni internazionali che preferiscono e salvare i dati in un formato ben specificato o specificare le impostazioni locali in cui i dati devono essere letti e scritti in fase di runtime.