[pso] Intrebare (masina big-endian)

[foxX]

http://www.ibm.com/developerworks/aix/library/au-endianc/index.html?ca=drs-

nu-i chiar jegul de C standard, da e destul de aproape, fiind o scriitura a
IBM (masini si big si little endian).

"

Similarly, it's natural to wonder whether strings might be saved in some
sort of strange order, depending on the machine. To understand this, let's
go back to the basics of an array. A C-style string, after all, is still an
array of characters. Each character requires one byte of memory, since
characters are represented in ASCII. In an array, the address of consecutive
array elements increases. Thus, &arr[i] is less than &arr[i+1]. Though it
isn't obvious, if something is stored with increasing addresses in memory,
it's going to be stored with increasing "addresses" in a file. When you
write to a file, you usually specify an address in memory and the number of
bytes you wish to write to the file starting at that address.

For example, suppose you have a C-style string in memory called man. Assume
that m is stored at address 1000, a at address 1001, and n at address 1002.
The null character \0 is at address 1003. Since C-style strings are arrays
of characters, they follow the rules of characters. Unlike int or long, you
can easily see the individual bytes of a C-style string, one byte at a time.
You use array indexing to access the bytes (characters) of a string. But you
can't easily index the bytes of an int or long without playing some pointer
tricks. The individual bytes of an int are more or less hidden from you.

Now imagine writing out this string to a file using some sort of
write()method. You specify a pointer to
m and the number of bytes you wish to print (in this case four). The
write()method proceeds byte by byte in the character string and writes
it to the
file, starting with m and working to the null character.

Given this explanation, it's clear that endianness doesn't matter with
C-style strings.
"

2008/9/30 mE <me_registered at yahoo.com>

> int a[] = {0x12345678, 0x22334455};
> memdump arata asa:
> 0x78 0x56 0x34 0x12 0x55 0x44 0x33 0x22
>
> ----- Original Message ----
> From: foxX <alex.mihaiuc at gmail.com>
> To: Proiectarea Sistemelor de Operare <pso at cursuri.cs.pub.ro>
> Sent: Tuesday, September 30, 2008 5:46:41 PM
> Subject: Re: [pso] Intrebare (masina big-endian)
>
> poftim http://msdn.microsoft.com/en-us/library/ms796989.aspx
> int tag = '1gaT'
>
> 2008/9/30 mE <me_registered at yahoo.com>
>
>> :) same answer here
>>
>> ----- Original Message ----
>> From: Alexandru Moşoi <brtzsnr at gmail.com>
>> To: laurentiu.duca at cs.pub.ro; Proiectarea Sistemelor de Operare <
>> pso at cursuri.cs.pub.ro>
>> Sent: Tuesday, September 30, 2008 5:26:44 PM
>> Subject: Re: [pso] Intrebare (masina big-endian)
>>
>> 2008/9/30 Laurentiu-Cristian Duca <laurentiu.duca at mail.cs.pub.ro>:
>> > Buna ziua,
>> >
>> >  Am nevoie de un sfat.
>> > Pe o masina big-endian,
>> > char *str="abcd";
>> > str[0]==(*str) este 'd' // nu este 'a'.
>>
>> da?
>> eu stiam ca bigendian se refera la asezarea byteurile intr-un numar
>> intreg (gen int32_t) si nu intr-un sir. pentru siruri ordinea nu
>> trebuie sa se schimbe.
>>
>> daca ai facut ceva de genul:
>> int a = 45354;
>> char *str = (int*)&a; s-ar putea sa ai surprize de genul celor de mai
>> sus, altfel nu vad cum ai obtinut 'd' in loc de 'a'.
>>
>> oricum, e posibil sa gresesc eu...
>>
>>
>> --
>> Alexandru Moşoi
>> http://alexandru.mosoi.googlepages.com
>>
>> Please avoid sending me Word or PowerPoint attachments.
>> See http://www.gnu.org/philosophy/no-word-attachments.html
>> _______________________________________________
>> pso mailing list
>> pso at cursuri.cs.pub.ro
>> http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/pso
>>
>>
>> _______________________________________________
>> pso mailing list
>> pso at cursuri.cs.pub.ro
>> http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/pso
>>
>>
>
>
> --
> kthxbai
>
>
> _______________________________________________
> pso mailing list
> pso at cursuri.cs.pub.ro
> http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/pso
>
>


-- 
kthxbai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cursuri.cs.pub.ro/pipermail/pso/attachments/20080930/1c0c3621/attachment.htm