Minden tiszteletem a tiétek, kisbetu, de a ‘bites vagy (|) ‘ használatával a kód mindig igazat ad, így használhatatlan az én olvasatomban. Vagy valamit tényleg félre nézek.  :rolleyes:
[align=right][snapback]138188[/snapback][/align]

Nézd, én gyûlölöm a C-t, assemblyben viszont elég jól elnavigálok.

00011111 VAGY 00000100 = 00011111
00011011 VAGY 00000100 = 00000000
ezzel megnéztem, hogy a 3. bit nulla-e

00011111

Köszi a hozzászólásokat.
Kicsit belebonyolódtam a kizáró vagyba. A lónak is 4 lába van…
Azt hiszem már írtam, nyugodtan javítsd ki kisbetu…
(Ja, talán szerencsésebb lett volna a bittenkénti logikai vagy kifejezés.)

„

Ja, ja igazad van az az és, amit kellene használni… (nekem meg a fejem, nemcsak evésre)
(Nem jött be ez a tegnapi nap :))

„hát ez itt nem is programozói verseny.”
Nem, nem. Az a lényeg, hogy végül kiderüljön az igazság :))))

Vérszagra gyûl az éji vad… 🙂

„az,hogy egy int típus hány bájtos az a cputól,fordítótól,oprendszertõl függ!!”
Kizárólag a fordítótól:

Pl. ezt win/*nix, 13/32/64 bites processzoron bármelyikén, ez a részlet
short int a;
_AX = a;

nézhet ki így, tök mindegy, hogy milyen vas, vagy os van alatta (32 bites szegmenssel):
…00: 0x0000
…02: 66 67 A1 …00 (mov ax, […00])
és ez már nem fog változni, semmilyen procin, mert gépikód – ilyet fog létrehozni a fordító és kész
(16 bites szegmenssel, 16 bites procin csak ez megy)
…02: A1 …00

aztán (32 bites szegmenssel):
long int a;
_EAX = a;
…00: 0x00000000
…04: A1 …00 (mov eax, […00])
(16 bites szegmenssel, 16 bites cpu-n ez sem futhat)
…04: 66 67 A1 …00

na ezzel valóban az a helyzet, hogy 16 bites processzoron nem fut, bár attól, lehetne az int/longint 32 bites, de sokkal nehezebben lehetne bánni vele, mivel nincs általános célú 32 bites regiszter
long int a;
…00: 0x00000000
…04: mov ax, […02]
……: mov dx, […04]

tehát csak praktikussági okokból van ez az int kavarás
(
– az int deffiniciót az általános regiszterek méretéhez igazították
– hogy miért?
– látod is a 66 67 miatt – amit az idétlen 16 bites kompatibilitás miatt van; mert ha a regiszter nem a természetes környezetében van (32 bites regiszter – 32 bites szegmens/ 16 bites regiszter – 16 bites szegmens), akkor az „elõcsalogatásához” + két byte-ra van szükség
– viszont mindenki szeret keveset írni, így egy 32 bites szegmensben egy 16 bites változót illetni a legrövidebb néven, a legnagyobb marhaság, mert erõforrás pazarló
)
de könyörgöm mutass már egy 16 bites processzorral ellátott pc-t? a 386-os processzor már 32 bites…
bár az igaz, hogy a windows a 98-as oprendszerrel bezárólag jórészt nem használta ki a 32 bites processzor elõnyeit, bár a legelsõ 32 bites processzoron, már alig-alig futott (ha futott egyátalán, 486-ra aszem még fel lehetett rakni); ezért egyes fordítókban maradt is az, hogy az int 16 bites…, de ezt már egyre kevesebb fordító használja
a gcc-ben pedig az int mindig 32 bites és azonos méretû, mint a long int, amíg a short int 16 bites, tök mindegy milyen rendszer alatt…
de, ha más fordítóval is ugyanazt a kódot kell elõállítani a short intet, vagy a long intet kell használni. az elõbbi mindig 16 bites, az utóbbi mindig 32 bites (ha jól tudom)

Nos, most már belátható, hogy a cpu-tól csak praktikussági okok miatt függhet(ne), de senki nem akar ma 16 bites cpu-val ellátott pc-re programot írni.
Aki pedig egy 386-os, vagy jobb arc.-ával ellátott gépen 16 bites os-t használ meg is érdemli.
De a lényeg az, hogy a fordító olyan gépikódot generál, amilyet akar. (Legfeljebb erõforrás pazarló lesz.)

ltoa…
char * ltoa ( long value, char * buffer, int radix );