On Thu Nov 22 04:03:29 EST 2012, charles.fors...@gmail.com wrote:
usize is indeed the same size as uintptr.
Instead of either for purely integer values, it would be better to
make all integers 64 bit, and use uint and int (for pointer
differences),
but that causes other problems, at the
I hadn't noticed that particularly, but having grep'd the source, I
see it's also used for variables that are counters and numbers of
things.
Is that right too? I suspect it's more out of expediency. Some other
type usage looks odd too. int32 where int would do. Curious.
On 22 November 2012
.B char
can generally be assumed to be a signed value.
What does generally mean here? Is it safe to assume or not?
There are no signed variants of these as they
are not useful where size-specific types are appropriate.
Not useful seems an arbitrary judgment. There are certainly
cases
usize is indeed the same size as uintptr.
Instead of either for purely integer values, it would be better to
make all integers 64 bit
I hope that was intended as a joke. It's not that long ago I was
writing C for a 16-bit processor (in a smart card). I would hate to
lose the meaning of int
On 22 November 2012 11:00, Richard Miller 9f...@hamnavoe.com wrote:
OTOH, it's not worth making special provision for physical memory addresses.
I think that any code which is dealing with those is not likely to be
portable to another architecture for many other reasons. I can't envision
a
To try to clarify: most existing Plan 9 code doesn't worry about the
actual type of sizeof or pointer differences.
They assume int/long or uint/ulong. It's obvious from this discussion
that hardly anyone noticed usize.
Since its introduction years ago, grep shows that only kernel code has
used
Even port refers to
physical addresses (eg, Page)
You're right, I should have thought a bit longer. This is
why my PAE hack for xen only supports 4GB of physical
(well, virtually physical) memory.
I meant, detect code. It's easy to find: just look at libflate, but
there were many more.
On 22 November 2012 11:32, Charles Forsyth charles.fors...@gmail.com wrote:
it's quite
hard to find code (automatically) that assumes they are 32 bits.
New C programmers are often confused by
size_t being unsigned (even experienced ones at times)
Especially experienced ones. My 1978 copy of KR says
The expression sizeof(object) yields an integer equal to the
size of the specified object.
Not unsigned integer. Old habits die hard.
It was in v6 (and a nasty bug):
/*
* sizeof gets turned into a number here.
* Bug: sizeof(structure-member-array) is 2 because
* the array has been turned into a ptr already.
*/
if (op==SIZEOF) {
t1 = length(p1);
p1-op = CON;
p1-type = INT;
On Thu Nov 22 06:01:38 EST 2012, 9f...@hamnavoe.com wrote:
.B char
can generally be assumed to be a signed value.
What does generally mean here? Is it safe to assume or not?
good point.
There are no signed variants of these as they
are not useful where size-specific types are
i put up corrections
- erik
The expression sizeof(object) yields an integer equal to the
size of the specified object.
Not unsigned integer. Old habits die hard.
I feel your pain.
We use lint a lot here and it irritates me greatly when it
grumbles about loss of precision in assignment
from sizeof() or nelem() to an
It was changed in Ritchie's own compiler in v7 as I noted earlier.
It was that, use long, or limit your sizeof'd data to half the 16-bit
address space.
On 22 November 2012 11:54, Steve Simon st...@quintile.net wrote:
I wish I had been in the standards meeting with a big stick when somone
Charles Forsyth charles.fors...@gmail.com once said:
On 22 November 2012 03:44, Bruce Ellis bruce.el...@gmail.com wrote:
uintptr in all over the go packages because it is right.
I hadn't noticed that particularly, but having grep'd the source, I
see it's also used for variables that are
this is just a sample, but there were other likely candidates:
./src/pkg/runtime/cpuprof.c: uintptr count;
./src/pkg/runtime/cpuprof.c: uintptr count; // tick count
./src/pkg/runtime/cpuprof.c: uintptr evicts; // eviction count
./src/pkg/runtime/cpuprof.c: uintptr lost; // lost ticks that need to
Charles Forsyth charles.fors...@gmail.com once said:
this is just a sample, but there were other likely candidates:
Ah. I thought we were talking about Go code not C. Carry on.
Anthony
so what do you want to do about usize. i can't easily just make it 64-bits on
nix, because that would require that we get some changes in sources. malloc
would need to be fixed, etc.
Just tell the plain truth - have I got this right?
Usize is an unsigned integer which can hold the maximum
Usize is an unsigned integer which can hold the maximum size of an
object declared statically (the sizeof operator returns a value of
type usize) or created by the usual allocation functions (the size
argument of malloc is - or should be? - type usize). Usize may be
smaller than uintptr,
On Nov 22, 2012, at 6:38 AM, Charles Forsyth charles.fors...@gmail.com wrote:
I wonder if there's an assumption that usize is a novelty. It has been
in u.h for at least 5 years.
yes, there was such assumption on my behalf. I haven't seen it before erik
posted
the man page, now after some
hola,
usize, really?
any reason not use this opportunity to join the world and use inttypes.h or
stdint.h format?
On Nov 20, 2012, at 6:49 PM, erik quanstrom quans...@quanstro.net wrote:
i've written a little man page
/n/sources/contrib/quanstro/types
On Wed Nov 21 19:19:21 EST 2012, benave...@gmail.com wrote:
hola,
usize, really?
any reason not use this opportunity to join the world and use inttypes.h or
stdint.h format?
have you read the opengroup pubs?
http://pubs.opengroup.org/onlinepubs/007904975/basedefs/stdint.h.html
i think that go's scalar types would work better. also usize is a bit
dicky.
brucee
On Nov 22, 2012 12:23 PM, erik quanstrom quans...@quanstro.net wrote:
On Wed Nov 21 19:19:21 EST 2012, benave...@gmail.com wrote:
hola,
usize, really?
any reason not use this opportunity to join the
I agree with brucee here about the Go type names: I'd rather see uint64,
int64, uint32, int32, etc.
usize doesn't bother me much. New C programmers are often confused by
size_t being unsigned (even experienced ones at times); this makes it clear.
On Wed, Nov 21, 2012 at 8:35 PM, Bruce Ellis
uintptr for size_t.
brucee
On Nov 22, 2012 1:10 PM, Dan Cross cro...@gmail.com wrote:
I agree with brucee here about the Go type names: I'd rather see uint64,
int64, uint32, int32, etc.
usize doesn't bother me much. New C programmers are often confused by
size_t being unsigned (even
That will obviously work, and indeed I use uintmem the same way to
avoid having yet another type,
but that's only because that's specific to the kernel, and of little use.
Otherwise, I think there's a difference between storing a pointer
value in an integer, and storing a size.
For one thing, many
heads up! uintptr in all over the go packages because it is right. i'd like
an example of where usize wins, as it has to be same as uintptr. what is
sizeof(x)?
struct {
char stuff[8 * GB];
} x;
quite a reasonable but rookie decl in 64 bit land.
brucee
On 22 November 2012 13:35, Charles
i've written a little man page
/n/sources/contrib/quanstro/types
http://iwp9.org/magic/man2html/2/types
describing a progression of the plan 9 type system that works
outside the 32-bit-only world we've been living in since 1992.
nix uses this type system.
- erik
28 matches
Mail list logo
