2014-11-04 2 views
5

Sto trasferendo un'applicazione utilizzando char* per tutto e ovunque per utilizzare UCS4 come rappresentazione Unicode interna. Uso C11 U"unicode literals" per la definizione delle stringhe, che si espandono agli array di char32_t, che sono essenzialmente uint32_t.Come usare correttamente `__attribute __ ((format (printf, x, y)))` per C11 U "letterali unicode"?

Problema con annotazione corretta delle funzioni printf -like. Siccome "format" non è più char*, il compilatore rifiuta di compilarlo ulteriormente, così come non sarà contento di char32_t * invece del char * per il formato %s, suppongo.

Non dipende affatto dalla famiglia stdlib *printf, quindi la formattazione viene eseguita esclusivamente dall'implementazione della mia.

Qual è la soluzione corretta per questo, oltre a disabilitare completamente questo attributo?

+0

Una domanda secondaria: quale vantaggio si ritiene di ottenere dall'uso di UTF-32 anziché UTF-8? E sei proprio sicuro che ne valga la pena? (Anche UTF-32 ha glifi multi-codepoint.) – Deduplicator

+1

La mia applicazione funziona esclusivamente su codepoint, quindi non ho davvero alcun motivo per me di considerare graft cluster, caratteri percepiti dall'utente e così via. UCS4 semplifica enormemente l'elaborazione delle stringhe come al momento, poiché posso riutilizzare la maggior parte della base di codice esistente e migrerò la rappresentazione interna in UTF8 nella prossima iterazione. – toriningen

+0

Anche a me sembra mancare il punto di "U" ... "" roba, sembra un passaggio complicato, in particolare dal momento che C11 aggiunge solo un supporto minore per gestirli. Potresti semplicemente usare la notazione '" \ u2002 "per implementare tutti i punti di codice Unicode di cui hai bisogno come mbs. Per la domanda in sé, dovresti probabilmente chiedere direttamente alla gente di gcc. Questo non è molto comune, quindi hai davvero bisogno della loro esperienza sulla domanda. –

risposta

1

Attualmente non esiste alcun modo per farlo in GCC. Si tratta di un bug noto, vedere GCC bug 64862

+1

Grazie mille per l'aggiornamento! Qualche informazione simile su clang forse? – toriningen