NevemTeve blogja

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

 ( NevemTeve | 2017. június 15., csütörtök - 20:53 )

http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf

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

Mitől véd az O_NOFOLLOW?

 ( NevemTeve | 2017. május 27., szombat - 8:48 )

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.

samba-4.4.14 -- Már kezdtem megijedni...

 ( NevemTeve | 2017. május 26., péntek - 14:44 )

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

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

 ( NevemTeve | 2017. május 22., hétfő - 19:56 )

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.

WinSock beszámolóm

 ( NevemTeve | 2017. május 19., péntek - 14:39 )

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

 ( NevemTeve | 2017. május 12., péntek - 13:49 )

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?

 ( NevemTeve | 2017. május 5., péntek - 14:29 )

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

Eterm agya eldurrant?

 ( NevemTeve | 2017. április 26., szerda - 9:57 )

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

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

 ( NevemTeve | 2017. április 18., kedd - 11:25 )

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

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

 ( NevemTeve | 2017. április 5., szerda - 7:03 )

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

Oracle kliens UDP portot nyit

 ( NevemTeve | 2017. március 9., csütörtök - 13:56 )

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

OpenSSL is tud ám exportálni...

 ( NevemTeve | 2017. február 28., kedd - 12:54 )

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:

[code]
$ 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.

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

 ( NevemTeve | 2017. február 22., szerda - 20:14 )

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

Ez milyen haxor: GET /DeviceInformationX

 ( NevemTeve | 2017. február 17., péntek - 14:03 )

Ú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

 ( NevemTeve | 2017. február 16., csütörtök - 15:22 )

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)

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

 ( NevemTeve | 2017. február 7., kedd - 14:23 )

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");

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

 ( NevemTeve | 2016. október 30., vasárnap - 21:31 )

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.

[code]
$ 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

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

 ( NevemTeve | 2016. szeptember 15., csütörtök - 18:43 )

(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

firefox-ból is megárt a sok

 ( NevemTeve | 2016. szeptember 5., hétfő - 16:42 )

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

php-7.0.10 fordítása (AIX újabb kalandjai)

 ( NevemTeve | 2016. augusztus 31., szerda - 7:55 )

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

GeoClue -- i've no clue about it

 ( NevemTeve | 2016. augusztus 29., hétfő - 12:46 )

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.

iconv az iconv ellen (Kramer contra Kramer)

 ( NevemTeve | 2016. augusztus 19., péntek - 13:38 )

Pontosabban mondva: ha van egy /usr/local/include/iconv.h meg egy /usr/include/iconv.h,
akkor ki fog nyerni? Mondjuk egy PHP fordítás során?

Nyilván az egyik a libc része (libc6-dev), a másik a külön telepített libiconvé.

Gondolom, az természetes, hogy semerről sem kompatibilisek... a libc ilyen szimbóleumokat exportál:
iconv
iconv_close
iconv_open

a /usr/local/lib/libiconv.so meg ilyeneket:
_fini
_init
_libiconv_version
iconv_canonicalize
libiconv
libiconv_close
libiconv_open
libiconv_open_into
libiconv_set_relocation_prefix
libiconvctl
libiconvlist

Emlékeztető: mit is kell megkérdezni a panaszos ügyféltől.

 ( NevemTeve | 2016. augusztus 12., péntek - 23:07 )

Nevét.
Telefonszámát.
Beosztását.
Saját maga tapasztalta-e a hibát, vagy másvalaki? Utóbbi esetben át tudná adni az illetőnek a telefont?
Saját maga hogyan sorolná be a gondját: hibabejelentés, segítségkérés, jogosultsági/bejelentkezési probléma, fejlesztési/változtatási igény, egyedi lekérdezés/feldolgozás kérése [pl.: Pistának hívják és Balmazújvárosban lakik, mi a telefonszáma?], egyéb.
Helyi rendszergazdával beszélt már? Miért nem?
Mikor működött utoljára? (Ha egyáltalán.)
Azóta mit telepítettek?

OpenSSL-1.1.0 elközeleg

 ( NevemTeve | 2016. augusztus 11., csütörtök - 14:30 )

De tényleg, előbb-utóbb kell vele foglalkozni. Egyelőre az 1.1.0-pre6 próbálható ki.

Bizonyos jelek [lásd a Makefile-t] arra utalnak, hogy a fejlesztők úgy képzelik, hogy az 1 a major verziószám és az 1.0-pre6 a minor. (Vagy csak az 1, és a .0-pre6 nem is számít. Legalábbis a shared object nevébe nem kerül bele.)

Namostan ezt mérések nem támasztják alá, default fordítás után:
[code]
# readelf -d /usr/local/lib64/libssl.so
0x000000000000000e (SONAME) Library soname: [libssl.so.1.1]

detencode -- mi a gond vele?

 ( NevemTeve | 2016. augusztus 10., szerda - 10:46 )

Ugye az alapgondolat zseniális: írjuk bele a fájl elején kommentbe a fájl kódolását, pl:

/* HelloVilag.java */
/* encoding: ISO-8859-2 */

Aztán valahogy így fordítsunk:

$ javac -encoding $(detencode HelloVilag.java) HelloVilag.java
# javac -encoding ISO-8859-2 HelloVilag.java -- ez lesz belőle

Ez így csudállatiasan jó.

Lenne.