NevemTeve's blog

IIS 7.5 -- Valami 48K

Ugyebár ez nem jó, ami valami, az harminc, nem pedig 48 KB.

Valahogy 'hozzápiszkálódott' az IIS konfigjához (csakis a marsklakók lehettek, mert mindenki más tagad (még a Windows Update-ot is gyanusítom)), és emiatt valamilyen 48 KB -s korlát lett a POST-méretére (kidebuggoltam 49152 még ok, 49153 már nem)

Valamilyen SOAP-os ASP.NET-es okosság is van a történetben, csak hogy érdekesebb legyen.

Nagy utazás -- dbuson

Na jó, semmi komoly, csak arra lennék kíváncsi, hogy hogy került az AIX-omra egy /usr/local/etc/bash_completion.d/gdbus-bash-completion.sh nevű fájl?

Valaki arra készül, hogy egyszer talán majd dbus lesz az AIX-on? Vagy így akarjuk átrázni a kémeket? Persze csak azokat, akik nem ismerik az uname-t?

Szerk:
A glib volt. Az telepítette a gdbus nevű programmal együtt. Mindjárt szétnézek, van-e valahol egy kis systemd is..

php7: Nincsen nekije alloca

Mármint eddig nem hiányzott neki, de most hiányzik. Az --enable-mbstring óta. Csak azért zavar ez az alloca, mert emlékezni vélek, hogy erre már rászaladtam valamikor... Nyilván utólag majd teljesen kézenfekvő lesz a dolog. Mondjuk nem volt include-álva az alloca.h, pedig kellett volna. Vagy include-álva volt, de nem kellett volna. Vagy balkézzel kellett volna lenyomni az Enter-t a ./configure-hoz. Szóval valami teljesen érthető hibát követtem el.

Szerk: google nevű varázseszköz megtalálta: https://hup.hu/node/115430#comment-1527342

Szerk: linker elárulta, ezek a problémás komponensek:
ext/mbstring/oniguruma/regexec.c
ext/mbstring/oniguruma/regcomp.c

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.

mc - már megint nem értek valamit

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?!

memset_s -- ez mi ez?

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.

Olvasmány fordító-optimalizáció ügyében

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]

Mitől véd az O_NOFOLLOW?

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.

netkit-telnetd elavulta magát -- de most jön a jó hír

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>

A C++ keze betette a lábát...

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...

bash-4.4 -- mi a fejlődés tárgya?

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.

A jó tervgazdálkodás alapja a jó tervgazdálkodás

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?

Én vagyok hülye, vagy a clang görbe?

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

Oracle kliens UDP portot nyit

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.

OpenSSL is tud ám exportálni...

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.

[Megoldva] apache/openssl -- valami baj van a certificate-tel

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

Ez milyen haxor: GET /DeviceInformationX

Ú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...

php-7.0.16 nem fordul -- előfordul az ilyen

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

Az 'inet_ntop' sem fenékig tejfel...

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.

What time(zone) it is? (TZ enviro)

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

Legszebb öröm a káröröm

(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');