New activity for FreeRADIUS (the high performance and highly configurable RADIUS server) ====== remove compilation error messages (As noted by Alan Buxey) removes the following at compile time: dhcp.c: In function ‘fr_dhcp_add_arp_entry’: dhcp.c:1561: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 2 has type ‘unsigned int’ dhcp.c:1561: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 3 has type ‘size_t’ Arran Cudbard-Bell@2012-10-15T16:07:57Z Files modified: * src/lib/dhcp.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/df5ebfae4e20ad523dd4e... ====== Only print out user authorized message if the ldap module is actually being used for user authorization Arran Cudbard-Bell@2012-10-15T10:42:38Z Files modified: * src/modules/rlm_ldap/rlm_ldap.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/5a95de4c77d882c867522... ====== Add option to disable password check Arran Cudbard-Bell@2012-10-15T10:33:38Z Files modified: * src/modules/rlm_ldap/rlm_ldap.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/fdb3c8e74bd21f40a1772... ====== Add base64 encoding/decoding library Add %{base64:} expansion to encode the raw octets of an attribute Add %{strtobase64:} expansion to encode a string to base64 Add %{base64tostr:} expansion to decode a base64 string Arran Cudbard-Bell@2012-10-14T22:10:24Z Files modified: * src/include/Makefile * src/include/all.mk * src/include/base64.h * src/lib/Makefile * src/lib/all.mk * src/lib/base64.c * src/main/xlat.c * src/modules/rlm_expr/rlm_expr.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/7f4d67fe5bd7368c42062... ====== Fixup radius_xlat calls to pass inst (was missed from previous commit) Minor reformatting Arran Cudbard-Bell@2012-10-14T18:31:14Z Files modified: * src/modules/rlm_sql/rlm_sql.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/538ad07d11ef2098061f8... ====== -- This commit summary was generated @2012-10-15T18:00:01Z by lgfeed version 0.00 (https://github.com/arr2036/lgfeed).
On Mon, Oct 15, 2012 at 06:00:01PM +0200, The git bot wrote:
====== remove compilation error messages (As noted by Alan Buxey)
removes the following at compile time:
dhcp.c: In function ‘fr_dhcp_add_arp_entry’: dhcp.c:1561: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 2 has type ‘unsigned int’ dhcp.c:1561: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 3 has type ‘size_t’
Arran Cudbard-Bell@2012-10-15T16:07:57Z Files modified: * src/lib/dhcp.c
Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/df5ebfae4e20ad523dd4e... ======
Aside: this uses "%u", sizeof(...) for the first argument. Is it guaranteed that sizeof() is int on all platforms? There is an example at http://en.wikipedia.org/wiki/Sizeof which uses "%zu" for sizeof() values. I guess if there's any doubt, "%lu", (long)sizeof(...) should be pretty safe.
On 10/17/2012 09:04 AM, Brian Candler wrote:
Aside: this uses "%u", sizeof(...) for the first argument. Is it guaranteed that sizeof() is int on all platforms?
Very much not. sizeof returns size_t which is always unsigned (so never "int"), but otherwise implementation (compiler) dependent. In principle "%zu" is the correct format spec. However, I'm not sure how widely supported that is on older compilers - even on current ones.
I guess if there's any doubt,
"%lu", (long)sizeof(...)
should be pretty safe.
Yuck. Cast of unsigned to signed :oP TBH it's a fairly theoretical argument; sizeof is used on objects whose size tends to be in the range 1-100k and specified at compile time. The odds of sizeof ever returning >2**31 are very, very remote, at least with current system architectures.
On 17 Oct 2012, at 09:26, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 10/17/2012 09:04 AM, Brian Candler wrote:
Aside: this uses "%u", sizeof(...) for the first argument. Is it guaranteed that sizeof() is int on all platforms?
Very much not.
Quite.
sizeof returns size_t which is always unsigned (so never "int"), but otherwise implementation (compiler) dependent. In principle "%zu" is the correct format spec. However, I'm not sure how widely supported that is on older compilers - even on current ones.
%zu was specified in C99, it is by no means new.
I guess if there's any doubt,
"%lu", (long)sizeof(...)
should be pretty safe.
Yuck. Cast of unsigned to signed :oP
TBH it's a fairly theoretical argument; sizeof is used on objects whose size tends to be in the range 1-100k and specified at compile time. The odds of sizeof ever returning >2**31 are very, very remote, at least with current system architectures.
:) -Arran
On Wed, Oct 17, 2012 at 09:26:35AM +0100, Phil Mayers wrote:
I guess if there's any doubt,
"%lu", (long)sizeof(...)
should be pretty safe.
Yuck. Cast of unsigned to signed :oP
Sorry, I meant "%lu", (unsigned long)sizeof(...) If "%zu", sizeof(...) is correct I'm happy with that too.
TBH it's a fairly theoretical argument; sizeof is used on objects whose size tends to be in the range 1-100k and specified at compile time. The odds of sizeof ever returning >2**31 are very, very remote, at least with current system architectures.
It's more about pushing the right size onto the stack for va_arg. If you push an 8-byte value when printf consumes 4-bytes, or vice versa, then it will screw up the following arguments. Regards, Brian.
On 17 Oct 2012, at 10:41, Brian Candler <B.Candler@pobox.com> wrote:
On Wed, Oct 17, 2012 at 09:26:35AM +0100, Phil Mayers wrote:
I guess if there's any doubt,
"%lu", (long)sizeof(...)
should be pretty safe.
Yuck. Cast of unsigned to signed :oP
Sorry, I meant "%lu", (unsigned long)sizeof(...)
Hmm, but size_t could be 64bits, long is only guaranteed to be 32bits? If you use unsigned long long and %llu you're into C99 features. -Arran
On Wed, Oct 17, 2012 at 11:22:49AM +0100, Arran Cudbard-Bell wrote:
Sorry, I meant "%lu", (unsigned long)sizeof(...)
Hmm, but size_t could be 64bits, long is only guaranteed to be 32bits? If you use unsigned long long and %llu you're into C99 features.
Yes in theory, although in practice I would be extremely surprised to find a platform where long is 32 bits and size_t is 64 bits. Anyway, "%zu" FTW.
Phil Mayers wrote:
TBH it's a fairly theoretical argument; sizeof is used on objects whose size tends to be in the range 1-100k and specified at compile time. The odds of sizeof ever returning >2**31 are very, very remote, at least with current system architectures.
Yeah. But I'm (finally) OK with using C99 features. I avoided them for a while, because so many systems didn't support even C89. So changing all of the code to use %zu for size_t, and %zd for ssize_t is probably OK. I would STRONGLY avoid casts. They're an ugly brute-force solution to a simple problem. Alan DeKok.
participants (6)
-
alan buxey -
Alan DeKok -
announce＠freeradius.org -
Arran Cudbard-Bell -
Brian Candler -
Phil Mayers