Elmeorvosi kivizsgálásomat kérem gcc-ügyben...

2017.07.30. 15:10
Legyen meg írásban is: http://web.axelero.hu/lzsiga/ekezet.html#Q0168

2017.07.28. 06:34
No, megnyugodtam, kényelmes gumiszobában meditálhattam, és arra jutottam, hogy az -finput-charset az az, amiről a preprocesszor UTF8-ra konvertál. Mindent. Nem csak az L", u", U", u8" stringeket, hanem mindent. A szoftver segít.

Ha ezt nem akarjuk, akkor ne használjuk ezt az opciót; vagy használjuk a -fexec-charset opciót is, ugyanezzel az értékkel. Ennek [vagyis mindkét opció használatának] akkor van érteleme, ha a forrásprogramban van hagyományos string is, és megvariált (L", u", U", u8") string is -- az előbbiek maradnak, ahogy voltak, az utóbbiak UTF-N-re konvertálódnak.

2017.07.27. 18:18
Elnézést kérek a rágalmazásért. Valójában a cpp csak továbbadja a munkát ennek a programnak:
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.4/cc1

2017.07.27. 11:20
A mérések szerint a cpp nevű program csinálja. Folyt. köv.

Eredeti topiknyitó
Nyilván fantomot kergetek, de úgy tűnik nekem, hogy a gcc-m egy "\xC5\x91" stringliterálból "\xC4\xB9\xC2\x91" szekvenciát generált az Assembly-be...

Szerk: illetve nem az x-szekvenciával van baj, hanem a "sima" ékezetes betűkkel: 


$ xd fantom.c
       0: 23 69 6e 63  6c 75 64 65  20 3c 73 74  64 69 6f 2e  #include <stdio.
      10: 68 3e 0a 0a  76 6f 69 64  20 54 65 73  74 49 6e 73  h>..void TestIns
      20: 33 20 28 76  6f 69 64 29  3b 0a 0a 76  6f 69 64 20  3 (void);..void 
      30: 54 65 73 74  49 6e 73 33  20 28 76 6f  69 64 29 0a  TestIns3 (void).
      40: 7b 0a 20 20  20 20 70 72  69 6e 74 66  20 28 22 68  {.    printf ("h
      50: c5 91 73 5c  78 63 35 5c  78 39 31 6b  5c 6e 22 29  Ĺ.s\xc5\x91k\n")
      60: 3b 0a 7d 0a                                         ;.}.

A stringben két 'ő' van, az első literál (utf8), a másik \x-szekvencia.

A hibajelenség (ha ez hiba egyáltalán) az, hogy a -finput-charset-től függően az ő literálból négy byte lesz az Assembly-ben. 


-finput-charset=ISO-8859-2:
.string "h\304\271\302\221s\305\221k"

-finput-charset=UTF-8:
.string "h\305\221s\305\221k"

Arról már értesültem, hogy vannak olyan string-típusok (L", u", U", u8"), ahol a fordítóprogramnak figyelembe kell vennie a forrásprogram kódolását, és arról konvertálni valamire (wchar_t, UTF-16, UTF-32, UTF-8), de ez most csak olyan sima, fékezett habzású "stringliterál".