On Tue, 16 Jul 2002, David Taylor wrote:
Bah, ignore me, it appears you've already admitted your post was rather
less than clear :)
--
David Taylor
[EMAIL PROTECTED]
"The future just ain't what it used to be"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in
On Mon, 15 Jul 2002, Terry Lambert wrote:
> Thomas Moestl wrote:
> > > He's making the valid point that for:
> > >
> > > struct foo *fee;
> > >
> > > It's possible that:
> > >
> > > sizeof(struct foo) != (((char *)&fee[1]) - ((char *)&fee[0]))
> >
> > No, I do not. In fact, the opposi
Richard Tobin wrote:
> It is not a valid point that it's possible that
>
> sizeof(struct foo) != (((char *)&fee[1]) - ((char *)&fee[0]))
>
> because it isn't possible. It must be the case that
>
> sizeof(struct foo) == (((char *)&fee[1]) - ((char *)&fee[0]))
>
> If that's what you meant,
> If everyone could read the text past my example of bad math, so
> that they could know it was an intentional example of bad math,
> live would be beautiful. 8-).
I did read past it, and I just read it again, and I can't make it come
out any way other than it did the first time.
You said:
> H
Richard Tobin wrote:
> Er, no, that's not right. Otherwise
[ ... ]
If everyone could read the text past my example of bad math, so
that they could know it was an intentional example of bad math,
live would be beautiful. 8-).
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsub
Peter Edwards wrote:
> > He's making the valid point that for:
> >
> > struct foo *fee;
> >
> > It's possible that:
> >
> > sizeof(struct foo) != (((char *)&fee[1]) - ((char *)&fee[0]))
>
> Wouldn't that mean
>
> .. struct X *xarr = malloc(sizeof (struct X) * arrayLen);
>
> woul
Thomas Moestl wrote:
> > He's making the valid point that for:
> >
> > struct foo *fee;
> >
> > It's possible that:
> >
> > sizeof(struct foo) != (((char *)&fee[1]) - ((char *)&fee[0]))
>
> No, I do not. In fact, the opposite:
>
> sizeof(struct foo) = (((char *)&fee[1]) - ((c
Thomas Moestl <[EMAIL PROTECTED]> writes:
> Oh, right, that's related: the kernel checks for a minimum size of the
> passed data on two occasions, first in sooptcopyin(), and then again
> in check_ipfw_struct().
> It the size to be at least sizeof(struct ip_fw), however for
> structures containing
ok, convincing explaination, thanks!
I will review the code and try to implement a proper fix,
not the workaround that I put in.
cheers
luigi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
> struct foo *fee;
>
> It's possible that:
>
> sizeof(struct foo) != (((char *)&fee[1]) - ((char *)&fee[0]))
>
> because of end-padding, which is not accounted for in arrays,
Er, no, that's not right. Otherwise
fee = malloc(n * sizeof(struct foo))
wouldn't work.
C89 says:
Hi,
> He's making the valid point that for:
>
> struct foo *fee;
>
> It's possible that:
>
> sizeof(struct foo) != (((char *)&fee[1]) - ((char *)&fee[0]))
Wouldn't that mean
.. struct X *xarr = malloc(sizeof (struct X) * arrayLen);
wouldn't produce a useable array of struct X o
On Mon, 2002/07/15 at 04:24:33 -0700, Terry Lambert wrote:
> Luigi Rizzo wrote:
> > sorry but all this just does not make sense to me.
> >
> > sizeof(foo) should give the same result irrespective of
> > where you use it.
> >
> > Perhaps the best thing would be to put a
> >
> > printf("s
On Mon, 2002/07/15 at 04:00:08 -0700, Luigi Rizzo wrote:
> sorry but all this just does not make sense to me.
>
> sizeof(foo) should give the same result irrespective of
> where you use it.
OK, let me rephrase it: as I explained before, struct ip_fw has padding
after 'cmd' (the last member) to e
Luigi Rizzo wrote:
> sorry but all this just does not make sense to me.
>
> sizeof(foo) should give the same result irrespective of
> where you use it.
>
> Perhaps the best thing would be to put a
>
> printf("struct ip_fw has size %d\n", sizeof(struct ip_fw));
>
> both in ipfw2.c and s
sorry but all this just does not make sense to me.
sizeof(foo) should give the same result irrespective of
where you use it.
Perhaps the best thing would be to put a
printf("struct ip_fw has size %d\n", sizeof(struct ip_fw));
both in ipfw2.c and somewhere in ip_fw2.c and see if there i
On Sun, 2002/07/14 at 23:08:21 -0400, Mike Barcroft wrote:
> Thomas Moestl <[EMAIL PROTECTED]> writes:
> > (Disclaimer: my solution below is untested, so it may all be bogus)
>
> As request, here are the test results.
>
> Most rules work, except my final one:
> %%%
> bowie# ipfw add allow all fr
Thomas Moestl <[EMAIL PROTECTED]> writes:
> (Disclaimer: my solution below is untested, so it may all be bogus)
As request, here are the test results.
Most rules work, except my final one:
%%%
bowie# ipfw add allow all from any to any
ipfw: getsockopt(IP_FW_ADD): Invalid argument
%%%
Here's a l
On Sun, 2002/07/14 at 13:43:37 -0700, Luigi Rizzo wrote:
> [i am deliberately not trimming the email in case someone wants to
> look at the context]
>
> i am a bit dubious about your explaination -- it also does not
> explain why the person reporting this problem "fixed" that
> by swapping "times
[i am deliberately not trimming the email in case someone wants to
look at the context]
i am a bit dubious about your explaination -- it also does not
explain why the person reporting this problem "fixed" that
by swapping "timestamp" and "next_rule" in the structure
cheers
luigi
On Sun, 2002/07/14 at 01:18:10 -0700, Luigi Rizzo wrote:
> Hi,
> the following message seems to suggest that the compiler
> (the way it is invoked) packs structures differently
> when building the kernel and userland.
>
> The stize of the structure in question is computed
> by both kernel and use
Luigi Rizzo wrote:
> Hi,
> the following message seems to suggest that the compiler
> (the way it is invoked) packs structures differently
> when building the kernel and userland.
>
> The stize of the structure in question is computed
> by both kernel and userland app using sizeof(),
> so there i
21 matches
Mail list logo
