CVS commit: xsrc/external/mit/xauth/dist
Module Name:xsrc Committed By: mrg Date: Mon Jul 15 06:01:53 UTC 2019 Modified Files: xsrc/external/mit/xauth/dist: process.c Removed Files: xsrc/external/mit/xauth/dist: README Log Message: merge xauth 1.1. To generate a diff of this commit: cvs rdiff -u -r1.1.1.6 -r0 xsrc/external/mit/xauth/dist/README cvs rdiff -u -r1.6 -r1.7 xsrc/external/mit/xauth/dist/process.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: xsrc/external/mit/xauth/dist
On Mon, Jun 03, 2013 at 08:00:58PM +, David Holland wrote: #define__DECONST(t, a) const_castt(a) and I suppose one could also do something like this: #define __DECONST(t, v) \ (sizeof((v) - (const t)0) ? (t)(unsigned long)(v) : 0) Sounds good to me. I seriously wonder why an intern __-namespaced macro needs to be portable beyound all currently supported architextures. Maybe we could add another clause to the ? selector and check for sizeof(unsigned long) = sizeof(const t) to make possible future failures very explicit - but that should IMO be enough. On the other hand, the idea of making this *evil* macro usable by C++ code makes me shiver. Plaese don't tell me bind11 or newer gcc will need this! Martin
Re: CVS commit: xsrc/external/mit/xauth/dist
On Mon, 03 Jun 2013, Christos Zoulas wrote: | Well, there is an advantage that the FreeBSD one has over ours. It can be | used in c++ with -Wold-style-cast, if defined as: | | #define __DECONST(t, a) const_castt(a) | | That, and why is it cast to an unsigned long and not uintptr_t? So that it does not bring in another header to define uintptr_t. unsigned long might not be long enough. I'd rather bring in another header than have code that might do the wrong thing on some future platform. We should probably have a header that defines __ versions of some useful types without polluting the namespace, and then use __intptr_t. --apb (Alan Barrett)
Re: CVS commit: xsrc/external/mit/xauth/dist
On Sun, Jun 02, 2013 at 12:40:12AM +, Christos Zoulas wrote: Log Message: apply __UNCONST() if it exists. Reminds me: should/can __UNCONST() be revisited w.r.t. the thread below? http://lists.freebsd.org/pipermail/freebsd-arch/2013-May/014371.html How/why? Yes, it's unsafe. That's the *point*. Well, there is an advantage that the FreeBSD one has over ours. It can be used in c++ with -Wold-style-cast, if defined as: #define __DECONST(t, a) const_castt(a) and I suppose one could also do something like this: #define __DECONST(t, v) \ (sizeof((v) - (const t)0) ? (t)(unsigned long)(v) : 0) to make it more or less typesafe at the cost of expanding the value more than once. (And someone might be able to come up with a version that doesn't require that.) As for the unsigned long, we could just use uintptr_t and expect users of the macro to include stdint.h themselves; after all it isn't supposed to be used at all except in certain known special cases. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: xsrc/external/mit/xauth/dist
On Sun, Jun 02, 2013 at 12:40:12AM +, Christos Zoulas wrote: Reminds me: should/can __UNCONST() be revisited w.r.t. the thread below? http://lists.freebsd.org/pipermail/freebsd-arch/2013-May/014371.html How/why? Yes, it's unsafe. That's the *point*. Well, there is an advantage that the FreeBSD one has over ours. It can be used in c++ with -Wold-style-cast, if defined as: #define __DECONST(t, a) const_castt(a) That, and why is it cast to an unsigned long and not uintptr_t? - Jukka.
Re: CVS commit: xsrc/external/mit/xauth/dist
On Jun 3, 5:34am, jruoho...@iki.fi (Jukka Ruohonen) wrote: -- Subject: Re: CVS commit: xsrc/external/mit/xauth/dist | Well, there is an advantage that the FreeBSD one has over ours. It can be | used in c++ with -Wold-style-cast, if defined as: | | #define __DECONST(t, a) const_castt(a) | | That, and why is it cast to an unsigned long and not uintptr_t? So that it does not bring in another header to define uintptr_t. christos
Re: CVS commit: xsrc/external/mit/xauth/dist
On Fri, May 31, 2013 at 12:26:53PM +0300, Jukka Ruohonen wrote: Module Name: xsrc Committed By: mrg Date: Fri May 31 06:46:39 UTC 2013 Modified Files: xsrc/external/mit/xauth/dist: process.c Log Message: apply __UNCONST() if it exists. Reminds me: should/can __UNCONST() be revisited w.r.t. the thread below? http://lists.freebsd.org/pipermail/freebsd-arch/2013-May/014371.html How/why? Yes, it's unsafe. That's the *point*. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: xsrc/external/mit/xauth/dist
In article 20130601232927.ga19...@netbsd.org, David Holland dholland-sourcechan...@netbsd.org wrote: On Fri, May 31, 2013 at 12:26:53PM +0300, Jukka Ruohonen wrote: Module Name: xsrc Committed By: mrg Date: Fri May 31 06:46:39 UTC 2013 Modified Files: xsrc/external/mit/xauth/dist: process.c Log Message: apply __UNCONST() if it exists. Reminds me: should/can __UNCONST() be revisited w.r.t. the thread below? http://lists.freebsd.org/pipermail/freebsd-arch/2013-May/014371.html How/why? Yes, it's unsafe. That's the *point*. Well, there is an advantage that the FreeBSD one has over ours. It can be used in c++ with -Wold-style-cast, if defined as: #define __DECONST(t, a) const_castt(a) christos
Re: CVS commit: xsrc/external/mit/xauth/dist
On Fri, May 31, 2013 at 06:46:39AM +, matthew green wrote: Module Name: xsrc Committed By: mrg Date: Fri May 31 06:46:39 UTC 2013 Modified Files: xsrc/external/mit/xauth/dist: process.c Log Message: apply __UNCONST() if it exists. Reminds me: should/can __UNCONST() be revisited w.r.t. the thread below? http://lists.freebsd.org/pipermail/freebsd-arch/2013-May/014371.html - Jukka.
Re: CVS commit: xsrc/external/mit/xauth/dist
In article 20130531092653.GA24785@marx.bitnet, Jukka Ruohonen jruoho...@iki.fi wrote: On Fri, May 31, 2013 at 06:46:39AM +, matthew green wrote: Module Name: xsrc Committed By:mrg Date:Fri May 31 06:46:39 UTC 2013 Modified Files: xsrc/external/mit/xauth/dist: process.c Log Message: apply __UNCONST() if it exists. Reminds me: should/can __UNCONST() be revisited w.r.t. the thread below? http://lists.freebsd.org/pipermail/freebsd-arch/2013-May/014371.html I am discussing this with them already. christos
