[17493] in Kerberos_V5_Development
Re: Proposed platform assumption changes
daemon@ATHENA.MIT.EDU (Nico Williams)
Tue Jan 31 16:42:45 2012
MIME-Version: 1.0
In-Reply-To: <4F28430F.2070809@mit.edu>
Date: Tue, 31 Jan 2012 15:42:41 -0600
Message-ID: <CAK3OfOiqQ8-3zJDq+AUWXn5pwFYNKYG9xCuxkAssTbWm=8tbEQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Tue, Jan 31, 2012 at 1:37 PM, Greg Hudson <ghudson@mit.edu> wrote:
> Summarizing this thread and the likely outcomes:
>
> * No one voiced concerns about assuming IPv6, variadic macros, and
> failure-free mutex locking and unlocking. So I think we're likely to
> assume those.
No objection.
> * No one raised concerns about assuming POSIX signal support in Unix
> code, although it's worth noting that Windows has signal() but not
> sigaction(). It turns out we don't install signal handlers in any code
> built on Windows at the moment, so I think we're likely to assume POSIX
> signal support.
All the Unix-ish OSes you care about support POSIX signals, so there's
no reason to object to the use of POSIX signals as opposed to the old
Unix signal(2) interface.
However, as much as possible libraries should not use signals. Right
now the only use of signals in an MIT krb5 library is
krb5_prompter_posix(), which seems fair enough.
> * The idea of using an aborting malloc wrapper inside library code is
> objectionable.
Yes.
> * People would really like C99 designated initializers, but the ways of
> getting them (dumping MSVC) or sort of getting them (ugly macros) are
> objectionable.
I've had to chase function calls across function tables/vtables/ops
vectors/whatever you want to call them a few times in the past two
days. Each time I want to chase something like "cache->ops->store" to
all the ccache store functions, say, I can't do it with a trivial
cscope symbol search. No, such searches are painful. I don't care
how ugly the macros are: they would make my life simpler. The lack of
support for this makes me wonder if I might be the only one in this
community using cscope.
There's another way though: at least for ops vectors you could have
the initializers generated by a script that generates code that the
compiler can consume, and if your compiler handles designated
initializers, then you get code that uses designated initializers. No
macros this way, but you have to build to find the struct initializers
(but that's already true for, e.g., error tables).
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
