Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
* Bernd Eckenfels: > In article <[EMAIL PROTECTED]> you wrote: >>>sizeof(char) == 1 > >> I just removed them for this reason. > > Maybe we need to specify CHAR_BITS instead? Too much Java programming? 8-) POSIX requires CHAR_BITS to be 8 these days. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
On Sat, 2008-04-26 at 20:21 +0200, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > >>sizeof(char) == 1 > > > I just removed them for this reason. > > Maybe we need to specify CHAR_BITS instead? Maybe some day Debian will run on an architecture where CHAR_BITS != 8, but I doubt it; too much software depends on having exactly-8-bit types. Until then, why bother? (Similarly there's little point in including sizeof(short) and sizeof(int); they don't vary between our current architectures and are very unlikely to do so in future.) Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
In article <[EMAIL PROTECTED]> you wrote: >>sizeof(char) == 1 > I just removed them for this reason. Maybe we need to specify CHAR_BITS instead? Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
On Sat, 2008-04-26 at 00:15 -0400, Zack Weinberg wrote: > I looked at the page: this seems like an appropriate moment to mention > something that should be a lot more widely known than it is: > >sizeof(char) == 1 >sizeof(signed char) == 1 >sizeof(unsigned char) == 1 > > Those three equalities are not part of any ABI. They are written into > the C standard, in the definition of the sizeof() operator. They will > never be false. I just removed them for this reason. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
On Sat, 2008-04-26 at 12:29 +0200, Florian Weimer wrote: > * Cyril Brulebois: > > > I'm wondering whether the ArchitectureSpecificsMemo[1] wiki page is > > (well-)known, and whether its content got reviewed, esp. by porters of > > each architecture, who could fix obvious errors or typos, or eventually > > add special-cases, exceptions, and the like. > > I hope the table can be simplified, along the categories LP32/LP64, > endianness, char signedness. sizeof(long double) needs to be listed > separately, along with it's range/precision. > > Hopefully, we will never end up with an architecture where sizeof(long) > != sizeof(void *) Linux has a convention predating intptr_t of using long for that purpose, so Linux won't allow such an ABI. > or sizeof(int) != 4. GNU requires that, unless I'm much mistaken. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
* Cyril Brulebois: > I'm wondering whether the ArchitectureSpecificsMemo[1] wiki page is > (well-)known, and whether its content got reviewed, esp. by porters of > each architecture, who could fix obvious errors or typos, or eventually > add special-cases, exceptions, and the like. I hope the table can be simplified, along the categories LP32/LP64, endianness, char signedness. sizeof(long double) needs to be listed separately, along with it's range/precision. Hopefully, we will never end up with an architecture where sizeof(long) != sizeof(void *) or sizeof(int) != 4. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
On Fri, Apr 25, 2008 at 05:06:59PM +0200, Petter Reinholdtsen wrote: > 'arm' is said to be LE, but I believe it differ for integers and > floating point numbers. Is 'arm' in the list the 'arm' archtecture? > What about 'armel' and 'armeb'? on arm (unlike armeb and armel), doubles are two little-endian words stored bigendian. -- "rm -rf" only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
I looked at the page: this seems like an appropriate moment to mention something that should be a lot more widely known than it is: sizeof(char) == 1 sizeof(signed char) == 1 sizeof(unsigned char) == 1 Those three equalities are not part of any ABI. They are written into the C standard, in the definition of the sizeof() operator. They will never be false. zw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
[Cyril Brulebois] > Hi, > > I'm wondering whether the ArchitectureSpecificsMemo[1] wiki page is > (well-)known, and whether its content got reviewed, esp. by porters of > each architecture, who could fix obvious errors or typos, or eventually > add special-cases, exceptions, and the like. > > 1. http://wiki.debian.org/ArchitectureSpecificsMemo 'arm' is said to be LE, but I believe it differ for integers and floating point numbers. Is 'arm' in the list the 'arm' archtecture? What about 'armel' and 'armeb'? The page should state if the architecture name is the output from 'dpkg --print-architecture' or some other value. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
On Fri, Apr 25, 2008 at 08:12:58AM +0200, Cyril Brulebois wrote: Hi, I'm wondering whether the ArchitectureSpecificsMemo[1] wiki page is (well-)known, and whether its content got reviewed, esp. by porters of each architecture, who could fix obvious errors or typos, or eventually add special-cases, exceptions, and the like. 1. http://wiki.debian.org/ArchitectureSpecificsMemo One other thing that might be useful is alignment for each of 1, 2, 4, and 8 byte quantities, and the signal used for unaligned accesses. This would be useful because it would allow developers to immediately determine (e.g) what a SIGBUS on sparc means. Obviously, if a machine doesn't prohibit unaligned accesses (like the i386) then that field would be left blank. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Reviewing http://wiki.debian.org/ArchitectureSpecificsMemo
Hi, I'm wondering whether the ArchitectureSpecificsMemo[1] wiki page is (well-)known, and whether its content got reviewed, esp. by porters of each architecture, who could fix obvious errors or typos, or eventually add special-cases, exceptions, and the like. 1. http://wiki.debian.org/ArchitectureSpecificsMemo Looking at its history, the number of commits is rather low, so it might be interesting to have some couples of eyes checking that page. Mraw, KiBi. pgpy0wEHuCkK7.pgp Description: PGP signature
