NevemTeve blogja

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.25. 17:02
Ez lett belőle: https://midnight-commander.org/ticket/3843

2017.07.25. 14:58
Pédául ezt a sort lehetne meghaxolni, hogy UTF-8 esetén már 128-tól szíveskedjen unikódolni:

edit.c:3359         if (char_for_insertion > 255 && !mc_global.utf8_display)

2017.07.25. 12:25
Van egy ilyen rész benne (miután lenyomtam egy 'é'-t):

charsets.c:474	    res = g_unichar_to_utf8 (input_char, (char *) str);

p/x input_char => 0xffffffe9
p   res        => 6
p/x str        => {0xff, 0xbf, 0xbf, 0xbf, 0xbf, 0xa9, 0x0}

Látunk-e itt hibát?!

TL;DR: a gcc a zavaró játékos, az /opt/freeware/lib/gcc/powerpc*/*/include-fixed alatt kell törölni a string.h-t.

Eredeti szöveg:

Ezt kéri tőlem az apr-util. Nyilván egy derék komputer-tudós áttörést ért el a 'memóriaterületek feltöltése konstans byte-tal' nevű tudományterületén, és annak követésére kellett ez a fejlesztés. No, mindjárt utánanézek.

Szerk: Csodállatias. Mindössze egy handlert kell beállítani (ONERRORGOTO stílusban), és máris könnyedén kezelhetjük a hibát. Persze mindenki (minden programrész) átállíthatja a handlert, tehát ha biztosra akarunk menni, minden egyes xyzuvw_s függvény előtt kell. Persze így is ezerszer egyszerűbb, mint egy if-et tenni oda.

Szóval amire én rászaladtam 2016-ban, azt valaki már 2005-ben jelezte, csak elsikkadt...

http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submissio…

Még csak belepillantottam, de jónak tűnik.

Szerk: pl. ilyesmiről hallottam a usenet sötét zugaiban: ha 'p' pointer esetleg lehet NULL, akkor pl. a strnlen(p,0) vagy a memcmp(p,q,0) is UB, tehát az optimalizáló akármit is generálhat oda, akár szándékosan rosszat is.

Kieg: itten van például ez a clang-os teszt
[code]
printf ("sin_addr at %d\n",
(int)offsetof (struct sockaddr_in, sin_addr.s_addr));

warning: using extended field designator is an extension [-Wextended-offsetof]

Amit értek: megnyitnám a "/fontos/outputfile"-t írásra, de aggódom, hogy a haxor esetleg odatett egy /fontos/outputfile nevű szimlinket, ami a /etc/passwd-re mutat. Mondjuk neki nincs írási joga a /etc/passwd fájlra, de nekem van, és ezzel rávesz, hogy tegyek kárt a fájlban.

Vagy lehet az egy érvénytelen symlink, amit ha megnyitok írásra, akkor ott hozok létre egy fájlt, ahol nem akartam.. és mondjuk elhasználom a lemezhelyet, vagy információ jut ki a gépből (ha mondjuk az egy NFS-en felmountolt lemezhely), stb.

Nyilván lehetne a megnyitás előtt tájékozódni (lstat(2)), de a gonosz haxor a lstat és az open között is változtathat a helyzeten. Az open után meg már késő a fstat(2), ha mondjuk egy jó kis O_RDWR|O_CREAT|O_TRUNC volt a nyitási mód.

samba-4.4.14 -- Már kezdtem megijedni, hogy csak úgy ukk-mukk-fukk lefordul, de szerencsére megállt itt: [2342/3334] Compiling source3/smbd/open.c

A múltkor panaszoltm a netkit-telnetd-re, de most van jó hír is: AIX-on nem hajlandó fordulni, mert hogy:

checking for BSD signal semantics... no
This package needs BSD signal semantics to run.

Abban bizakodom, hogy van valahol a /usr/lib-ben valami jó kis kompatibility-library pont az ilyen kőkorszakbeli termékek részére...

Szerk: Van, a neve libbsd.a, csak nagy ravaszul nem a LDFLAGS-ba, hanem a CXXFLAGS-ba kell betenni, hogy -lbsd'

Szerk: Továbbá 'ncurses' helyett 'curses' van AIX-on. Most épp a 'forkpty' hiányzik neki. Folyt. köv.

Később: Na, összecsaptam egy házi libutil-t, hadd örüljön. Talán sírva halálkodott? Csodát, most meg valami featúrákat hiányol!

In file included from commands.cc:67:0:
externs.h:44:22: fatal error: features.h: No such file or directory
 #include <features.h>

Mondjuk a ws2_32.dll nevű terméket szeretnénk használni, és ehhez az implib/impdef nevű komponenseket használnák. Három függvényre próbából rábökve ezt látom XP/32-n és Windows 7/64/SysWow64-en:

A C++ keze betette a lábát... Értem, hogy a hülyeségnek győznie kell az értelem felett, de hogy az AIX-on is ennyire előre tart ez a folyamat... egy localtime_r-ből indultunk, de hogy abból hogy lett C++ ?!

Szerk: Elnézést, ha nem volt világos: a programhibát nem localtime (vagy az abból hívott valamelyik komponens) okozza, csupán csak azt akartam mondani, hogy eddig boldog tudatlanságban éltem, nem tudtam erről a C++-os betüremkedésről...

Rögtön kezdetnek itt van a lehetőség, hogy a readline-t is frissítsük 7.0-ra (ne felejtsük el a patch-eket.)

Aztán itt kiderül, hogy ez a verzió már pluginokat is tud, examples/loadables néven. A linkelésüket a következő nagyon tudományos módszerrel végezné:

ld -bdynamic -bnoentry -bexpall -maix64 -Wl,-brtl -Wl,-blibpath

Vagyis ügyes szervezéssel a gcc-nek szóló LDFLAGS-t is odacsapta a ld parancssora végére, hátha az AIX!ld tud gcc-ül is. De nem. Viszont a gcc sem tud AIX!ld nyelven, tehát símán lecserélni sem lehet. Köszönjük, Emese.

Mármint megjelenik egy ablak, csak mintha shell nem futna benne. strace következtik. Annyit máris látok, hogy a végén le akarja zárni a világ összes fájlját, close(43123) -nál leállítottam.

ii  eterm 0.9.6-1 amd64 Enlightened Terminal Emulator

Mint tudjuk. A gcc fordításának alapja pedig a gcc. Először is a gcc kitermel magából egy proto-gcc-t, és aztán azzal az igazit. Esetünkben ilyesmi hibával akadunk meg:

../../.././libgcc/config/i386/sfp-exceptions.c:52:7: error: 'asm' undeclared (first use in this function)
       asm volatile ("%vdivss\t{%0, %d0|%d0, %0}" : "+x" (f));

Ez olyasmit próbál jelenteni, hogy a gcc elfelejtett szólni a gcc-nek, hogy valamilyen asm-ot is támogató -std-opció kellene... Nyilván az én hibám;)

Naszóval, ha a CFLAGS-ot, CXXFLAGS-ot LDFLAGS-ot üresre állítom, akkor rendben lefordul a gcc-4.9.4; lesz benne -m32/-m64, az utóbbi a default. Na most jön a nagy kérdés: rá merem-e küldeni az AIX-ra?

Van a gcc-nek egy -finput-charset nevű opciója, gondoltam, kipróbálom a másodgyártó termékében is az érdekesség kedvéért, hát még nem százszázalékos a siker...

clang -v
Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM 3.5.0)
...
clang: error: invalid value 'latin2' in '-finput-charset=latin2'
clang: error: invalid value 'ISO-8859-2' in '-finput-charset=ISO-8859-2'
clang: error: invalid value 'ISO-8859-1' in '-finput-charset=ISO-8859-1'

Akkor most egy leírás kellene, hogy az UTF-8-on kívül mi az, amit elfogad...

Szerk: Itten van írásba foglalva

2017.03.09. 14:24
Na ezt kell mondani a gdb!configure-nak, hogy a hétköznapi értelemhez közelebb álló működést kapjunk:

./configure ... \
        CC=gcc                  CXX=gcc                 \
        CFLAGS="$CFLAGS"        CXXFLAGS="$CFLAGS"      \

2017.03.09. 13:18
Az egyik gépen, ahol a tesztelni akartam volna, nem volt gdb. Letöltöttem a legújabb gdb-t (7.12.1), elküldtem fordulni, és most mintha azt látnám, hogy g++-szal akar fordítani. Reméljük, sima napszúrás, mert akkora bajt még nem láttam, amit C++-szal ne lehetett volna sokkal rosszabbá tenni.

Ja, exportál az OpenSSL lelkesen, mint egy fejlődő ország, ami kemény valutára vágyik.
Kicsit megfékeztem a lelkesedését, itt a jutalmam:

$ ssh
exec(): 0509-036 Cannot load program ssh because of the following errors:
        0509-130 Symbol resolution failed for ssh because:
        0509-136   Symbol memcpy (number 207) is not exported from
                   dependent module /usr/local/lib64/libcrypto.so.1.0.2.
        0509-136   Symbol memset (number 208) is not exported from
                   dependent module /usr/local/lib64/libcrypto.so.1.0.2.
        0509-136   Symbol strcmp (number 209) is not exported from
                   dependent module /usr/local/lib64/libcrypto.so.1.0.2.
        0509-136   Symbol memmove (number 210) is not exported from
                   dependent module /usr/local/lib64/libcrypto.so.1.0.2.

2018.04.06. 04:06
Ezt most minek néztem meg?!

[308]   0x00000000    undef      IMP     RW EXTref /opt/lib64/libclntsh.so.10 __tab
[309]   0x00000000    undef      IMP     RW EXTref /opt/lib64/libclntsh.so.10 __itab
[310]   0x00000000    undef      IMP     RW EXTref /opt/lib64/libclntsh.so.10 guesses
[311]   0x00000000    undef      IMP     RW EXTref /opt/lib64/libclntsh.so.10 tantab

Szerk: relax, én bénáztam, a 10-es még gyárilag oké, 11-től jött be a '-bexpall', ezt a tizest én rontottam el. A hibát érzékeltetendő ezt a kettőt nézzük össze: explist explist_so

Újabb nyomoznivalóm támadt: ki és miért kérdezgeti az Apache-tól, hogy DeviceInformationX

I.P.v.4 - - [14/Feb/2017:12:01:47 +0100] "GET /DeviceInformationX HTTP/1.1" 404 302

Nyilván valami segítő, felügyelő, megkönnyítő, távvezérlő alkalmazás lesz ez is... Már most az erőforrások több mint felét ilyenekre használjuk, de ez folyamatosan növekszik...

2017-02-16.14:22
Azt mondja szegény:

libtool: compile: gcc -DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 -IZend/ -I/usr/local/src/php-7.0
In file included from /usr/local/src/php-7.0.16/Zend/zend.h:39:0,
                 from /usr/local/src/php-7.0.16/Zend/zend_ini_parser.y:25:
/usr/local/src/php-7.0.16/Zend/zend_ini_parser.y: In function 'yydestruct':
/usr/local/src/php-7.0.16/Zend/zend_variables.h:122:57: error: expected identifier before
 #define zval_ptr_dtor(zval_ptr) _zval_ptr_dtor((zval_ptr) ZEND_FILE_LINE_CC)

ha ebből nem látszana tisztán, ezt akarja fordítani: php-7.0.16/Zend/zend_ini_parser.c

Például azért nem, mert Windows XP-ben nincs ilyen. Na mindegy, gondoltam, gyorsan összecsapok valamit, és Linuxon tesztelem: összehasonlítom a saját verziót a gyárival.

Jó stréber módjára tesztprogram készítésével kezdtem, abban rögtön egy inet_pton függvénnyel, a főprogramban valami ilyesmi:

    Test1 (AF_INET,  "127.1");
    Test1 (AF_INET,  "127.0.0.1");
    Test1 (AF_INET6, "1234:5678::abcd:ef01");

Hát természetesen az inet_pton (AF_INET, "127.1") nem működik. Manuál is írja: csak négy decimális számot fogad el. inet_aton("127.1") persze működik. Csak elavult. Helyette az inet_pton ajánlatos. Remélem, édesanyjuk nem csuklik ilyenkor.

Egyszerűbben mondva, egy kis kompatibilitási kérdés: ha van egy fájlunk, aminek a dátuma 2016-10-30 00:30:00 UTC, akkor milyen időt ír a 'ls' a 'TZ' függvényében (no meg persze az OS(pl AIX) verzió függvényében). Annyit előrebocsátok, hogy 01:00 UTC-kor kellene legyen az átállítás, tehát az a dátum még nyáriidő-beli.

$ TZ=CET-1CEST,M3.5.0,M10.5.0 ls -l ~/tmp/utc30-00:30
Oct 30 01:30 /home/projects/tmp/utc30-00:30

$ TZ=CET-1CEST,M3.5.0/2,M10.5.0/3 ls -l ~/tmp/utc30-00:30
Oct 30 02:30 /home/projects/tmp/utc30-00:30

$ TZ=Europe/Budapest ls -l ~/tmp/utc30-00:30
Oct 30 02:30 /home/projects/tmp/utc30-00:30

(Felülről lefelé bővül)

20160918.1947
Oszt úgy tűnik, nem különbözik. Akkor mi ez a kavarás a refcounter refaktorálásával, ami miatt az oci8 működése vagy nem-működése a hívó jóindulatának függvényévé válik?

És még itt van az a kérdés (bár itt off-topik), hogy hogyan van a NCHAR-ok támogatása... van egy olyan tippem, hogy sehogy, vagyis ami belefér a NLS_CHARACTERSET és a NLS_LANG metszetébe, az jól jár, a többi megy a levesbe.

20160918.1934
Namost ha ez így igaz, akkor akár az alábbi kód is másképp működhet php5-ben és php7-ben:

$a= 100;
$aref= &$a;
$a= 'stringvalue';
xdebug_debug_zval ('$a');
xdebug_debug_zval ('$aref');

Például:

about:config-ban

network.dns.disableIPv6 := true
network.http.speculative-parallel-limit := 0
browser.safebrowsing.enabled := false
browser.safebrowsing.malware.enabled := false
services.sync.prefs.sync.browser.safebrowsing.enabled := false
services.sync.prefs.sync.browser.safebrowsing.malware.enabled := false

/etc/hosts-ban

127.0.0.1 incoming.telemetry.mozilla.org

Kieg:

toolkit.telemetry.shutdownPingSender.enabled := false

(Felülről lefelé bővül)

20160908.1240
Itten van írásba foglalva (komoly tolongásra azért nem számítok): https://bugs.php.net/bug.php?id=73002#1473330938

20160908.1135
Az a hülye ötletem támadt, hogy alaposabban tesztelem a fejlesztésemet... Nem kellett volna, bugra szaladtam a "csak-be" típusú bind-változóknál.

Ha ez a saját programocskám lenne, akkor a 'php_oci_bind' struktúrából a 'dummy_len' című mezőt kiszedném, és helyette 'maximum_length', 'in_length' és 'out_length' mezőket csinálnék, plusz egy jelzőt, hogy hívódott-e a 'bind_out_callback'.

20161007.1127
Ma leszedtem a 'dleyna-renderer' és 'dleyna-server' nevű komponenseket. Kár értük, jó ügynökök voltak.

20160909.1216
Szintén kitörlöm a /etc/passwd-ből, /etc/group-ból és /var/lib/dpkg/statoverride-ból.

20160909.1207
Nem jó, apt-get bedurcizik a hiánya miatt. Akkor újratelepítem, és kézileg törlöm a fájljait.

Miért van nekem ilyen geoclue a debian8-amban? Persze nyilván ezrével vannak komponensek, amiknek nem értem a jelentőségét, de legalább ezt most leszedem, aztán megnézem, összedől-e a ház...