> No new machine will ever have this property because there's too much
> existing code that would break and there's no plausible reason to
> bother.
> Similarly, for all-bits-0 floats, no new machine is going to use
> anything but IEEE floats.
If you really believe those, there's no point in carr
>> see, for example, the example code in 5.2's getaddrinfo(3) manpage.)
> I assume you mean
> memset(&hints, 0, sizeof(hints));
Yes.
> That one is perfectly fine, in any C, the values of the pointer
> fields of hints are irrelevant,
According to the manpage, their values are relevant:
corrections from Mouse:
On Mon, Dec 09, 2013 at 07:02:39AM +, David Holland wrote:
> (2) union of function pointers
>
>r = is_r ? cmpu.cmp(a, b) : cmpu.cmp_r(a, b, data);
this test is backwards.
> void
> sort(void *p, size_t n, size_t sz, int (*cmp)(const void *, const v
On Mon, Dec 09, 2013 at 06:10:36AM +, Alan Barrett wrote:
> >My irritation with not being able to pass a data pointer through
> >qsort() boiled over just now. Apparently Linux and/or GNU has a
> >qsort_r() that supports this; so, following is a patch that gives
> >us a compatible qsort_r()
On Mon, Dec 09, 2013 at 01:49:29AM -0500, Mouse wrote:
> >> Then there are a lot of things that need fixing; the one I'm most
> >> aware of is the assumption that all-bits-0 is a nil pointer.
> > Yes. I think the official stance on that is to worry about it when a
> > real platform appears whe
Date:Mon, 9 Dec 2013 00:59:49 -0500 (EST)
From:Mouse
Message-ID: <201312090559.aaa21...@chip.rodents-montreal.org>
| see, for example, the
| example code in 5.2's getaddrinfo(3) manpage.)
I assume you mean
memset(&hints, 0, sizeof(hints));
That one
On Sun, Dec 08, 2013 at 10:50:15PM +, David Holland wrote:
> > > I have done it by having the original, non-_r functions provide a
> > > thunk for the comparison function, as this is least invasive. If we
> > > think this is too expensive, an alternative is generating a union of
> > > f
>>> [...] I don't think it's a good idea to make any assumptions at all
>>> about things the C standard doesn't guarantee.
>> Then there are a lot of things that need fixing; the one I'm most
>> aware of is the assumption that all-bits-0 is a nil pointer.
> Yes. I think the official stance on that
>>> Is just casting the function pointers safe in C
>> No. As soon as you call through a pointer to the wrong type you're
>> off in nasal demon territory.
> You can't call through a function pointer of the wrong type, but you
> can cast from one type to another.
True. I wrote that with more cont
On Mon, Dec 09, 2013 at 12:59:49AM -0500, Mouse wrote:
> > [...]. In this environment I don't think it's a good idea to make
> > any assumptions at all about things the C standard doesn't guarantee.
>
> Then there are a lot of things that need fixing; the one I'm most aware
> of is the assum
On Sun, 08 Dec 2013, Mouse wrote:
Is just casting the function pointers safe in C
No. As soon as you call through a pointer to the wrong type
you're off in nasal demon territory. (Loosely put; I'd have to
look up the exact wording - there is a little wiggle room, but,
if I've understood th
On Sun, 08 Dec 2013, David Holland wrote:
My irritation with not being able to pass a data pointer through
qsort() boiled over just now. Apparently Linux and/or GNU
has a qsort_r() that supports this; so, following is a patch
that gives us a compatible qsort_r() plus mergesort_r(), and
heapsor
>> If you can find me a description of what NetBSD assumes beyond what
>> C promises, [...]
> I don't think we have such a list.
I didn't think so either, but wasn't nearly sure enough to assume there
wasn't one.
> [...]. In this environment I don't think it's a good idea to make
> any assumptio
On Sun, Dec 08, 2013 at 11:51:15PM -0500, Mouse wrote:
> If you can find me a description of what NetBSD assumes beyond what C
> promises, I can have a stab at answering that question. (I know a few
> of the things, such as "there is an exactly-8-bit type", but I feel
> fairly sure I don't kno
[Should this maybe be moved to tech-toolchain?]
>>> My irritation with not being able to pass a data pointer through
>>> qsort() boiled over just now.
>> This sort of thing is one reason I do not consider nested function
>> support optional in any compiler I consider using: [...]
> Nested function
> Is just casting the function pointers safe in C
No. As soon as you call through a pointer to the wrong type you're off
in nasal demon territory. (Loosely put; I'd have to look up the exact
wording - there is a little wiggle room, but, if I've understood the
subject of the discussion correctly,
On Sun, Dec 08, 2013 at 11:26:47PM +, David Laight wrote:
> > > I have done it by having the original, non-_r functions provide a
> > > thunk for the comparison function, as this is least invasive. If we
> > > think this is too expensive, an alternative is generating a union of
> > > functi
Hi Folks,
Here is a tiny patch that changes the luapmf module for using
luaL_register() function, instead of reimplementing it.
Regards,
--
Lourival Vieira Neto
luapmf-1.patch
Description: Binary data
Hi Folks,
I think the luacore module is misnomer because it is also how the Lua
official distribution refers to its nucleus. Moreover, the luacore
module is, in essence, a binding for sys/systm.h. Thus, a more
appropriate name for this module should be luasystm. Here is a patch
that renames the lu
On Sun, Dec 08, 2013 at 06:21:16PM -0500, Mouse wrote:
> > My irritation with not being able to pass a data pointer through
> > qsort() boiled over just now.
>
> This sort of thing is one reason I do not consider nested function
> support optional in any compiler I consider using: they make it eas
On Sun, Dec 08, 2013 at 10:29:53PM +, David Holland wrote:
>
> I have done it by having the original, non-_r functions provide a
> thunk for the comparison function, as this is least invasive. If we
> think this is too expensive, an alternative is generating a union of
> function pointers and
> My irritation with not being able to pass a data pointer through
> qsort() boiled over just now.
This sort of thing is one reason I do not consider nested function
support optional in any compiler I consider using: they make it easy to
curry away function arguments to generate something suitable
In article <20131208222953.gb25...@netbsd.org>,
David Holland wrote:
>(Cc: tech-kern because of kheapsort())
>
>My irritation with not being able to pass a data pointer through
>qsort() boiled over just now. Apparently Linux and/or GNU has a
>qsort_r() that supports this; so, following is a patch
On Sun, Dec 08, 2013 at 11:44:28PM +0100, Joerg Sonnenberger wrote:
> On Sun, Dec 08, 2013 at 10:29:53PM +, David Holland wrote:
> > I have done it by having the original, non-_r functions provide a
> > thunk for the comparison function, as this is least invasive. If we
> > think this is too ex
On Sun, Dec 08, 2013 at 11:44:28PM +0100, Joerg Sonnenberger wrote:
> > I have done it by having the original, non-_r functions provide a
> > thunk for the comparison function, as this is least invasive. If we
> > think this is too expensive, an alternative is generating a union of
> > function
On Sun, Dec 08, 2013 at 10:29:53PM +, David Holland wrote:
> I have done it by having the original, non-_r functions provide a
> thunk for the comparison function, as this is least invasive. If we
> think this is too expensive, an alternative is generating a union of
> function pointers and mak
(Cc: tech-kern because of kheapsort())
My irritation with not being able to pass a data pointer through
qsort() boiled over just now. Apparently Linux and/or GNU has a
qsort_r() that supports this; so, following is a patch that gives us
a compatible qsort_r() plus mergesort_r(), and heapsort_r().
27 matches
Mail list logo
