Android

In the darkest hour on Mon, 7 Feb 2011 07:11:11 +0100, Lelek@ snipped-for-privacy@nndn.pl screamed:

Tak na szybko...

byte[] buf = ...?

Dnia 07-02-2011 o 08:26:16 Artur M. Piwko snipped-for-privacy@buziaczek.pl napisał(a):

Też jestem zwolennikiem takiego zapisu, ale to raczej nie może być przyczyną problemów. Proponuję:

1. sprawdzić jak zachowuje się odczyt z tablicy deklarowanej statycznie jaki private.
2. czyścić/zerować tablicę tworzoną dynamicznie przed jej odczytem
3. używać normalnego słownictwa bo aż człowieka skręca czyta "casting" zamiast "rzutowanie"

zaznaczam, że nie znam androidowego SDK ani ichniejszej maszyny wirtualnej, to są jedynie luźne pomysły (za wyjątkiem pkt3 :))

Ju¿ wiem co jest. Ten bufor nie istnieje je¿eli nic siê tam nie wpisze i próba odczytu buf[0] bez wcze¶niejszego wpisania czego¶ skutkuje totaln± wywa³k± tak jakby wyskakiwa³ wyj±tek nie wiadomo od czego. To jest java, a nie C++ co mnie bardzo denerwuje, szczególnie brak "unsigned" - to jest ju¿ totalna pora¿ka. Ta java to takie C++ dla pó³g³ówków, którzy mieli problem ze zrozumieniem wska¼ników, struktur i wykonywania kodu :-) Tragedia ale nie ma wyj¶cia.

Rzutowanie to rzutowanie, wymienic odpowiedzialnych autorow ktorzy zastosowali do C :)

P.S. Casting ? Odlewanie. I nie mamy na mysli egzaminu dla aktorek :-)

J.

W dniu 2011-02-07 12:39, Lelek@ pisze:

Pewnie wynika to z optymalizacji - alokacja zasobów dopiero przy pierwszym dostępie. W sumie niezły bat na "specjalistów" od niezainicjalizowanych zmiennych :-).

W dniu 2011-02-07 07:11, Lelek@ pisze:

int X = (int)buf; lub int X = (int)&(buf[0]);

byte Y = (byte)(buf+2);

tak lepiej?

Nie znam sdk Androida, ale dolary przeciw kamieniom, że błąd jest zupełnie gdzie indziej niż Ci się wydaje. Ta tablica powinna się automatycznie wypełnić zerami i jak najbardziej bufor istnieje.

W dniu 2011-02-07 07:11 Lelek@ napisał(a):

Zobacz co pokazuje LogCat. Tam będzie informacja dlaczego program się wywalił.

BTW: NTG?

Nie wiem co to jest LogCat :-) Od kilku dni się tym zajmuję :-). Wiem jedno, że ten buf[256] zapełniam wpisując w niego null terminated string. I jeżeli czytam poza długością wpisanego stringa to zawsze jest ten efekt ale dziwi mnie czemu mimo zadeklarowania rozmiaru on tak to traktuje. To zachowanie ma miejsce tylko dla byte. dla int tablica istnieje. Obszedłem to ale weź sobie zapodaj w kodzie takie dwie linijki, jedna deklaracja i niżej Y = buf[10] i skompiluj i uruchom. Wywałka murowana gdziekolwiek nie postawisz byle się wykonało.

W dniu 2011-02-08 00:16 Lelek@ napisał(a):

Wygląda na to, że byłem pierwszy, który to sprawdził doświadczalnie. Takie linijki dodałem na końcu onCreate w głównej mojej klasie dziedziczącej po Activity:

byte buf[] = new byte[256]; byte y = buf[10]; Log.d("TEST", "WARTOSC Y=" + String.valueOf(y));

Sprawdzałem w emulatorach 1.5 oraz 2.2. W obu przypadkach zachowanie jest identyczne i przewidywalne. Świeżo alokowany blok 256 bajtów jest standardowo wypełniony zerami i to widzę w LogCat:

Program się nie wywalił i działa normalnie. Może masz wywałkę z innego powodu...

Powiem ci, że nie mam pojęcia :-) byte y = buf[10]; Ta linijka mi załatwia sprawę :-)

Jeszcze wrócę do sprawy jutro :-) Nie daje mi to spokoju :-)

Opakuj tę linijkę w blok try/catch i zobacz czy coś się złapie. Jak wejdziesz w obsługę wyjątku, to znaczy że ta linijka bruździ. Jeśli dalej się będzie wywalać, to znaczy że co problem jest gdzieś indziej.

pzdr. j.

Jest tam jakas opcja wydruku w "assemblerze" ? Moze sie cos ujawni .

J.

W dniu 2011-02-09 00:02 J.F. napisał(a):

W Javie? Zawsze możesz zrobić disassemblację pliku classes.dex z wewnątrz instalki apk. Ale pewnie dużo się nie wyjaśni dopóki Lelek nie napisze, co mu LogCat wywala przy tym błędzie.

In the darkest hour on Wed, 09 Feb 2011 00:02:54 +0100, J.F <jfox snipped-for-privacy@poczta.onet.pl> screamed:

Da się zobaczyć jak kod wygląda na poziomie byte kodu.

Skoro ta dyskusja trwa dalej, to zanim się wytoczy takie armaty, można byłoby poprosić autora wątku o kompilowalny kawałek kodu który ma sprawiać takie problemy? Z opisu, z pierwszej wiadomości, można podejrzewać że program rzuca coś w rodzaju segfaulta a nie wyjątek. Nie wierzę w to jakoś, jeśli nie ma tam żadnego odwołania do JNI.

public void dupa() { byte buf[] = new byte[256]; int bfx[] = new int[256]; int i, len;

buf = FromEditText.getBytes("UTF-8");

len = buf.length;

for (i = 0; i < len; i++) {bfx[i] = ((int)buf[i] & 0xFF);}

// tu dalej kod ale niezwi±zany

Je¿eli w polu EditText nic nie wpiszê, bêdzie puste to próba odczytania buf[0] skoñczy siê wywa³k±. Pêtle for mo¿na wywaliæ do testów nie chodzi o jej warunek < len. Pêtlê doda³em pó¼niej

Zabezpieczy³em to tak:

if (len != 0) { for (i = 0; i < len; i++) {bfx[i] = ((int)buf[i] & 0xFF);} }

to mi wyglada na jak±¶ cholern± optymalizacjê garbage collecrion czy co¶ takiego w czasie wykonywania, ¿e nie je¿eli buf = zamiana zawarto¶co pola wide charów UTF16 na UTF8 na bajty daje tylko null to tablica nie powstaje

ale jak wpiszê choæby jeden znak konwertuj±cy siê na 1 bajt w utf8 to mogê czytaæ dowolny element tablicy bez wywa³ki.

Chodzi o to, ¿e je¶li to: buf = FromEditText.getBytes("UTF-8"); nie bêdzie mia³o czego czytaæ w polu bo nic w nie nie wpiszê

to byte Y = buf[0} czy int Y = (int)buf[0]

zamyka program "przys³owiowy ble screen" i do widzenia zamyka aplikacjê