cquenel@polyslo.CalPoly.EDU (36 more school days) (04/18/89)
In 9424 peter@ficc.uu.net (Peter da Silva) sez: >I've suggested this before. I think syntax like: > > int:32 x, y; > int:36 z; /* Unisys 1100 compatibility :-> */ > int a:8, b:9, c:6; int32_t x,y; int16_t c; (and maybe for unsigned) uint16_t n; would probably raise a lot fewer hackles. --chris -- @---@ ----------------------------------------------------------------- @---@ \. ./ | Chris (The Lab Rat) Quenelle cquenel@polyslo.calpoly.edu | \. ./ \ / | All those moments will be lost in time, like tears in rain. | \ / ==o== ----------------------------------------------------------------- ==o==
peter@ficc.uu.net (Peter da Silva) (04/18/89)
In article <10377@polyslo.CalPoly.EDU>, cquenel@polyslo.CalPoly.EDU (36 more school days) writes: > In 9424 peter@ficc.uu.net (Peter da Silva) sez: > > int:32 x, y; > > int:36 z; /* Unisys 1100 compatibility :-> */ > > int a:8, b:9, c:6; > int32_t x,y; > int16_t c; Oh yes, I know, I know. I'm involved in setting up a company-wide standard for 'C' programming, and we're doing something like this. But the semantics are not quite as good as int:n would be. For example, 1+(unsigned int:3)7 should be 0. Defining specific types does not give you this ability. It'd also be a boon for people porting code to weird machines... sometimes you really need an int with a power-of-2 size, and it's a pain to emulate that by hand on a 36-bit machine. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.