Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 15 Jan 2011 00:45:14 -0800
From:      Garrett Cooper <gcooper@FreeBSD.org>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        svn-src-head@freebsd.org, mdf@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r217369 - in head/sys: cam/scsi sys
Message-ID:  <AANLkTimoT9c6q2=K=C7dSnxJXkT=qZx=wPbAf6k68hWZ@mail.gmail.com>
In-Reply-To: <20110115170529.T16715@besplex.bde.org>
References:  <201101131820.p0DIKXip059402@svn.freebsd.org> <AANLkTinh619WaGgq=5fFxTvEX0JPir34k8xb%2Bs6oSH8Y@mail.gmail.com> <20110114174719.D28159@besplex.bde.org> <AANLkTikVwuSO3h8tKeYXCvC6zqYVHVxdY5Abrzo-Ks2R@mail.gmail.com> <20110115133929.D16210@besplex.bde.org> <AANLkTi=B5mZCJ_bhe=Gf1pLUmWsTswi3O3U2ZLnHMODV@mail.gmail.com> <20110115170529.T16715@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Fri, Jan 14, 2011 at 10:27 PM, Bruce Evans <brde@optusnet.com.au> wrote:
> On Fri, 14 Jan 2011, Garrett Cooper wrote:
>
>> On Fri, Jan 14, 2011 at 6:42 PM, Bruce Evans <brde@optusnet.com.au> wrote:
>>>
>>> On Fri, 14 Jan 2011 mdf@FreeBSD.org wrote:
>>>
>>>> On Thu, Jan 13, 2011 at 10:50 PM, Bruce Evans <brde@optusnet.com.au>
>>>> wrote:
>>>>>
>>>>> On Thu, 13 Jan 2011 mdf@freebsd.org wrote:
>>>>>
>>>>>> There appear to be 330 uses of SYSCTL and QUAD on the same line in
>>>>>> CURRENT.  This seems reasonable to change them to S64, U64 and X64 so
>>>>>> they correctly reflect the size they operate upon.
>>>>>>
>>>>>> What do y'all think?
>>>>>
>>>>> Now I suggest delaying this until they can be renamed to a type-
>>>>> generic
>>>>> SYSCTL_INT() (would probably need to be spelled differently, SYSCTL_I()
>>>>> say, even if SYSCTL_INT() was changed at the same time).
>>>>
>>>> I'm torn on this one.  The compiler knows the type (unless, for
>>>> SYSCTL_INT, NULL/0 is used, but that is also a compile-time check),
>>>> but to interpret it requires the use of __builtin_foo which is a gcc
>>>> extension and not part of standard C.
>>>>
>>>> Philosophically, while I like this kind of letting the compiler do the
>>>> work, if you want C++ you know where to find it.
>>>
>>> Oops.  I think sizeof() and issigned() can be used to determine the type
>>> well enough in functions and initialized data (do a fuller type check if
>>> the compiler supports it), but I don't know how to do this in static
>>> sysctl declarations (since sizeof() can't be used in cpp expressions).
>>
>>   Why not just create some dumb testcases that can be run at build
>> time to determine that for you?
>
> Well, how?  You are given SYSCTL_I(&var, ...) and have to convert this
> to what is now in SYSCTL_INT(), using only the type of var, in hundreds
> or thousands of files.  I don't even know how to do this with a test
> case for each file, short of parsing all the files.  Oops, I do know
> how to translate from sizeof(var) to CTLTYPE_INT or CTLTYPE_UINT.
> That's just (sizeof(var) == sizeof(int) ? CTLTYPE_INT : ...).  The
> signness is harder (might need gnu typeof(), but not the recent type
> checking attributes).  This won't convert from SYSCTL_I() existing
> SYSCTL_INT() (the switch on the size would have to be in an ifdef for
> that, but sizeof() doesn't work in ifdefs), but it works for generating
> CTLTYPE_* internally SYSCTL_I().  The difficulty is converting from a
> bare variable `var' to an integer representing the signedness of its
> type, without using an unportability like typeof().  With typeof(), this
> is:
>
>        /* Only works for arithmetic types: */
>        #define isinteger(var)  ((typeof(var))0.1 == 0)
>        #define issigned(var)   ((typeof(var))-1 < 0)
>        ...

    This is what I meant:

$ cat test_warnings.c
#include <sys/types.h>

size_t x = (int) -1;
int y = 20000000000L;
$ gcc -Wconversion -Wstrict-overflow -Wsign-compare -c test_warnings.c
test_size_t.c:3: warning: negative integer implicitly converted to unsigned type
test_size_t.c:4: warning: overflow in implicit constant conversion
$

    With the right CFLAGS and a few properly written tests, and a few
make rules, you can figure out what's what pretty easily *shrugs*.
Thanks,
-Garrett



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimoT9c6q2=K=C7dSnxJXkT=qZx=wPbAf6k68hWZ>