> the %t and %T space seems rather crowded...
i agree. but %t is the real issue, and i see just 9 instances of that.
only one of them (the kernel) uses both %t and %T. this seems easy
enough to fix.
for all but the kernel we can change %t to %T, and for the kernel
we'll have to use something od
what if we introduce signed intptr type and use that instead
of introducing ptrdiff? ape already has a signed intptr_t
type.
then use 'z' as a modifier to mean "intptr size" so that
%zd would print signed intptr and %zud is for uintptr?
the %t and %T space seems rather crowded...
term% grep 'fmt
On Tue Jan 5 23:02:59 PST 2016, cinap_len...@felloff.net wrote:
> it appears that %t and %z are already used by a bunch of programs,
> including the kernel:
>
> term% grep -n 'fmtinstall\(''[zt]''' */*.c */*/*.c */*/*/*.c
> cmd/trace.c:137: fmtinstall('t', timeconv);
> 9/port/edf.c:122:
it appears that %t and %z are already used by a bunch of programs,
including the kernel:
term% grep -n 'fmtinstall\(''[zt]''' */*.c */*/*.c */*/*/*.c
cmd/trace.c:137:fmtinstall('t', timeconv);
9/port/edf.c:122: fmtinstall('t', timeconv);
cmd/db/output.c:159:fmtinstall('t'
> for instance, although the range of subtraction is theoretically
> -2^64+1 to 2^64-1, amd64 can only address 48 bits of memory
> (currently) despite using 64 bits to represent addresses. as long
> as virtual addresses in the system aren't exabytes apart, this
> shouldn't result in undefined beha
> ...and arguing with it, based on assuming charles is disagreeing with
> me about reasonable behavior. he isn't. apparently, you didn't take
> the time to read what i had written in the first place. or at least
> not past the first sentence.
>
> this is really annoying to me because it tends to b
2016-01-05 14:57 GMT-08:00 Devon H. O'Dell :
> 2016-01-05 14:32 GMT-08:00 :
>>> there are usable ANSI formats for the difference and sizeof types.
>>
>> so one would write %td instead of %ld for ptrdiff type? that seems
>> easy.
>
> yes, and there's support for u/i/o/X/x/etc modifiers
>
>> i'm not
On Tue Jan 5 14:34:52 PST 2016, cinap_len...@felloff.net wrote:
> > there are usable ANSI formats for the difference and sizeof types.
>
> so one would write %td instead of %ld for ptrdiff type? that seems
> easy.
yup.
> i'm not so sure how usize/ssize would work. %zud and %zd? or would
> the z
2016-01-05 14:32 GMT-08:00 :
>> there are usable ANSI formats for the difference and sizeof types.
>
> so one would write %td instead of %ld for ptrdiff type? that seems
> easy.
yes, and there's support for u/i/o/X/x/etc modifiers
> i'm not so sure how usize/ssize would work. %zud and %zd? or wo
> there are usable ANSI formats for the difference and sizeof types.
so one would write %td instead of %ld for ptrdiff type? that seems
easy.
i'm not so sure how usize/ssize would work. %zud and %zd? or would
the z flag imply unsigned? would the return type of sizeof() also
become usize?
--
cina
2016-01-05 12:40 GMT-08:00 erik quanstrom :
> On Tue Jan 5 11:49:06 PST 2016, charles.fors...@gmail.com wrote:
>
>> On 5 January 2016 at 19:01, Devon H. O'Dell wrote:
>>
>> > so given any of the examples in this thread, if you typedef'ed
>> > ptrdiff_t to long, then the compiler technically isn't
> since 6c is more commonly used now, and there's more interest or need,
> it's probably best just to introduce the difference type and change
> the result type. it's the same thing with usize. i'll see if i can
> add some code to check for mismatches automatically.
>
> there are usable ANSI for
On Tue Jan 5 11:49:06 PST 2016, charles.fors...@gmail.com wrote:
> On 5 January 2016 at 19:01, Devon H. O'Dell wrote:
>
> > so given any of the examples in this thread, if you typedef'ed
> > ptrdiff_t to long, then the compiler technically isn't actually doing
> > anything wrong. whether it is
On 5 January 2016 at 19:01, Devon H. O'Dell wrote:
> so given any of the examples in this thread, if you typedef'ed
> ptrdiff_t to long, then the compiler technically isn't actually doing
> anything wrong. whether it is doing something useful is a different
> question.
>
Well, although I knew th
2016-01-05 2:28 GMT-08:00 Charles Forsyth :
> since 6c is more commonly used now, and there's more interest or need, it's
> probably best just to introduce
> the difference type and change the result type. it's the same thing with
> usize.
i get that probably nobody cares about c standards here, b
On 5 January 2016 at 10:15, Charles Forsyth
wrote:
> 2) if a pointer subtraction has to yield a long, why dont we cast *after*
>> the division?
>>
>
> that would be certainly be better.
>
since 6c is more commonly used now, and there's more interest or need, it's
probably best just to introduce
On 5 January 2016 at 07:53, wrote:
> rsc has fixed this in the go 6c compiler. so far most code
> seems to compile and work fine. the most fallout is with
>
long x = p - q;
T *y = p+x;
really there needs to be a new typedef for the difference type.
On 5 January 2016 at 06:36, wrote:
> 1) why do we cast to long?
>
because that's the type all existing code expected, and there wasn't much
application
for > 4gb in single arrays at the time (as opposed to having big memory in
big address spaces)
> 2) if a pointer subtraction has to yield a lo
rsc has fixed this in the go 6c compiler. so far most code
seems to compile and work fine. the most fallout is with
warnings for %ld format strings as char* - char* is now
vlong instead of long.
is there any prefered way on how to move forwards with amd64?
i think as memories grow, we will hit pr
in the function /sys/src/cmd/cc/sub.c:/^arith we emit code
that cast the 64-bit subtraction result to 32-bit LONG *before*
doing the division of the sizeof of the pointer type.
so when the pointers are more than 4gb apart, we will calculate
the wrong result, even tho the result would have fit into
20 matches
Mail list logo
