---

Hej,

Jeg sidder her med et lille problem... jeg har gjort det gør men kan
simpelthen ikke huske hvordan.

Jeg har en buffer:

unsigned char _FF_Buf[512];

Nu vil jeg så gerne fange nogle unsigned int's fra den buffer. Og det
kan gøres med type casts jeg kan bare ikke huske syntaxen.

MyInt = (unsigned int) _FF_Buf+index;

Kan nogen hjælpe mig her?

Mvh
Jan Thogersen

---

Jan Thogersen wrote:
> Jeg sidder her med et lille problem... jeg har gjort det gør men kan
> simpelthen ikke huske hvordan.
>
> Jeg har en buffer:
>
> unsigned char _FF_Buf[512];
>
> Nu vil jeg så gerne fange nogle unsigned int's fra den buffer. Og det
> kan gøres med type casts jeg kan bare ikke huske syntaxen.
>
> MyInt = (unsigned int) _FF_Buf+index;
>
> Kan nogen hjælpe mig her?

MyInt = (unsigned int) _FF_Buf[index];

vil konvertere en unsigned char til en unsigned int

MyInt = *((unsigned int *) &_FF_Buf[index]);

vil konvertere et antal unsigned chars til en
unsigned int

ARne

---

[ Arne Vajhøj ]

[ ... ]

> > Jeg har en buffer:
> >
> > unsigned char _FF_Buf[512];

[ ... ]

> MyInt = *((unsigned int *) &_FF_Buf[index]);
>
> vil konvertere et antal unsigned chars til en unsigned int


Nei.





ivr
--
"...but it's HDTV -- it's got a better resolution than the real world."
       -- Fry, "When aliens attack"

---

Igor V. Rafienko wrote:
> [ Arne Vajhøj ]
>> MyInt = *((unsigned int *) &_FF_Buf[index]);
>>
>> vil konvertere et antal unsigned chars til en unsigned int
>
> Nei.

Jo.

Den sætning flytter et antal bytes fra en adresse i
memory der af C opfattes som et antal unsigned chars til det samme
antal bytes på en anden adresse i memory som af C opfattes
som en en unsigned integer.

Hvad der præcis sker afhænger af om int er 2 eller 4 eller
8 byte og fortolkningen af resultatet afhænger af om maskinen
er little eller big endian.

Arne

---

[ Arne Vajhøj ]

[ ... ]

> > > MyInt = *((unsigned int *) &_FF_Buf[index]);
> > >
> > > vil konvertere et antal unsigned chars til en unsigned int
> >
> > Nei.
>
> Jo.


Nei.


> Den sætning flytter et antal bytes fra en adresse i memory der af C
> opfattes som et antal unsigned chars til det samme antal bytes på en
> anden adresse i memory som af C opfattes som en en unsigned integer.


Nei, det gjør den aldeles ikke.

$ cat end.c
int
main()
{
unsigned char buf[10] = { 0 };

return *((unsigned int*) &buf[1]);
}
$ gcc end.c
$ ./a.out
Bus Error
$

Dagens trivia -- hvorfor skjer dette?

Løsningen med shift / multiplikasjon er den eneste portable. Hverken C
eller C++ garanterer fornuftige resultater med forslaget med typecast.





ivr
--
"...but it's HDTV -- it's got a better resolution than the real world."
       -- Fry, "When aliens attack"

---

Igor V. Rafienko wrote:
> Nei, det gjør den aldeles ikke.
>
> $ cat end.c
> int
> main()
> {
> unsigned char buf[10] = { 0 };
>
> return *((unsigned int*) &buf[1]);
> }
> $ gcc end.c
> $ ./a.out
> Bus Error
> $
>
> Dagens trivia -- hvorfor skjer dette?
>
> Løsningen med shift / multiplikasjon er den eneste portable. Hverken C
> eller C++ garanterer fornuftige resultater med forslaget med typecast.

Fordi du kører på en lidt gammeldags processor formentlig
en SPARC som ikke kan lide unaligned integers.

Men det er da en relevant pointe som jeg havde glemt alt om
(det er mange år siden jeg sidst har set det problem).

Arne

---

[ Arne Vajhøj ]

[ ... ]

> Fordi du kører på en lidt gammeldags processor formentlig en SPARC
> som ikke kan lide unaligned integers.


Eh, verden er ikke x86. En rekke platformer enten krever eller kan
kjøres med alignmentbegrensninger.

Men det er egentlig på siden av saken -- selv på en platform uten
alignmentkrav er ikke typecast garantert å fungere. Det finnes nemlig
ingen typecasts som kan brukes her.

[ ... ]





ivr
--
"...but it's HDTV -- it's got a better resolution than the real world."
       -- Fry, "When aliens attack"

---

Den Sat, 08 Apr 2006 18:25:37 -0400 skrev Arne Vajhøj:
> Igor V. Rafienko wrote:
>>
>> Dagens trivia -- hvorfor skjer dette?
>>
>> Løsningen med shift / multiplikasjon er den eneste portable. Hverken C
>> eller C++ garanterer fornuftige resultater med forslaget med typecast.
>
> Fordi du kører på en lidt gammeldags processor formentlig
> en SPARC som ikke kan lide unaligned integers.

"Lidt gammeldags"?

Er en CPU nu gammeldags hvis den ikke er opstået ved at klytte 32-bit
instruktioner ovenpå en uheldig blanding af en 16-bit og 8-bit CPU
der vist nok er bagudkompatibel med den oprindelige 4-bit Intel 4004?

Det er ikke fordi det er en fordel med unaligned access at Intel
CPU'er kan det, faktisk gør de fleste compilere hvad de kan for at
undgå det, for det er langsomt. Det er fordi at hvis man fjernede
muligheden, ville man få problemer med bagudcompatibiliteten med
gode gamle 16- og 8-bit programmer.

> Men det er da en relevant pointe som jeg havde glemt alt om
> (det er mange år siden jeg sidst har set det problem).

Kom ud af 8-bit bagudkompatibilitets-verdenen, så vil du se det i
stribevis.

Hvad med Itanium - Intels "Nu har vi fået nok af det her gamle
lort, lad os lave en moderne CPU", hvordan tror du den har det med
unaligned Access?

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Den Sat, 08 Apr 2006 18:25:37 -0400 skrev Arne Vajhøj:
>> Fordi du kører på en lidt gammeldags processor formentlig
>> en SPARC som ikke kan lide unaligned integers.
>
> "Lidt gammeldags"?
>
> Er en CPU nu gammeldags hvis den ikke er opstået ved at klytte 32-bit
> instruktioner ovenpå en uheldig blanding af en 16-bit og 8-bit CPU
> der vist nok er bagudkompatibel med den oprindelige 4-bit Intel 4004?

Lidt modificeret version af en gammel anti-MS vits.

Men Alpha og PPC matcher vist ikke beskrivelsen.

> Det er ikke fordi det er en fordel med unaligned access at Intel
> CPU'er kan det, faktisk gør de fleste compilere hvad de kan for at
> undgå det, for det er langsomt. Det er fordi at hvis man fjernede
> muligheden, ville man få problemer med bagudcompatibiliteten med
> gode gamle 16- og 8-bit programmer.

Der er ikke nogen 8 bit mode i x86.

Jeg kan ikke umiddelbart se nogen grund til at man ikke skulle
kunne tillade unaligned data access i 16 bit mode og ikke tillade
det i 32 bit mode. Data tilgang er jo i forvejen total forskellig.

Så det kan vist ikke være forklaringen. Snarere noget med
service overfor programmørerne.

>> Men det er da en relevant pointe som jeg havde glemt alt om
>> (det er mange år siden jeg sidst har set det problem).
>
> Kom ud af 8-bit bagudkompatibilitets-verdenen, så vil du se det i
> stribevis.

M68K (undtagen første generation), x86, VAX, Alpha,
PPC (for integer) kan alle håndtere unaligned data.

Det er kun SPARC, PA og MIPS af de klassiske
processor arkitekturer som ikke kan håndtere
unaligned data.

(og jeg har primært kodet på 64 bit systemer siden 1994)

> Hvad med Itanium - Intels "Nu har vi fået nok af det her gamle
> lort, lad os lave en moderne CPU", hvordan tror du den har det med
> unaligned Access?

Itanium er lidt speciel derved at den bruger et mix af
hardware og software meget a la support for virtual memory.

Linux og OpenVMS håndterer unaligned data access.

Af årsager ukendt for mig gør Windows 64 bit det ikke
default (man skal kalde SetErrorMode med SEM_NOALIGNMENTFAULTEXCEPT).

[og jeg skal ikke forsøge at gøre mig klog på HP-UX's
uransagelige verden]

Arne

---

Den Sun, 09 Apr 2006 19:47:08 -0400 skrev Arne Vajhøj:
> Kent Friis wrote:
>> Den Sat, 08 Apr 2006 18:25:37 -0400 skrev Arne Vajhøj:
>>> Fordi du kører på en lidt gammeldags processor formentlig
>>> en SPARC som ikke kan lide unaligned integers.
>>
>> "Lidt gammeldags"?
>>
>> Er en CPU nu gammeldags hvis den ikke er opstået ved at klytte 32-bit
>> instruktioner ovenpå en uheldig blanding af en 16-bit og 8-bit CPU
>> der vist nok er bagudkompatibel med den oprindelige 4-bit Intel 4004?
>
> Lidt modificeret version af en gammel anti-MS vits.

Ja.

> Men Alpha og PPC matcher vist ikke beskrivelsen.

Alpha var vel nærmest bygget til WinNT, så det kan ikke overraske. Hvad
IBM og Motorolas undskyldning er ved jeg ikke.

>> Det er ikke fordi det er en fordel med unaligned access at Intel
>> CPU'er kan det, faktisk gør de fleste compilere hvad de kan for at
>> undgå det, for det er langsomt. Det er fordi at hvis man fjernede
>> muligheden, ville man få problemer med bagudcompatibiliteten med
>> gode gamle 16- og 8-bit programmer.
>
> Der er ikke nogen 8 bit mode i x86.

Men dog AL/AH osv registrene, der lugter ret meget derhendad.

> Jeg kan ikke umiddelbart se nogen grund til at man ikke skulle
> kunne tillade unaligned data access i 16 bit mode og ikke tillade
> det i 32 bit mode. Data tilgang er jo i forvejen total forskellig.
>
> Så det kan vist ikke være forklaringen. Snarere noget med
> service overfor programmørerne.

Compileren har altså været opfundet i mange år, så den tror jeg ikke
på. Specielt ikke på en CPU-arkitektur der har ry for at være så
programmør-fjendtlig som x86.

>>> Men det er da en relevant pointe som jeg havde glemt alt om
>>> (det er mange år siden jeg sidst har set det problem).
>>
>> Kom ud af 8-bit bagudkompatibilitets-verdenen, så vil du se det i
>> stribevis.
>
> M68K (undtagen første generation), x86, VAX, Alpha,
> PPC (for integer) kan alle håndtere unaligned data.
>
> Det er kun SPARC, PA og MIPS af de klassiske
> processor arkitekturer som ikke kan håndtere
> unaligned data.

Hvor passer POWER ind?

> (og jeg har primært kodet på 64 bit systemer siden 1994)
>
>> Hvad med Itanium - Intels "Nu har vi fået nok af det her gamle
>> lort, lad os lave en moderne CPU", hvordan tror du den har det med
>> unaligned Access?
>
> Itanium er lidt speciel derved at den bruger et mix af
> hardware og software meget a la support for virtual memory.
>
> Linux og OpenVMS håndterer unaligned data access.
>
> Af årsager ukendt for mig gør Windows 64 bit det ikke
> default (man skal kalde SetErrorMode med SEM_NOALIGNMENTFAULTEXCEPT).

Underlig arkitektur.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Den Sun, 09 Apr 2006 19:47:08 -0400 skrev Arne Vajhøj:
>> Men Alpha og PPC matcher vist ikke beskrivelsen.
>
> Alpha var vel nærmest bygget til WinNT, så det kan ikke overraske. Hvad
> IBM og Motorolas undskyldning er ved jeg ikke.

Nope.

Alpha blev lavet til DEC OSF/1 og VMS.

Windows NT supporten kom senere.

I forbindelse med Windows NT supporten tilføjede
de nogle instruktioner til Alpha arkitekturen (jeg er
dog ikke klar over om det var nødvendigt for at NT kunne
køre eller kun nødvendigt for typiske Windows applikationer
performede godt).

>> M68K (undtagen første generation), x86, VAX, Alpha,
>> PPC (for integer) kan alle håndtere unaligned data.
>>
>> Det er kun SPARC, PA og MIPS af de klassiske
>> processor arkitekturer som ikke kan håndtere
>> unaligned data.
>
> Hvor passer POWER ind?

POWER = PPC

Den håndterer unaligned integers, men ikke unaligned
floating point.

>> Itanium er lidt speciel derved at den bruger et mix af
>> hardware og software meget a la support for virtual memory.
>>
>> Linux og OpenVMS håndterer unaligned data access.
>>
>> Af årsager ukendt for mig gør Windows 64 bit det ikke
>> default (man skal kalde SetErrorMode med SEM_NOALIGNMENTFAULTEXCEPT).
>
> Underlig arkitektur.

Itanium er faktisk på mange måder en anderledes
men spændende arkitektur.

Arne

---

Igor V. Rafienko wrote:
> Løsningen med shift / multiplikasjon er den eneste portable.

Bemærk at i portabilitets perspektiv gør shift/multiplikation
ikke det samme som den cast gør (eller forsøger at gøre).

Hvis man vil have samme funktionalitet på en sikker måde
er det nemmeste sikkert memcpy.

Arne

---

[ Arne Vajhøj ]

[ ... ]

> > Løsningen med shift / multiplikasjon er den eneste portable.
>
> Bemærk at i portabilitets perspektiv gør shift/multiplikation ikke
> det samme som den cast gør (eller forsøger at gøre).


Det er ingen grunn til å anta at typecast vil virke, da
språkdefinisjonen ikke krevere denne oppførselen.

En skift / multiplikasjonsløsning er, så vidt jeg ser, den eneste
portable.


> Hvis man vil have samme funktionalitet på en sikker måde er det
> nemmeste sikkert memcpy.


.... Da forutsetter du at en int har den eksakt samme
bitrepresentasjonen som N chars plassert etter hverandre. Den
antagelsen finner jeg intet grunnlag for i standarden.





ivr
--
"...but it's HDTV -- it's got a better resolution than the real world."
       -- Fry, "When aliens attack"

---

Igor V. Rafienko wrote:
> [ Arne Vajhøj ]
>> Bemærk at i portabilitets perspektiv gør shift/multiplikation ikke
>> det samme som den cast gør (eller forsøger at gøre).
>
> Det er ingen grunn til å anta at typecast vil virke, da
> språkdefinisjonen ikke krevere denne oppførselen.

C standarden kræver ikke at det virker.

Det virker så tilfældigvis på det store flertal af computere.

Men hvis du læser hvad jeg skrev i parentesen, så snakker
jeg kun om hvad folk der skriver den slags kode vil forvente
at koden gør.

Nu er det naturligvis muligt at du tror at folk skriver koden, sådan
for at få undefined behaviour, men jeg tror altså at folk skriver
koden sådan for at flytte det antal bits der er i en int.

>> Hvis man vil have samme funktionalitet på en sikker måde er det
>> nemmeste sikkert memcpy.
>
> ... Da forutsetter du at en int har den eksakt samme
> bitrepresentasjonen som N chars plassert etter hverandre. Den
> antagelsen finner jeg intet grunnlag for i standarden.

Nej.

Og netop derfor vil memcpy nok være bedst (mest portable) i
de fleste tilfælde !

Hvis sizeof(int) bytes "indeholder" en int, så er det langt
mere sandsynligt at de char indeholder bit mønsteret for int
end nogle numerisk konverterede værdier. Fordi de skal
jo også derind på et tidspunkt.

Det var dog ikke derfor jeg skrev hvad jeg skrev. Bitmønsteret skal
nok passe på alle gængse computere.

Men multiplikation/shift bruger fixed endianess, mens memcpy
bruger host endianess.

Og da den af programmøren tilsigtede virkning af cast
vil bruge host endianess, så matcher memcpy bedre.

Og endianess er et virkeligt problem.

Arne

---

[ Arne Vajhøj ]

[ ... ]

> Det virker så tilfældigvis på det store flertal af computere.


Right. Omtrent som i eksempelet mitt.

[ ... ]


> Og netop derfor vil memcpy nok være bedst (mest portable) i
> de fleste tilfælde !


Nei. (Fx. når data i char-arrayen er representasjonen av heltall i en
annen endianess).


> Hvis sizeof(int) bytes "indeholder" en int, så er det langt mere
> sandsynligt at de char indeholder bit mønsteret for int end nogle
> numerisk konverterede værdier. Fordi de skal jo også derind på et
> tidspunkt.


Og dette sannsynlighetsutsagnet er basert på ... ?

[ ... ]


> Men multiplikation/shift bruger fixed endianess, mens memcpy bruger
> host endianess.


Hva *er* det du snakker om? memcpy() har intet begrep om endianess i
seg. Den vil bare flytte bytes fra en adresse til en annen. Når tallet
som ligger i char-arrayet er i samme endianess som platformen iøvrig,
er det bare å kopiere bytes rått (slik som memcpy gjør). Men, som sagt
tidligere, det trenger ikke å være tilfellet.

memcpy() vil virke bedre enn det horrible typecast-hacket, da man
kommer seg rundt alignmentproblematikk. Men det vil fremdeles være
utilstrekkelig.


> Og da den af programmøren tilsigtede virkning af cast vil bruge host
> endianess, så matcher memcpy bedre.


Det er bare fjas.

Den eneste måten å gjøre en slik konvertering på, er å avtale på
forhånd hva denne char-arrayen representerer og i hvilken rekkefølge.

Når denne protokollen er på plass, *kan* det hende at memcpy() passer.
Men det trenger ikke å være tilfellet. Og når endianess av det som
ligger i char-arrayen er fastsatt, er det enklere (da det vil virke på
alle platformer) å komponere sluttresultatet med
skift/multiplikasjon/or[1]. Dette er en generalisering av det som
htonl()/ntohl() paret hjelper å løse.

Siden OP unnlot å spesifisere denne protokollen, er det enkleste å
ikke gjøre noen antagelser om hva som er sannsynlig. Hverken typecast
eller memcpy() er veien å gå (fordi det første ikke virker, og det
andre vil gi feil resultat).

[ ... ]





ivr
[1] jeg tror jeg retter det til "de nødvendige operasjonene". Er
det noen reserverte bits i implementasjonen, vil de måtte settes til
bestemte verdier før sluttresultatet kan leveres.
--
"...but it's HDTV -- it's got a better resolution than the real world."
       -- Fry, "When aliens attack"

---

Igor V. Rafienko wrote:
> [ Arne Vajhøj ]
>> Det virker så tilfældigvis på det store flertal af computere.
>
> Right. Omtrent som i eksempelet mitt.

Ked af at måtte fortælle dig det men flertallet af computere
kører altså windows/x86 ikke solaris/sparc.

>> Hvis sizeof(int) bytes "indeholder" en int, så er det langt mere
>> sandsynligt at de char indeholder bit mønsteret for int end nogle
>> numerisk konverterede værdier. Fordi de skal jo også derind på et
>> tidspunkt.
>
> Og dette sannsynlighetsutsagnet er basert på ... ?

Det kræver mindst kode at skovle en int ind as is.

Gennemsnitsprogrammøren er mageligt anlagt.

>> Men multiplikation/shift bruger fixed endianess, mens memcpy bruger
>> host endianess.
>
> Hva *er* det du snakker om? memcpy() har intet begrep om endianess i
> seg. Den vil bare flytte bytes fra en adresse til en annen. Når tallet
> som ligger i char-arrayet er i samme endianess som platformen iøvrig,
> er det bare å kopiere bytes rått (slik som memcpy gjør). Men, som sagt
> tidligere, det trenger ikke å være tilfellet.
>
> memcpy() vil virke bedre enn det horrible typecast-hacket, da man
> kommer seg rundt alignmentproblematikk. Men det vil fremdeles være
> utilstrekkelig.

Pointen er at typecast hacket flytter med host endianess.

Det samme gør memcpy.

Multiplikation/shift flytter med en fixed endianess.

Derfor er memcpy nok det mest ekvivalente til typecast hacket.

>> Og da den af programmøren tilsigtede virkning af cast vil bruge host
>> endianess, så matcher memcpy bedre.
>
> Det er bare fjas.
>
> Den eneste måten å gjøre en slik konvertering på, er å avtale på
> forhånd hva denne char-arrayen representerer og i hvilken rekkefølge.

Der er sikert en masse man kunne gøres smartere.

Man kunne have en protokol med en fixed endianess.

Måske kunne man bruge en struct.

Man kunne også sige at det var langt nemmere at bruge C# BinaryReader
eller Java DataInputStream.

O.s.v..

Det ændrer jo ikke på at memcpy gør det samme som typecast hacket
og at multiplikation/shift ikke gør det.

Jeg finder det lidt grotesk at man i en diskussion om portabilitet
uden at blinke foreslår at man ændrer koden fra host endianess til
fixed endianess.

Arne

---

Arne Vajhøj wrote:
> Ked af at måtte fortælle dig det men flertallet af computere
> kører altså windows/x86 ikke solaris/sparc.

Jeg tror du glemmer at tælle embeddede systemer med. I det projekt jeg
arbejder på har vi ca. 12 processorer hvor kun én er en x86 (80186
kompatibel) og ingen kører Windows.

Ivan Johansen

---

Ivan Johansen wrote:
> Arne Vajhøj wrote:
>
>> Ked af at måtte fortælle dig det men flertallet af computere
>> kører altså windows/x86 ikke solaris/sparc.
>
>
> Jeg tror du glemmer at tælle embeddede systemer med. I det projekt jeg
> arbejder på har vi ca. 12 processorer hvor kun én er en x86 (80186
> kompatibel) og ingen kører Windows.

Hvad er det "embeddede systemer" dækker over? Nu er jeg stødt på den
formulering et par gange, uden at vide hvad det er... Er det noget
linux-halløj?


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Den Tue, 11 Apr 2006 14:45:40 +0200 skrev Martin Jørgensen:
> Ivan Johansen wrote:
>> Arne Vajhøj wrote:
>>
>>> Ked af at måtte fortælle dig det men flertallet af computere
>>> kører altså windows/x86 ikke solaris/sparc.
>>
>>
>> Jeg tror du glemmer at tælle embeddede systemer med. I det projekt jeg
>> arbejder på har vi ca. 12 processorer hvor kun én er en x86 (80186
>> kompatibel) og ingen kører Windows.
>
> Hvad er det "embeddede systemer" dækker over? Nu er jeg stødt på den
> formulering et par gange, uden at vide hvad det er... Er det noget
> linux-halløj?

Det er alt det der ikke er en rigtig computer.

Fx en mobiltelefon eller styredimsen i en vaskemaskine...

"Embedded" ~ "inde i".

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

[ Arne Vajhøj ]

[ ... ]

> Ked af at måtte fortælle dig det men flertallet af computere kører
> altså windows/x86 ikke solaris/sparc.


1) Nei, mesteparten av computere kjører ikke windows/x86, men vi lar
nå dette ligge (hvor mange mobiltelefoner er det per en stasjonær
PC i verden?)

2) Ja, det er flere windows/x86 bokser enn Sun solaris. Hva så?
Typecastforslaget ditt er like defekt uansett hva dette forholdet
måtte være.


[ Arne Vajhøj ]
> Hvis sizeof(int) bytes "indeholder" en int, så er det langt mere
> sandsynligt at de char indeholder bit mønsteret for int end nogle
> numerisk konverterede værdier. Fordi de skal jo også derind på et
> tidspunkt.

[ ivr ]
> Og dette sannsynlighetsutsagnet er basert på ... ?

[ Arne Vajhøj ]
> Det kræver mindst kode at skovle en int ind as is.
>
> Gennemsnitsprogrammøren er mageligt anlagt.


Hva med å slutte å gjøre antagelser det ikke er grunnlag for og heller
foreslå en løsning som vil bare virke på alle platformer?

[ ... ]


> > Den eneste måten å gjøre en slik konvertering på, er å avtale på
> > forhånd hva denne char-arrayen representerer og i hvilken
> > rekkefølge.
>
> Der er sikert en masse man kunne gøres smartere.
:
> Man kunne også sige at det var langt nemmere at bruge C#
> BinaryReader eller Java DataInputStream.


Fra C? Neppe.


> Det ændrer jo ikke på at memcpy gør det samme som typecast hacket og
> at multiplikation/shift ikke gør det.


Nei, memcpy() gjør ikke det samme som typecast-hacket, slik beskrevet
tidligere.


> Jeg finder det lidt grotesk at man i en diskussion om portabilitet
> uden at blinke foreslår at man ændrer koden fra host endianess til
> fixed endianess.


Jeg finder det temmelig grotesk at i en diskusjon om portabilitet
kommer du med forslag som vil knekke i helt trivielle situasjoner, og
attpåtil prøver du å forsvare slike defekte liksomløsninger. Men vi
har vel krav hver på eget synspunkt.





ivr
--
"...but it's HDTV -- it's got a better resolution than the real world."
       -- Fry, "When aliens attack"

---

Igor V. Rafienko wrote:
>> Ked af at måtte fortælle dig det men flertallet af computere kører
>> altså windows/x86 ikke solaris/sparc.

> 2) Ja, det er flere windows/x86 bokser enn Sun solaris. Hva så?
> Typecastforslaget ditt er like defekt uansett hva dette forholdet
> måtte være.

Det er ca. 8-10 indlæg jeg erkendte den fejl.

Men kun 2-3 indlæg siden du mente at kunne modbevise
påstanden om de fleste computere med at dit Solaris
eksempel - hvilket jo enten var totalt irrelevant
eller måtte være baseret på en antagelse om at Solaris/SPARC
er mere udbredt end Windows/x86.

>> Det ændrer jo ikke på at memcpy gør det samme som typecast hacket og
>> at multiplikation/shift ikke gør det.
>
> Nei, memcpy() gjør ikke det samme som typecast-hacket, slik beskrevet
> tidligere.

memcpy gør det som programmøren der vil bruge typecast hacket
vil.

>> Jeg finder det lidt grotesk at man i en diskussion om portabilitet
>> uden at blinke foreslår at man ændrer koden fra host endianess til
>> fixed endianess.
>
> Jeg finder det temmelig grotesk at i en diskusjon om portabilitet
> kommer du med forslag som vil knekke i helt trivielle situasjoner, og
> attpåtil prøver du å forsvare slike defekte liksomløsninger. Men vi
> har vel krav hver på eget synspunkt.

Snakker du om typecast haclet eller memcpy ?

Arne

---

[ Arne Vajhøj ]

[ ... ]

> Men kun 2-3 indlæg siden du mente at kunne modbevise påstanden om de
> fleste computere med at dit Solaris eksempel - hvilket jo enten var
> totalt irrelevant eller måtte være baseret på en antagelse om at
> Solaris/SPARC er mere udbredt end Windows/x86.


Huh?

Eksempelet mitt var ment å illustrere at:

"MyInt = *((unsigned int *) &_FF_Buf[index]);

vil konvertere et antal unsigned chars til en unsigned int"

.... var feil. Denne påstanden *er* feil. Det var *alt* jeg skulle
illustrere. Ikke noe mer. I så måte er det totalt irrelevant hva som
er forholdet mellom x86 og SPARC arkitekturene.

For det andre, så har jeg aldri nevnt SPARC. *Du* har begynt å gnåle
om det. Jeg har ikke tenkt å stå for *dine* utsagn, det må du klare på
egenhånd.

[ ... ]


> > > Det ændrer jo ikke på at memcpy gør det samme som typecast
> > > hacket og at multiplikation/shift ikke gør det.
> >
> > Nei, memcpy() gjør ikke det samme som typecast-hacket, slik
> > beskrevet tidligere.
>
> memcpy gør det som programmøren der vil bruge typecast hacket vil.


.... som er fremdeles annerledes enn typecast-hacket. Du har jo
allerede fått et eksempel på det!

La meg legge frem en dårlig forenkling: på en elendighetsskala fra 0
til 10, der 10 betyr "virker" og alt under "5" er en klar kandidat til
dailywtf, kan man trygt spre forslagene slik:

0 10
rå typecast memcpy manuell sammensetting av tallet

memcpy _er_ et skritt i riktig retning, men det skrittet er ikke langt
nok. Vil du ha forklart _en gang til_ hvorfor?

[ ... ]


> > Jeg finder det temmelig grotesk at i en diskusjon om portabilitet
> > kommer du med forslag som vil knekke i helt trivielle situasjoner,
> > og attpåtil prøver du å forsvare slike defekte liksomløsninger.
> > Men vi har vel krav hver på eget synspunkt.
>
> Snakker du om typecast haclet eller memcpy ?


Her er kjernen til problemet: *begge* er defekte.





ivr
--
"...but it's HDTV -- it's got a better resolution than the real world."
       -- Fry, "When aliens attack"

---

Den 12 Apr 2006 16:25:35 +0200 skrev Igor V. Rafienko:
>
> La meg legge frem en dårlig forenkling: på en elendighetsskala fra 0
> til 10, der 10 betyr "virker" og alt under "5" er en klar kandidat til
> dailywtf, kan man trygt spre forslagene slik:
>
> 0 10
> rå typecast memcpy manuell sammensetting av tallet
>
> memcpy _er_ et skritt i riktig retning, men det skrittet er ikke langt
> nok. Vil du ha forklart _en gang til_ hvorfor?

Jeg tror efterhånden vi alle savner en forklaring på hvorfor memcpy
ikke duer til at flytte et antal bytes i host byte order over i en int.

Og næste spørgsmål bliver så hvordan man skriver portabel kode med
shifts til at flytte et antal bytes i host byte order over i en int.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

"Kent Friis" <nospam@nospam.invalid> wrote in message
news:443d16a7$0$15794$14726298@news.sunsite.dk...

[8<8<8<]
> Jeg tror efterhånden vi alle savner en forklaring på hvorfor memcpy
> ikke duer til at flytte et antal bytes i host byte order over i en int.

Det dur (i C++ kun for POD typer).
Det er meget omhyggeligt specificer et at det dur - og så vidt jeg
umiddelbart ved det eneste der dur.
I C++ Standarden (C++98) er det beskrevet i §3.9-2.
I C Standarden (C99 draft) er det beskrevet i §6.2.6.1

Venlig hilsen

Mogens Hansen

---

[ Kent Friis ]

[ ... ]

> Jeg tror efterhånden vi alle savner en forklaring på hvorfor memcpy
> ikke duer til at flytte et antal bytes i host byte order over i en
> int.


*Når* sa OP noe om endianess eller representasjonen av int'ene som lå
i dette char-arrayet? For å eksemplifisere: i denne nettverksalderen
kunne slike int'er godt ha vært sendt over nettverket, lest vha.
read() inn i et char-array, og så oppstår det et behov for å
tolke verdien.

*Men* siden OP *unnlot* å si noe som helst om representasjonen, er det
uhyre teit å spekulere om hva man kanskje muligens skulle hatt behov
for og basere et løsningsforslag på slike antagelser.


> Og næste spørgsmål bliver så hvordan man skriver portabel kode med
> shifts til at flytte et antal bytes i host byte order over i en int.


.... såsnart OP forteller hvordan disse int'ene er representert i
minne.





ivr
--
"...but it's HDTV -- it's got a better resolution than the real world."
       -- Fry, "When aliens attack"

---

Den 12 Apr 2006 21:10:40 +0200 skrev Igor V. Rafienko:
> [ Kent Friis ]
>
> [ ... ]
>
>> Jeg tror efterhånden vi alle savner en forklaring på hvorfor memcpy
>> ikke duer til at flytte et antal bytes i host byte order over i en
>> int.
>
>
> *Når* sa OP noe om endianess eller representasjonen av int'ene som lå
> i dette char-arrayet?

Det gjorde han ikke, og derfor kan vi ikke antage hverken det ene
eller det andet.

Men det du svarede på var en påstand om at memcpy var en brugbar
løsning ved host byte order. Og det er her uenigheden opstår, når
du siger memcpy ikke duer.

Der er ingen der har sagt den var brugbar ved network byte order.

> For å eksemplifisere: i denne nettverksalderen
> kunne slike int'er godt ha vært sendt over nettverket, lest vha.
> read() inn i et char-array, og så oppstår det et behov for å
> tolke verdien.

Blandt typiske Windows-udviklere, er de stadig i host byte order. Derfor
kan du ikke antage hverken det ene eller det andet.

> *Men* siden OP *unnlot* å si noe som helst om representasjonen, er det
> uhyre teit å spekulere om hva man kanskje muligens skulle hatt behov
> for og basere et løsningsforslag på slike antagelser.

Derfor blev løsningen med memcpy præsenteret som løsningen på
problem A, og shifts som løsning på problem B. Så kan han jo vurdere
om det er problem A eller B han forsøger at løse.

Det kan han så bare ikke alligevel, for der er jo nogen der siger
at alle løsningsforslag på problem A ikke duer, og så står han med
kun en løsning på problem B, og indtryk af at problem A slet ikke
kan løses.

>> Og næste spørgsmål bliver så hvordan man skriver portabel kode med
>> shifts til at flytte et antal bytes i host byte order over i en int.
>
> ... såsnart OP forteller hvordan disse int'ene er representert i
> minne.

Nå, må vi andre nu ikke stille spørgsmål? Eller kræver du en ny tråd
per tillægsspørgsmål?

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

[ Kent Friis ]

[ ... ]

> > *Når* sa OP noe om endianess eller representasjonen av int'ene som
> > lå i dette char-arrayet?
>
> Det gjorde han ikke, og derfor kan vi ikke antage hverken det ene
> eller det andet.


Nettopp.


> Men det du svarede på var en påstand om at memcpy var en brugbar
> løsning ved host byte order. Og det er her uenigheden opstår, når du
> siger memcpy ikke duer.


Jeg ser ikke noe reservasjon om endianess i
<news:%4h_f.1474$EA3.307@dukeread10>, gjør du det? Og endianess er
bare en liten del av problemet, nettopp fordi det er *så* mange måter
å representere et tall på.

memcpy vil virke, når man *internt* i programmet gjør int -> char[] ->
int konverteringen. *Alt* det andre kan ofte virke, men *trenger* ikke
det.

[ ... ]


> Blandt typiske Windows-udviklere, er de stadig i host byte order.
> Derfor kan du ikke antage hverken det ene eller det andet.


Det er derfor man lager seg protokoller for å representere data sendt
over nettverket. Når det er fastsatt, er det ingenting mer "å anta".

[ ... ]


> Det kan han så bare ikke alligevel, for der er jo nogen der siger at
> alle løsningsforslag på problem A ikke duer, og så står han med kun
> en løsning på problem B, og indtryk af at problem A slet ikke kan
> løses.


*Hvem* påstod noe slikt her?

[ ... hvordan skrive portabel kode for char[] -> int ]


> Nå, må vi andre nu ikke stille spørgsmål?


Jeg venter kun på int-represntasjonen til OP. Dersom du vet hva
han/hun ville, for all del, spesefiser det.


> Eller kræver du en ny tråd per tillægsspørgsmål?


Nei. Alt jeg vil vite er representasjonen av int'er i char[]. Om det
skulle være en ny tråd av det er egentlig temmelig likegyldig.





ivr
--
"...but it's HDTV -- it's got a better resolution than the real world."
       -- Fry, "When aliens attack"

---

Den 13 Apr 2006 12:29:14 +0200 skrev Igor V. Rafienko:
> [ Kent Friis ]
>
> [ ... ]
>
>> > *Når* sa OP noe om endianess eller representasjonen av int'ene som
>> > lå i dette char-arrayet?
>>
>> Det gjorde han ikke, og derfor kan vi ikke antage hverken det ene
>> eller det andet.
>
>
> Nettopp.
>
>
>> Men det du svarede på var en påstand om at memcpy var en brugbar
>> løsning ved host byte order. Og det er her uenigheden opstår, når du
>> siger memcpy ikke duer.
>
>
> Jeg ser ikke noe reservasjon om endianess i
> <news:%4h_f.1474$EA3.307@dukeread10>, gjør du det? Og endianess er
> bare en liten del av problemet, nettopp fordi det er *så* mange måter
> å representere et tall på.

Det er underforstået i "Hvis man vil have samme funktionalitet". Da
cast'en (i de tilfælde hvor den virker) er host byte order.

Det kunne måske have været tydeligere, men jeg er ikke i tvivl om at
det skulle forstås sådan.

> memcpy vil virke, når man *internt* i programmet gjør int -> char[] ->
> int konverteringen. *Alt* det andre kan ofte virke, men *trenger* ikke
> det.
>
>> Blandt typiske Windows-udviklere, er de stadig i host byte order.
>> Derfor kan du ikke antage hverken det ene eller det andet.
>
> Det er derfor man lager seg protokoller for å representere data sendt
> over nettverket. Når det er fastsatt, er det ingenting mer "å anta".

Sålænge vi ikke kender protokollerne, kan vi ikke andet end antage (og
spørge).

> [ ... ]
>
>
>> Det kan han så bare ikke alligevel, for der er jo nogen der siger at
>> alle løsningsforslag på problem A ikke duer, og så står han med kun
>> en løsning på problem B, og indtryk af at problem A slet ikke kan
>> løses.
>
>
> *Hvem* påstod noe slikt her?

Alle de forslag der indtil videre er kommet med host byte order (cast,
memcpy) gav du indtryk af var ubrugelige.

> [ ... hvordan skrive portabel kode for char[] -> int ]
>
>> Nå, må vi andre nu ikke stille spørgsmål?
>
> Jeg venter kun på int-represntasjonen til OP. Dersom du vet hva
> han/hun ville, for all del, spesefiser det.

Jeg ved det ikke, men jeg kunne stadig godt tænke mig at vide hvordan
du mener det bør gøres.

>> Eller kræver du en ny tråd per tillægsspørgsmål?
>
> Nei. Alt jeg vil vite er representasjonen av int'er i char[]. Om det
> skulle være en ny tråd av det er egentlig temmelig likegyldig.

Viden om hvordan OP's protokol ser ud ændrer ikke på mit tillægs-
spørgsmål.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

[ Kent Friis ]

[ ... ]

> > *Hvem* påstod noe slikt her?
>
> Alle de forslag der indtil videre er kommet med host byte order
> (cast, memcpy) gav du indtryk af var ubrugelige.


* "Alle de forslag der indtil videre er kommet" != "alle
løsningsforslag på problem A".

* Ingen påstod at problemet ikke kunne løses.

[ ... ]


> > Jeg venter kun på int-represntasjonen til OP. Dersom du vet hva
> > han/hun ville, for all del, spesefiser det.
>
> Jeg ved det ikke, men jeg kunne stadig godt tænke mig at vide
> hvordan du mener det bør gøres.


En gang til, siden det var uklart den første gangen: jeg venter kun på
int-representasjonen til OP. Dersom du vet hva han/hun ville, for all
del, spesifiser det.

*Med mindre* en slik spesifikasjon foreligger, er det umulig å svare
på spørsmålet.

Ser du /nå/ hva som mangler?

[ ... ]


> Viden om hvordan OP's protokol ser ud ændrer ikke på mit tillægs-
> spørgsmål.


Stemmer. Og det mangler fortsatt en liten bit, hvis jeg skal kunne
foreslå noe kode. Hva er det som mangler?





ivr
--
"...but it's HDTV -- it's got a better resolution than the real world."
       -- Fry, "When aliens attack"

---

Den 13 Apr 2006 19:42:18 +0200 skrev Igor V. Rafienko:
> [ Kent Friis ]
>
> [ ... ]
>
>> > *Hvem* påstod noe slikt her?
>>
>> Alle de forslag der indtil videre er kommet med host byte order
>> (cast, memcpy) gav du indtryk af var ubrugelige.
>
>
> * "Alle de forslag der indtil videre er kommet" != "alle
> løsningsforslag på problem A".

Hvis løsningen ikke er blevet foreslået, er det ikke et løsnings-
forslag.

> * Ingen påstod at problemet ikke kunne løses.

Nej, men vi har kun fået at vide "duer ikke". Vi venter stadig på dit
forslag.

>> > Jeg venter kun på int-represntasjonen til OP. Dersom du vet hva
>> > han/hun ville, for all del, spesefiser det.
>>
>> Jeg ved det ikke, men jeg kunne stadig godt tænke mig at vide
>> hvordan du mener det bør gøres.
>
>
> En gang til, siden det var uklart den første gangen: jeg venter kun på
> int-representasjonen til OP. Dersom du vet hva han/hun ville, for all
> del, spesifiser det.
>
> *Med mindre* en slik spesifikasjon foreligger, er det umulig å svare
> på spørsmålet.
>
> Ser du /nå/ hva som mangler?

Nej, jeg ser at du stadig kun ønsker at svare på OP's spørsmål, og ikke
mit.

Så jeg opgiver her.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

[ Kent Friis ]

[ ... ]

> > * "Alle de forslag der indtil videre er kommet" != "alle
> > løsningsforslag på problem A".
>
> Hvis løsningen ikke er blevet foreslået, er det ikke et løsnings-
> forslag.


"alle løsninger som er foreslått" != "alle løsninger". Fremdeles. Ikke
vanskelig, ikke sant?


> > * Ingen påstod at problemet ikke kunne løses.
>
> Nej, men vi har kun fået at vide "duer ikke". Vi venter stadig på
> dit forslag.


Og jeg venter stadig vekk på spesifikasjonen av det som skal løses.

[ ... ]


> > Ser du /nå/ hva som mangler?
>
> Nej, jeg ser at du stadig kun ønsker at svare på OP's spørsmål, og
> ikke mit.


Jeg venter på spesifikasjonen, fremdeles. Jeg gir i grunn blaffen i
hvem som kommer med den.

La oss ta dette nok en gang: den opprinnelige problemstillingen er
*altfor* vag for å kunne besvares. Jeg har protestert på "forslagene"
sendt hittil, nettopp fordi de ikke vil virke (i teori og praksis) i
en rekke realistiske scenarioer.

Så vil du se løsningsforslaget mitt. Greit nok. Men først må det være
en problemstilling til det løsningsforslaget! Så, hvordan *er* int'en
representert i det char-arrayet?


> Så jeg opgiver her.


Herregud, dette er som i et klassisk russisk eventyr: kongen sender en
uønsket undersått "dit jeg ikke vet hvor er, og hent det jeg ikke vet
hva er". Hvis du vil gi opp, framfor å spesifisere oppgaven, da kan du
umulig forvente at jeg skal *gjette* på egenhånd hva *du* vil jeg skal
løse? Hallo!





ivr
--
"...but it's HDTV -- it's got a better resolution than the real world."
       -- Fry, "When aliens attack"

---

Den 13 Apr 2006 20:04:46 +0200 skrev Igor V. Rafienko:
> [ Kent Friis ]
>
> [ ... ]
>
>> > * "Alle de forslag der indtil videre er kommet" != "alle
>> > løsningsforslag på problem A".
>>
>> Hvis løsningen ikke er blevet foreslået, er det ikke et løsnings-
>> forslag.
>
>
> "alle løsninger som er foreslått" != "alle løsninger". Fremdeles. Ikke
> vanskelig, ikke sant?

Derfor skrev jeg jo også netop løsnings-forslag, og ikke løsninger.

> Jeg venter på spesifikasjonen, fremdeles. Jeg gir i grunn blaffen i
> hvem som kommer med den.

Du *skrev* "OP's specifikation".

>> Så jeg opgiver her.
>
> Herregud, dette er som i et klassisk russisk eventyr: kongen sender en
> uønsket undersått "dit jeg ikke vet hvor er, og hent det jeg ikke vet
> hva er".

Tænk, sådan har jeg følt det de sidste mange gange du har skrevet det
ikke er godt nok, uden at fortælle hvad det er du savner.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis wrote:
> Den 12 Apr 2006 21:10:40 +0200 skrev Igor V. Rafienko:
>> [...]
> Men det du svarede på var en påstand om at memcpy var en brugbar
> løsning ved host byte order. Og det er her uenigheden opstår, når
> du siger memcpy ikke duer.

memcpy duer fint til hvad den nu gør. Det er begrebet "host byte order"
der ikke duer. Det er simpelthen ikke en nyttig abstraktion for den
praktiske programmør. Det er en unødvendig modalitet.

Det ses for eksempel når man prøver at skrive en unit test.

En unittest for en little-endian indkodningsfunktion:
vector<unsigned char> indkod_uint32_le(unsigned long);

kunne se ud noget i den her stil:
{
unsigned char forv[4] = {1,2,3,4};
assertEqual(indkod_uint32_le(0x04030201UL),
      vector<unsigned char>(forv+sizeof(forv)));
}

Ret ligetil, ikke sandt? Prøv nu at skrive en unittest for den
tilsvarende "host byte order" funktion:

vector<unsigned char> indkod_uint32_host(unsigned long);
{
vector<unsigned char> forv = indkod_uint32_host(0x04030201UL);
???
}

mvh. Anders

---

Kent Friis wrote:
> Blandt typiske Windows-udviklere, er de stadig i host byte order. Derfor
> kan du ikke antage hverken det ene eller det andet.

Jeg checkede lige i .NET docs:

System.IO.BinaryReader ReadInt32 bruger altid little endian.

System.BitConverter ToInt32 bruger host endianess.

(relevant for mono som kører på Linux og diverse BSD varianter
på både x86 og PPC)

Arne

---

Igor V. Rafienko wrote:
> [ Arne Vajhøj ]
>> Men kun 2-3 indlæg siden du mente at kunne modbevise påstanden om de
>> fleste computere med at dit Solaris eksempel - hvilket jo enten var
>> totalt irrelevant eller måtte være baseret på en antagelse om at
>> Solaris/SPARC er mere udbredt end Windows/x86.
>
> Huh?

Jeg skrev:

#Det virker så tilfældigvis på det store flertal af computere.

Du svarede:

#Right. Omtrent som i eksempelet mitt.

Hvis du mener at din kørsel modbeviser påstanden om
at det tilfældigvis virker på det store flertal af computere,
så må du vel mene at din kørsel er sket på et system
som repræsenterer flertallet af computere.

Ellers kan jeg ikke se logikken.

> For det andre, så har jeg aldri nevnt SPARC. *Du* har begynt å gnåle
> om det. Jeg har ikke tenkt å stå for *dine* utsagn, det må du klare på
> egenhånd.

Din kørsel antyder ret kraftigt at det var en SPARC det var
kørt på.

> La meg legge frem en dårlig forenkling: på en elendighetsskala fra 0
> til 10, der 10 betyr "virker" og alt under "5" er en klar kandidat til
> dailywtf, kan man trygt spre forslagene slik:
>
> 0 10
> rå typecast memcpy manuell sammensetting av tallet
>
> memcpy _er_ et skritt i riktig retning, men det skrittet er ikke langt
> nok. Vil du ha forklart _en gang til_ hvorfor?

memcpy virker

Der er ovenikøbet den som gør det spørger tror at typecast
hacket gør (og som det også tilfældigvis gør på en forfærdelig
masse computere).

Er en protokol med fixed endianess en god ting ?

Ja det er det ofte. Men det er ikke altid muligt fordi der
er andre system/subsystemer man ikke kan ændre. Men det er system
design og ikke C programmering.

Arne

---

[ Arne Vajhøj ]

[ ... ]

> memcpy virker


Ja, riktig. Omtrent som eksempelet mitt.


> Der er ovenikøbet den som gør det spørger tror at typecast hacket
> gør (og som det også tilfældigvis gør på en forfærdelig masse
> computere).


Høres ut som argumentasjon til de som designer vevsidene sine
utelukkende for MSIE.


> Er en protokol med fixed endianess en god ting ?


Det er ikke det som er poenget (d'uh!)


> Ja det er det ofte. Men det er ikke altid muligt fordi der er andre
> system/subsystemer man ikke kan ændre. Men det er system design og
> ikke C programmering.


Det er bare fjas, nok en gang. Formatet på data man leser inn er gitt.
(hvis ikke kan jo ikke programmet tolke dataene). Det spiller iofs.
ingen rolle om data er i little/big endian eller pakket på en annen
måte. Alt man *trenger* å vite *før* man skal prøve å løse oppgaven er
formatbeskrivelsen. Get it now?

[ ... ]





ivr
--
"...but it's HDTV -- it's got a better resolution than the real world."
       -- Fry, "When aliens attack"

---

Arne Vajhøj wrote:
> Jeg finder det lidt grotesk at man i en diskussion om portabilitet
> uden at blinke foreslår at man ændrer koden fra host endianess til
> fixed endianess.

Jeg finder det ganske naturligt, for det kan kun være en forbedring.

Enten er de pågældende data genereret af programmet selv under samme
kørsel, og så er det flintrende ligegyldigt hvordan man gør, når bare
man gør det samme begge veje, og det er indenfor defined behaviour.
Eller også skal det bruges til at kommunikere med verden omkring sig, fx
gennem filformater eller netværksprotokoller - og så er det en god idé
at have et fuldt specificeret format.

mvh. Anders

---

Anders J. Munch wrote:
> Arne Vajhøj wrote:
>> Jeg finder det lidt grotesk at man i en diskussion om portabilitet
>> uden at blinke foreslår at man ændrer koden fra host endianess til
>> fixed endianess.
>
> Jeg finder det ganske naturligt, for det kan kun være en forbedring.
>
> Enten er de pågældende data genereret af programmet selv under samme
> kørsel, og så er det flintrende ligegyldigt hvordan man gør, når bare
> man gør det samme begge veje, og det er indenfor defined behaviour.
> Eller også skal det bruges til at kommunikere med verden omkring sig, fx
> gennem filformater eller netværksprotokoller - og så er det en god idé
> at have et fuldt specificeret format.

Der er masser af gode grunde til at ligge sig fast på en
endianess.

Men hvis man foreslår det skal man gøre opmærksom på det.

"... når bare man gør det samme begge veje" er jo åbenlyst rigtigt,
men ikke nødvendigvis opfyldt.

Arne

---

Jan Thogersen wrote:
> Hej,
>
> Jeg sidder her med et lille problem... jeg har gjort det gør men kan
> simpelthen ikke huske hvordan.
>
> Jeg har en buffer:
>
> unsigned char _FF_Buf[512];
>
> Nu vil jeg så gerne fange nogle unsigned int's fra den buffer. Og det
> kan gøres med type casts jeg kan bare ikke huske syntaxen.
>
> MyInt = (unsigned int) _FF_Buf+index;

#include <iostream>

unsigned char Buf[512] = {0x12, 0x34, 0x56, 0x78, 0x11, 0x22, 0x33,
0x44, 0x55};

int main()
{
unsigned int MyInt = *(unsigned int *)(Buf + 4);
std::cout << "The result seems to be: " << MyInt << std::endl;
}

Husk på at der er tale om "undefined behaviour", "so be carefull
out there"

I C++ er der en hel række cast "operatorer", men jeg kan ikke huske
om der er en der vil være bedre at bruge her, og der vil vist
stadig være tale om "undefined behaviour".

--
Absolutely not the best homepage on the net:
http://home20.inet.tele.dk/midgaard
But it's mine - Bertel

---

Jan Thogersen wrote:
> Hej,
>
> Jeg sidder her med et lille problem... jeg har gjort det gør men kan
> simpelthen ikke huske hvordan.
>
> Jeg har en buffer:
>
> unsigned char _FF_Buf[512];
>
> Nu vil jeg så gerne fange nogle unsigned int's fra den buffer. Og det
> kan gøres med type casts jeg kan bare ikke huske syntaxen.
>
> MyInt = (unsigned int) _FF_Buf+index;

Der er ingen grund til at bruge casts til sådan noget.

Prøv enten:
/* Data i _FF_Buf er i netværksformat/big-endian */
MyInt = _FF_Buf[index] * 256u + _FF_Buf[index+1];
eller
/* Data i _FF_Buf er i little-endian format */
MyInt = _FF_Buf[index] + _FF_Buf[index+1] * 256u;

mvh. Anders

PS: Navne der begynder med _ fulgt af et stort bogstav er reserveret for
implementationen, så du bør nok kalde _FF_Buf noget andet.

---

Anders J. Munch wrote:
> Jan Thogersen wrote:
>> Jeg har en buffer:
>>
>> unsigned char _FF_Buf[512];
>>
>> Nu vil jeg så gerne fange nogle unsigned int's fra den buffer. Og det
>> kan gøres med type casts jeg kan bare ikke huske syntaxen.
>>
>> MyInt = (unsigned int) _FF_Buf+index;
>
> Der er ingen grund til at bruge casts til sådan noget.
>
> Prøv enten:
> /* Data i _FF_Buf er i netværksformat/big-endian */
> MyInt = _FF_Buf[index] * 256u + _FF_Buf[index+1];
> eller
> /* Data i _FF_Buf er i little-endian format */
> MyInt = _FF_Buf[index] + _FF_Buf[index+1] * 256u;

Eller shift fremfor gange.

Man skal bare gøre sig klart at de 2 stykker kode
grundliggende er forskellige:

1) der genereres formentligt forskellige maskin instruktioner
for dem

2) de opfører sig forskelligt ved flytning af koden mellem
little endian og big endian maskiner

Om det betyder noget for spørger ved jeg ikke.

Arne