On Thu, Jun 16, 2011 at 8:12 AM, Garrett Cooper <yaneg...@gmail.com> wrote:
> On Thu, Jun 16, 2011 at 7:06 AM, Bruce Evans <b...@optusnet.com.au> wrote:
>> On Thu, 16 Jun 2011, Tai-hwa Liang wrote:
>>
>>> On Thu, 16 Jun 2011, Bruce Evans wrote:
>>>
>>>> On Thu, 16 Jun 2011, Garrett Cooper wrote:
>>>>>
>>>>> And you need to add #include <stdint.h> to stand.h in order to get
>>>>> uintmax_t. Here's a proper patch for amd64..
>>>>
>>>> This would add namespace pollution.  stand.h doesn't use anything in
>>>> <stdint.h>.  It depends on normal namespace pollution in an XXX section
>>>> in <sys/types.h> for the declaration of uintptr_t.  It and other headers
>>>> should use __uintptr_t instead.  Strangely, <sys/types.h> declares
>>>> uintptr_t but not uintmax_t.
>>>
>>>  What about casting to __uintmax_t instead?
>>>
>>> Index: zalloc.c
>>> ===================================================================
>>> --- zalloc.c    (revision 223146)
>>> +++ zalloc.c    (working copy)
>>> @@ -154,7 +154,7 @@
>>>    if ((char *)ptr < (char *)mp->mp_Base ||
>>>        (char *)ptr + bytes > (char *)mp->mp_End ||
>>>        ((iaddr_t)ptr & MEMNODE_SIZE_MASK) != 0)
>>> -       panic("zfree(%p,%ju): wild pointer", ptr, bytes);
>>> +       panic("zfree(%p,%ju): wild pointer", ptr, (__uintmax_t)bytes);
>>> ...
>>
>> zalloc.c is not the (header) implementation, so it should not use the
>> implementation detail (anything beginning with __).
>>
>> The latest tinderbox errors for this are hard to understand.  For amd64
>> they say:
>>
>>> /src/lib/libstand/zalloc.c: In function 'zfree':
>>> /src/lib/libstand/zalloc.c:157: warning: format '%ju' expects type
>>> 'uintmax_t', but argument 3 has type 'iaddr_t'
>>
>> but amd64 seems to be just like sparc64 -- both seem to declare all the
>> types as `unsigned long' at the lowest level.  I would expect all 64-bit
>> arches to do this, although this is logically wrong (it makes the largest
>> integral type uintmax_t logically smaller than the standard bogus type
>> unsigned long long).  This logic error is partly intentional (it detects
>> different type mismatches than uintmax_t = `unsigned long long' combined
>> with uint64_t = `unsigned long' would).
>
>    My second patch when applied gets one past tinderbox on powerpc..
> waiting for powerpc64 and sparc64 to complete. Namespace pollution is
> one thing, but stdint.h isn't that bad IMHO -- I just find it funny
> that iaddr_t had to be typedef'ed to uintptr_t in the first place.

This needs to be committed to unbreak ia64 and mips64*. Still waiting
to see what happens with sparc64, but amd64 and powerpc64 were oddly
happy without this, even though they should have failed along with
ia64 and mips64* (the format string should have been %zu for a size_t
type).

Will rerun universe once it completes on amd64, ia64 and sparc64
though later on today..
Thanks!
-Garrett
Index: lib/libstand/zalloc_malloc.c
===================================================================
--- lib/libstand/zalloc_malloc.c	(revision 223140)
+++ lib/libstand/zalloc_malloc.c	(working copy)
@@ -110,7 +110,7 @@
 	    return;
 	}
 	if (*((signed char *)res + res->ga_Bytes - 1) != -2)
-	    panic("free: guard2 fail @ %p + %d from %s:%d", ptr, res->ga_Bytes - MALLOCALIGN, file, line);
+	    panic("free: guard2 fail @ %p + %zu from %s:%d", ptr, res->ga_Bytes - MALLOCALIGN, file, line);
 	*((signed char *)res + res->ga_Bytes - 1) = -1;
 #endif
 
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to