[ leka @ 02.06.2002. 18:49 ] @
Ovaj maleni C kod sam napisao da vidim da li moze da se na ovaj nacin izvrsi provera da li je platforma bigendian ili littleendian:
Code:

#include <stdio.h>
#include <stdint.h>

int main(int argc, char** argv)
{
     uint8_t plop[4] = "\1\2\3\4";
    uint32_t i = *(uint32_t*) plop;
    if(i == 0x04030201)
        printf("bla\n");
    else
                printf("trutj\n");

    return 0;
}


I kod mene na Intel i Sun masinama radi...

Ako neko ima bolji kod nek ga podeli sa nama molim Vas!

Dejan
[ sspasic @ 02.06.2002. 21:55 ] @
Ja obicno koristim AC_C_BIGENDIAN autoconf makro kad god mogu. Tj. kad god mogu da koristim autoconf za projekat.
[ rivan @ 02.06.2002. 22:19 ] @
moze i ovako (mislim da je isto kao gore samo malo krace)
long x = 0x01020304;
if (*((char*)&x) == 1)
...
[ leka @ 04.06.2002. 18:11 ] @
Inace GLIB ima savrsenu foru tako da je za korisnika totalno transparentno koja je platforma u pitanju, ali sam za ovo kasno shvatio - ko me j*** kad nisam citao GLIB dokumentaciju. :)
[ leka @ 04.06.2002. 18:13 ] @
Ivane odlicno! :)
Inace onaj kod sam poslao i na news://news.linuks.org (user: linuks, pass: linuks), konferencija linuks.prg.c i niko se nije javio da ga komentarise... :(

Citat:
rivan:
moze i ovako (mislim da je isto kao gore samo malo krace)
long x = 0x01020304;
if (*((char*)&x) == 1)
...

[ Reljam @ 04.06.2002. 18:24 ] @
Citat:
leka:
Ivane odlicno! :)
Inace onaj kod sam poslao i na news://news.linuks.org (user: linuks, pass: linuks), konferencija linuks.prg.c i niko se nije javio da ga komentarise... :(

leka, mislim da je tvoja varijanta bolja: na intel platformi rad sa int-ovima je brzi od rada sa char-ovima, a pogotovu kada jedan podatak koji si upisao u kes kao int poksavas da vratis nazad kao char. Tako da je bolje raditi sa intovima. A takodje je i mnogo citljivije da se radi ono sto si ti uradio, da prvo sadrzaj prebacis u pomocnu promenljivu pa tek onda da ga ispitas u if-u. Prvo, em je citljivije, em ces lakse moci da vidis sta je program procitao u debageru, a ionako ce optimizer da to 'sredi', tako da stavljanje svega u isti red bez pomocnih promenljivih nije nista brze.
[ tOwk @ 09.06.2002. 23:33 ] @
Reljam, čini mi se da tvoji argumenti nisu baš na mestu.

Naime, ukoliko je kod namenjen da radi samo na Intel mašinama, mislim da je besmisleno i proveravati da nije slučajno big-endian. Prema tome, argument za brzinu otpada (a još ako uzmemo u obzir da se ovakav kod može pojaviti samo jednom u celom programu, pitanje njegove brzine je zaista od najmanje važnosti).


Drugi argument, argument o (ne)čitljivosti se razrešava podjednako lako: dodavanjem komentara u taj retki deo koda (kao što sam već konstatovao, svaki se program može napraviti da takvu proveru vrši maksimalno jednom, i da posle tu dobijenu vrednost stalno koristi; u tom slučaju možemo i promenljivoj little_end dodeliti onaj kod iz if uslova).

Što se tiče debug podrške, verujem da nećemo imati mnogo problema sa konkretno ovim kodom, i prema tome, ovakvo skraćenje je na mestu, i meni se više sviđa.

A ovo je i jedini način koji sam dosad video da ljudi koriste u raznim programima za testiranje upravo toga da li je računar big- ili little-endian (mada se nisam baš načitao mnogo izvornog koda, pa sigurno postoje i druge varijante).

Toliko.
[ Reljam @ 10.06.2002. 02:37 ] @
tOwk, sto se toga tice, ovaj kod se izvrsava samo jedanput po startovanju programa, tako da je potpuno svejjedno kako radi. Moze i da se vrti u petlji 10,000 puta, nece imati nikakvog efekta.

Ovo sve spada u domen akademske rasprave, medjutim postoji jedno mesto (meni poznato) gde je dobro znati ovakve stvari koje sam izneo (i uzgred, kod koji je citljiv sam po sebi je uvek bolji od koda koji je citljiv uz hipoteticki komentar):
Intervju za posao! Firma u kojoj radim daje i ovakva pitanja: daju ti jedan relativno jednostavan problem, i onda te pitaju sta bi promenio, optimizovao. Otprilike ovo sto sam rekao gore su neki od ocekivanih odgovora.

Eto tako malo ;)