BHyVe - few questions as i don't catch on idea
i am very happy of such software being done - natively on freebsd. it seems very logic - separate memory for main FreeBSD system and separate for VMs, main FreeBSD system handles I/O. Great but i really don't understand what is the sense to run FreeBSD VM under FreeBSD - and that's what now it does. I don't need virtualization to run FreeBSD instances - it doesn't need it because it is already efficient multiuser and multitasking system. Virtualization is needed to make software and OSes that cannot really be efficiently multiuser and multitasking - to do so, by running multiple instances on the same machine. and as to preserve outdated software as is. Running one or few instances of windows is prime example. Is this planned in BHyVe? Would be great. I wished before than linux KVM driver could be ported to FreeBSD as it (+qemu itselv) already solves all needs. but i found this port will not be continued. I run virtualbox for now but it is far from efficient in speed and ever worse in usage, as it does everything to make it difficult (UUIDs, XML config files). Compared to this qemu is trivially simple, as well as BHyVe. Xen is completely inefficient as it adds overhead to everything, not just virtualized instances, because domain0 runs in VM too. thanks. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: A few questions...
In message: [EMAIL PROTECTED] Daniel Molina Wegener [EMAIL PROTECTED] writes: : : Hello, : :I need information about few things, I hope someone can help : me and thanks in advance. : : a) Is there any function or variable that tells me which is the :root user UID in the system, or root always have 0 and it's :an elegant option to compare the variables or structure :members against zero. The super user is always UID == 0. By definition. The root account typically is 0, but doesn't have to be. User accounts typically aren't 0, but can be (cf toor). Any account with a uid of 0 is a super user. It is the super user that gets all the toys. : b) Can normal users look for system processes or kernel threads? Sometimes. See the sysctls security.bsd.see_other_gids and security.bsd.see_other_uids. : c) Can root look for system processes or kernel threads? If it is the super user, yes. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A few questions...
2007/7/26, John-Mark Gurney [EMAIL PROTECTED]:
Victor Loureiro Lima wrote this message on Wed, Jul 25, 2007 at 12:14 -0300:
2007/7/24, John-Mark Gurney [EMAIL PROTECTED]:
Victor Loureiro Lima wrote this message on Tue, Jul 24, 2007 at 16:35
-0300:
2007/7/24, John-Mark Gurney [EMAIL PROTECTED]:
Daniel Molina Wegener wrote this message on Mon, Jul 23, 2007 at 20:52
-0400:
a) Is there any function or variable that tells me which is the
root user UID in the system, or root always have 0 and it's
an elegant option to compare the variables or structure
members against zero.
#include sys/conf.h
uid == UID_ROOT
b) Can normal users look for system processes or kernel threads?
Yes, ps does this...
ps(1) either elevates its priviledges during execution, or has some
other way of medling into the afairs of other processes that will
eventually need some higher priviledge status (either that, or I am
really out-dated on modern operational systems)
hydrogen,ttypm,/home/johng,503$ls -l /bin/ps
-r-xr-xr-x 1 root wheel 31372 May 8 2005 /bin/ps*
So, as you see, no suid or sgid necessary for ps to function...
FreeBSD exports most/all of the info through sysctl which does not
require elevated privs to get...
And ps doesn't medling.. it's just a voyeur..
hahaha I liked that phrase ;)
Check this out:
http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/ps/ps.c?rev=1.106.2.2;content-type=text%2Fplain
Turns out ps(1) uses libkvm, more specifically kvm_getprocs() function
(the function that I said was in the middle of my last experience on
getting process information from FreeBSD ;)) Im pretty sure it doesnt
get _any_ of its info thru sysctl's, but using the kvm interface which
is simple, clean and orthogonal, however I guess I was a little bit
incorrect in my last email, ps(1) in its common execution mode will
Have you looked at the source to kvm_getprocs(3)?
struct kinfo_proc *
kvm_getprocs(kd, op, arg, cnt)
[...]
{
[...]
if (ISALIVE(kd)) {
size = 0;
mib[0] = CTL_KERN;
mib[1] = KERN_PROC;
mib[2] = op;
mib[3] = arg;
temp_op = op ~KERN_PROC_INC_THREAD;
st = sysctl(mib,
temp_op == KERN_PROC_ALL || temp_op == KERN_PROC_PROC ?
3 : 4, NULL, size, NULL, 0);
[...]
So, yes, ps isn't using sysctl directly, but kvm_getprocs is... And
if you look at -current's ps(1):
-a Display information about other users' processes as well as your
own. This will skip any processes which do not have a control-
ling terminal, unless the -x option is also specified. This can
be disabled by setting the security.bsd.see_other_uids sysctl to
zero.
and security.bsd.see_other_uids defaults to 1...
Check-mate ;) I am defeated!!! But at least it was illustrative (for
me). But getting back on the topic, the prefered way is using
kvm_getprocs(3) (for historic purposes on the list ;))
cheers and hugs,
victor f. loureiro lima
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A few questions...
Victor Loureiro Lima wrote this message on Wed, Jul 25, 2007 at 12:14 -0300:
2007/7/24, John-Mark Gurney [EMAIL PROTECTED]:
Victor Loureiro Lima wrote this message on Tue, Jul 24, 2007 at 16:35
-0300:
2007/7/24, John-Mark Gurney [EMAIL PROTECTED]:
Daniel Molina Wegener wrote this message on Mon, Jul 23, 2007 at 20:52
-0400:
a) Is there any function or variable that tells me which is the
root user UID in the system, or root always have 0 and it's
an elegant option to compare the variables or structure
members against zero.
#include sys/conf.h
uid == UID_ROOT
b) Can normal users look for system processes or kernel threads?
Yes, ps does this...
ps(1) either elevates its priviledges during execution, or has some
other way of medling into the afairs of other processes that will
eventually need some higher priviledge status (either that, or I am
really out-dated on modern operational systems)
hydrogen,ttypm,/home/johng,503$ls -l /bin/ps
-r-xr-xr-x 1 root wheel 31372 May 8 2005 /bin/ps*
So, as you see, no suid or sgid necessary for ps to function...
FreeBSD exports most/all of the info through sysctl which does not
require elevated privs to get...
And ps doesn't medling.. it's just a voyeur..
hahaha I liked that phrase ;)
Check this out:
http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/ps/ps.c?rev=1.106.2.2;content-type=text%2Fplain
Turns out ps(1) uses libkvm, more specifically kvm_getprocs() function
(the function that I said was in the middle of my last experience on
getting process information from FreeBSD ;)) Im pretty sure it doesnt
get _any_ of its info thru sysctl's, but using the kvm interface which
is simple, clean and orthogonal, however I guess I was a little bit
incorrect in my last email, ps(1) in its common execution mode will
Have you looked at the source to kvm_getprocs(3)?
struct kinfo_proc *
kvm_getprocs(kd, op, arg, cnt)
[...]
{
[...]
if (ISALIVE(kd)) {
size = 0;
mib[0] = CTL_KERN;
mib[1] = KERN_PROC;
mib[2] = op;
mib[3] = arg;
temp_op = op ~KERN_PROC_INC_THREAD;
st = sysctl(mib,
temp_op == KERN_PROC_ALL || temp_op == KERN_PROC_PROC ?
3 : 4, NULL, size, NULL, 0);
[...]
So, yes, ps isn't using sysctl directly, but kvm_getprocs is... And
if you look at -current's ps(1):
-a Display information about other users' processes as well as your
own. This will skip any processes which do not have a control-
ling terminal, unless the -x option is also specified. This can
be disabled by setting the security.bsd.see_other_uids sysctl to
zero.
and security.bsd.see_other_uids defaults to 1...
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A few questions...
2007/7/24, John-Mark Gurney [EMAIL PROTECTED]:
Victor Loureiro Lima wrote this message on Tue, Jul 24, 2007 at 16:35 -0300:
2007/7/24, John-Mark Gurney [EMAIL PROTECTED]:
Daniel Molina Wegener wrote this message on Mon, Jul 23, 2007 at 20:52
-0400:
a) Is there any function or variable that tells me which is the
root user UID in the system, or root always have 0 and it's
an elegant option to compare the variables or structure
members against zero.
#include sys/conf.h
uid == UID_ROOT
b) Can normal users look for system processes or kernel threads?
Yes, ps does this...
ps(1) either elevates its priviledges during execution, or has some
other way of medling into the afairs of other processes that will
eventually need some higher priviledge status (either that, or I am
really out-dated on modern operational systems)
hydrogen,ttypm,/home/johng,503$ls -l /bin/ps
-r-xr-xr-x 1 root wheel 31372 May 8 2005 /bin/ps*
So, as you see, no suid or sgid necessary for ps to function...
FreeBSD exports most/all of the info through sysctl which does not
require elevated privs to get...
And ps doesn't medling.. it's just a voyeur..
hahaha I liked that phrase ;)
Check this out:
http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/ps/ps.c?rev=1.106.2.2;content-type=text%2Fplain
Turns out ps(1) uses libkvm, more specifically kvm_getprocs() function
(the function that I said was in the middle of my last experience on
getting process information from FreeBSD ;)) Im pretty sure it doesnt
get _any_ of its info thru sysctl's, but using the kvm interface which
is simple, clean and orthogonal, however I guess I was a little bit
incorrect in my last email, ps(1) in its common execution mode will
attempt to retrieve only the
processes information that are pertinent to the current user uid, as
this snippets from
ps.c shows:
-
kd = kvm_openfiles(nlistf, memf, NULL, O_RDONLY, errbuf);
if (kd == 0)
errx(1, %s, errbuf);
if (!_fmt)
parsefmt(dfmt, 0);
if (nselectors == 0) {
uidlist.l.ptr = malloc(sizeof(uid_t));
if (uidlist.l.ptr == NULL)
errx(1, malloc failed);
nselectors = 1;
uidlist.count = uidlist.maxcount = 1;
*uidlist.l.uids = getuid();
}
-
So yes, you are correct, it wont need any root priviledge in order
to get the information
about its own processes, but it will need root priviledge to get
information on all process running on the system (am I correct? I am
assuming a lot of things based on very little source-code reading, so
feel free to bash me if I am wrong ;))
I guess the whole sanity checking for permission is done inside
libkvm somewhere ;)
cheers,
victor f. loureiro lima
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A few questions...
On 7/23/07, Darren Pilgrim [EMAIL PROTECTED] wrote: Daniel Molina Wegener wrote: Hello, I need information about few things, I hope someone can help me and thanks in advance. a) Is there any function or variable that tells me which is the root user UID in the system, or root always have 0 and it's an elegant option to compare the variables or structure members against zero. Root is always UID 0. Checking UID == 0 is the common practice for determining if the effective UID has root priveleges. But should it be common practice? What of suser(9) and priv(9)? -Ben Kaduk ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A few questions...
On Tue, Jul 24, 2007 at 12:37:53AM -0500, Ben Kaduk wrote: On 7/23/07, Darren Pilgrim [EMAIL PROTECTED] wrote: Daniel Molina Wegener wrote: Hello, I need information about few things, I hope someone can help me and thanks in advance. a) Is there any function or variable that tells me which is the root user UID in the system, or root always have 0 and it's an elegant option to compare the variables or structure members against zero. Root is always UID 0. Checking UID == 0 is the common practice for determining if the effective UID has root priveleges. But should it be common practice? What of suser(9) and priv(9)? In userspace it's what you have to do if you're going to check privleges. In general though, you shouldn't check at all and just attempt the operation and let the kernel decide (there are of course exceptions to this rule). In the kernel you should use priv(9). -- Brooks pgpokK2vdLPUj.pgp Description: PGP signature
Re: A few questions...
Daniel Molina Wegener wrote this message on Mon, Jul 23, 2007 at 20:52 -0400: a) Is there any function or variable that tells me which is the root user UID in the system, or root always have 0 and it's an elegant option to compare the variables or structure members against zero. #include sys/conf.h uid == UID_ROOT b) Can normal users look for system processes or kernel threads? Yes, ps does this... c) Can root look for system processes or kernel threads? Yes, ps does this... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A few questions...
2007/7/24, John-Mark Gurney [EMAIL PROTECTED]: Daniel Molina Wegener wrote this message on Mon, Jul 23, 2007 at 20:52 -0400: a) Is there any function or variable that tells me which is the root user UID in the system, or root always have 0 and it's an elegant option to compare the variables or structure members against zero. #include sys/conf.h uid == UID_ROOT b) Can normal users look for system processes or kernel threads? Yes, ps does this... ps(1) either elevates its priviledges during execution, or has some other way of medling into the afairs of other processes that will eventually need some higher priviledge status (either that, or I am really out-dated on modern operational systems) There lots of ways of finding information on other process, using libkvm was the most recent option that I saw ;) might be worth taking a look at it... victor loureiro lima ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A few questions...
Victor Loureiro Lima wrote this message on Tue, Jul 24, 2007 at 16:35 -0300: 2007/7/24, John-Mark Gurney [EMAIL PROTECTED]: Daniel Molina Wegener wrote this message on Mon, Jul 23, 2007 at 20:52 -0400: a) Is there any function or variable that tells me which is the root user UID in the system, or root always have 0 and it's an elegant option to compare the variables or structure members against zero. #include sys/conf.h uid == UID_ROOT b) Can normal users look for system processes or kernel threads? Yes, ps does this... ps(1) either elevates its priviledges during execution, or has some other way of medling into the afairs of other processes that will eventually need some higher priviledge status (either that, or I am really out-dated on modern operational systems) hydrogen,ttypm,/home/johng,503$ls -l /bin/ps -r-xr-xr-x 1 root wheel 31372 May 8 2005 /bin/ps* So, as you see, no suid or sgid necessary for ps to function... FreeBSD exports most/all of the info through sysctl which does not require elevated privs to get... And ps doesn't medling.. it's just a voyeur.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
A few questions...
Hello, I need information about few things, I hope someone can help me and thanks in advance. a) Is there any function or variable that tells me which is the root user UID in the system, or root always have 0 and it's an elegant option to compare the variables or structure members against zero. b) Can normal users look for system processes or kernel threads? c) Can root look for system processes or kernel threads? Regards, -- .O. | Daniel Molina Wegener | C/C++ Developer ..O | dmw [at] unete [dot] cl | FOSS Coding Adict OOO | FreeBSD Linux User| Standards Rocks! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A few questions...
Daniel Molina Wegener wrote: Hello, I need information about few things, I hope someone can help me and thanks in advance. a) Is there any function or variable that tells me which is the root user UID in the system, or root always have 0 and it's an elegant option to compare the variables or structure members against zero. Root is always UID 0. Checking UID == 0 is the common practice for determining if the effective UID has root priveleges. b) Can normal users look for system processes or kernel threads? Yes, depending on the value of the security.bsd.see_other_uids sysctl. If security.bsd.see_other_uids=0, non-root users can only see their own processes. c) Can root look for system processes or kernel threads? Yes, regardless of the value of security.bsd.see_other_uids. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A few questions about a few includes
Lowell Gilbert [EMAIL PROTECTED] wrote:
C-99 requires a fully specified type before the unspecified array (and
requires said array to be the last element in the structure). So this
example is *not* valid in C99, but the following would be:
struct foo {
int bar;
char array[];
};
[Which makes sense; it forces a structure to have a non-zero size.]
Although there has been some discussion in the committee about allowing
zero-sized objects in C, the standard doesn't allow them. This is perhaps
why it doesn't follow gcc's [0] syntax for variable length arrays at the
end of structures.
Tony.
--
f.a.n.finch [EMAIL PROTECTED]
THAMES DOVER WIGHT PORTLAND PLYMOUTH: WEST OR SOUTHWEST 5 TO 7 DECREASING 4.
DRIZZLE DYING OUT. MODERATE, OCCASIONALLY POOR, BECOMING GOOD.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: A few questions about a few includes
On Sun, 3 Mar 2002, Erik Trulsson wrote:
ETOn Sun, Mar 03, 2002 at 10:27:17AM -0700, Ian wrote:
ET
ET In sys/proc.h:
ET
ET /*
ET * pargs, used to hold a copy of the command line, if it had a sane
ET * length
ET */
ET struct pargs {
ET u_int ar_ref; /* Reference count */
ET u_int ar_length; /* Length */
ET u_char ar_args[0]; /* Arguments */
ET };
ET
ET This does indeed seem to make little or no sense. Could someone explain
ET this? Is ar_args supposed to be a pointer or what?
ET
ET This is a common technique for defining a structure which is some
ET descriptive information about an array of objects is followed by an
ET open-ended array of those objects. (In this case the objects are
ET characters.) The ar_args member of the structure gives a name to that
ET location in the structure without reserving any space (and thus when the
ET technique is used, there can only ever be one [0] member and it must be at
ET the end of the structure). You access the open-ended array of objects just
ET as you would any other array embedded within a structure, E.G.
ET instance-ar_args[n].
ET
ET Not all compilers support defining zero-length arrays like this. And that's
ET a pity; it's an incredibly useful technique, and the alternatives to it are
ET not nearly as elegant and generally involve ugly recasting of pointers.
ET
ETFor those compilers that don't support zero-length arrays one can still
ETuse the same trick but with a one-element array at the end of the
ETstruct. One just has to remember to that element into account when
ETallocating memory for the structure. Slightly uglier, but not much.
ET
ETIt might be worth mentioning that this trick is not actually allowed
ETaccording to the C standard and in principle invokes undefined
ETbehaviour. OTOH, AFAIK the trick does work on all existing compilers,
ETso while it is not standard-conforming it is quite portable.
My ISO-C draft copy allows in section 6.7.2.1 paragraph 2 the last member
of a structure to be an incomplete array type and paragraph 16 shows an
example. Was this removed from the final standard?
harti
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: A few questions about a few includes
On Mon, Mar 04, 2002 at 10:29:18AM +0100, Harti Brandt wrote:
On Sun, 3 Mar 2002, Erik Trulsson wrote:
ETOn Sun, Mar 03, 2002 at 10:27:17AM -0700, Ian wrote:
ET
ET In sys/proc.h:
ET
ET /*
ET * pargs, used to hold a copy of the command line, if it had a sane
ET * length
ET */
ET struct pargs {
ET u_int ar_ref; /* Reference count */
ET u_int ar_length; /* Length */
ET u_char ar_args[0]; /* Arguments */
ET };
ET
ET This does indeed seem to make little or no sense. Could someone explain
ET this? Is ar_args supposed to be a pointer or what?
ET
ET This is a common technique for defining a structure which is some
ET descriptive information about an array of objects is followed by an
ET open-ended array of those objects. (In this case the objects are
ET characters.) The ar_args member of the structure gives a name to that
ET location in the structure without reserving any space (and thus when the
ET technique is used, there can only ever be one [0] member and it must be at
ET the end of the structure). You access the open-ended array of objects just
ET as you would any other array embedded within a structure, E.G.
ET instance-ar_args[n].
ET
ET Not all compilers support defining zero-length arrays like this. And that's
ET a pity; it's an incredibly useful technique, and the alternatives to it are
ET not nearly as elegant and generally involve ugly recasting of pointers.
ET
ETFor those compilers that don't support zero-length arrays one can still
ETuse the same trick but with a one-element array at the end of the
ETstruct. One just has to remember to that element into account when
ETallocating memory for the structure. Slightly uglier, but not much.
ET
ETIt might be worth mentioning that this trick is not actually allowed
ETaccording to the C standard and in principle invokes undefined
ETbehaviour. OTOH, AFAIK the trick does work on all existing compilers,
ETso while it is not standard-conforming it is quite portable.
My ISO-C draft copy allows in section 6.7.2.1 paragraph 2 the last member
of a structure to be an incomplete array type and paragraph 16 shows an
example. Was this removed from the final standard?
I think it is still there (and my draft copy says the same thing).
I was thinking about the original C89 standard which does not allow it
(and does not allow incomplete array types in structs). Guess I should
have said which standard I was referring to.
harti
--
harti brandt,
http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED]
--
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: A few questions about a few includes
In message: [EMAIL PROTECTED]
Erik Trulsson [EMAIL PROTECTED] writes:
: I think it is still there (and my draft copy says the same thing).
: I was thinking about the original C89 standard which does not allow it
: (and does not allow incomplete array types in structs). Guess I should
: have said which standard I was referring to.
struct foo {
char array[0];
};
appears to be in C-99 but not C-89. If you have the draft, so far the
only thing I've noticed that is different between the draft and the
final standard is that there's 10-15 more footnotes in the final
standard than were in the final draft.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: A few questions about a few includes
On Mon, 4 Mar 2002, M. Warner Losh wrote:
MWLIn message: [EMAIL PROTECTED]
MWLErik Trulsson [EMAIL PROTECTED] writes:
MWL: I think it is still there (and my draft copy says the same thing).
MWL: I was thinking about the original C89 standard which does not allow it
MWL: (and does not allow incomplete array types in structs). Guess I should
MWL: have said which standard I was referring to.
MWL
MWLstruct foo {
MWL char array[0];
MWL};
MWL
MWLappears to be in C-99 but not C-89. If you have the draft, so far
MWLthe only thing I've noticed that is different between the draft
MWLand the final standard is that there's 10-15 more footnotes in the
MWLfinal standard than were in the final draft.
MWL
MWLWarner
This should be
struct foo {
char array[];
};
according to C-99, on which gcc2 barfs. Don't know, whether gcc3 can
handle this.
harti
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Re: A few questions about a few includes
On Mon, Mar 04, 2002 at 09:35:29AM -0700, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Erik Trulsson [EMAIL PROTECTED] writes:
: I think it is still there (and my draft copy says the same thing).
: I was thinking about the original C89 standard which does not allow it
: (and does not allow incomplete array types in structs). Guess I should
: have said which standard I was referring to.
struct foo {
char array[0];
};
appears to be in C-99 but not C-89. If you have the draft, so far the
only thing I've noticed that is different between the draft and the
final standard is that there's 10-15 more footnotes in the final
standard than were in the final draft.
Warner
Are you sure that is in C99?
What is allowed in C99 (but wasn't in C89) is
struct foo
{
int b;
char array[];
};
Note that you must have a 'normal' field before the incomplete array.
I don't think
char array[0];
is allowed in either of C89 or C99.
--
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: A few questions about a few includes
Erik Trulsson [EMAIL PROTECTED] writes:
On Mon, Mar 04, 2002 at 09:35:29AM -0700, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Erik Trulsson [EMAIL PROTECTED] writes:
: I think it is still there (and my draft copy says the same thing).
: I was thinking about the original C89 standard which does not allow it
: (and does not allow incomplete array types in structs). Guess I should
: have said which standard I was referring to.
struct foo {
char array[0];
};
appears to be in C-99 but not C-89. If you have the draft, so far the
only thing I've noticed that is different between the draft and the
final standard is that there's 10-15 more footnotes in the final
standard than were in the final draft.
Warner
Are you sure that is in C99?
What is allowed in C99 (but wasn't in C89) is
struct foo
{
int b;
char array[];
};
Note that you must have a 'normal' field before the incomplete array.
I don't think
char array[0];
is allowed in either of C89 or C99.
Correct on all counts. I'll cite the letter of the law from C99 if
anybody really cares.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: A few questions about a few includes
Harti Brandt [EMAIL PROTECTED] writes:
This should be
struct foo {
char array[];
};
according to C-99, on which gcc2 barfs. Don't know, whether gcc3 can
handle this.
C-99 requires a fully specified type before the unspecified array (and
requires said array to be the last element in the structure). So this
example is *not* valid in C99, but the following would be:
struct foo {
int bar;
char array[];
};
[Which makes sense; it forces a structure to have a non-zero size.]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
A few questions about a few includes
Am I just completely stupid, or do we have a few things that could use a
little cleaning up in /usr/include as well as in the man page for kvm_*?
System: FreeBSD 4.5-STABLE
1) The man page for the kvm_* functions lists the following #include
dependencies:
#include kvm.h
#include sys/param.h
#include sys/sysctl.h
However, kvm.h contains some declarations that also require sys/proc.h and
sys/user.h (namely, struct kinfo_proc and struct proc). Otherwise, one
might encounter warnings/errors re: incomplete types.
2) If compiling with the -pedantic switch, one might see something like
this:
In file included from main.c:151:
/usr/include/sys/proc.h:108: warning: ANSI C forbids zero-size array
`ar_args'
In sys/proc.h:
/*
* pargs, used to hold a copy of the command line, if it had a sane
* length
*/
struct pargs {
u_int ar_ref; /* Reference count */
u_int ar_length; /* Length */
u_char ar_args[0]; /* Arguments */
};
This does indeed seem to make little or no sense. Could someone explain
this? Is ar_args supposed to be a pointer or what?
3) Furthermore, on including sys/user.h, one then sees this:
In file included from /usr/include/sys/user.h:40,
from main.c:153:
/usr/include/machine/pcb.h:90: warning: struct has no members
In machine/pcb.h:
/*
* The pcb is augmented with machine-dependent additional data for
* core dumps. For the i386: ???
*/
struct md_coredump {
};
Nowhere under /usr/include is a more complete definition of md_coredump to
be found. This looks awfully kludgy to me.
I do hope someone can shed some light here. Thanks.
--
Conrad Sabatier [EMAIL PROTECTED]
First Rule of History:
History doesn't repeat itself -- historians merely repeat each
other.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: A few questions about a few includes
In sys/proc.h:
/*
* pargs, used to hold a copy of the command line, if it had a sane
* length
*/
struct pargs {
u_int ar_ref; /* Reference count */
u_int ar_length; /* Length */
u_char ar_args[0]; /* Arguments */
};
This does indeed seem to make little or no sense. Could someone explain
this? Is ar_args supposed to be a pointer or what?
This is a common technique for defining a structure which is some
descriptive information about an array of objects is followed by an
open-ended array of those objects. (In this case the objects are
characters.) The ar_args member of the structure gives a name to that
location in the structure without reserving any space (and thus when the
technique is used, there can only ever be one [0] member and it must be at
the end of the structure). You access the open-ended array of objects just
as you would any other array embedded within a structure, E.G.
instance-ar_args[n].
Not all compilers support defining zero-length arrays like this. And that's
a pity; it's an incredibly useful technique, and the alternatives to it are
not nearly as elegant and generally involve ugly recasting of pointers.
-- Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: A few questions about a few includes
On Sun, Mar 03, 2002 at 10:27:17AM -0700, Ian wrote:
In sys/proc.h:
/*
* pargs, used to hold a copy of the command line, if it had a sane
* length
*/
struct pargs {
u_int ar_ref; /* Reference count */
u_int ar_length; /* Length */
u_char ar_args[0]; /* Arguments */
};
This does indeed seem to make little or no sense. Could someone explain
this? Is ar_args supposed to be a pointer or what?
This is a common technique for defining a structure which is some
descriptive information about an array of objects is followed by an
open-ended array of those objects. (In this case the objects are
characters.) The ar_args member of the structure gives a name to that
location in the structure without reserving any space (and thus when the
technique is used, there can only ever be one [0] member and it must be at
the end of the structure). You access the open-ended array of objects just
as you would any other array embedded within a structure, E.G.
instance-ar_args[n].
Not all compilers support defining zero-length arrays like this. And that's
a pity; it's an incredibly useful technique, and the alternatives to it are
not nearly as elegant and generally involve ugly recasting of pointers.
For those compilers that don't support zero-length arrays one can still
use the same trick but with a one-element array at the end of the
struct. One just has to remember to that element into account when
allocating memory for the structure. Slightly uglier, but not much.
It might be worth mentioning that this trick is not actually allowed
according to the C standard and in principle invokes undefined
behaviour. OTOH, AFAIK the trick does work on all existing compilers,
so while it is not standard-conforming it is quite portable.
--
Insert your favourite quote here.
Erik Trulsson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: A few questions about a few includes
On Sunday 03 March 2002 10:19 am, Conrad Sabatier wrote:
Am I just completely stupid, or do we have a few things that could use a
little cleaning up in /usr/include as well as in the man page for kvm_*?
System: FreeBSD 4.5-STABLE
2) If compiling with the -pedantic switch, one might see something like
this:
In file included from main.c:151:
/usr/include/sys/proc.h:108: warning: ANSI C forbids zero-size array
`ar_args'
In sys/proc.h:
/*
* pargs, used to hold a copy of the command line, if it had a sane
* length
*/
struct pargs {
u_int ar_ref; /* Reference count */
u_int ar_length; /* Length */
u_char ar_args[0]; /* Arguments */
};
This does indeed seem to make little or no sense. Could someone explain
this? Is ar_args supposed to be a pointer or what?
I can explain this one; it's a moderately-common C programming technique.
This strucuture will be allocated dynamically. I could be declared like
struct pargs { ... u_char *ar_args; }
and allocated like
pargs = malloc(sizeof(struct pargs));
pargs-ar_args = malloc(args_size);
but it's a lot more efficient to declare it as above and allocate it as
pargs = malloc(sizeof(struct pargs) + args_+size);
since pointers arrays are equivalent, except that array data is at the
location of the name rather than having a pointer to the data at that
location, a [0] array has exactly the right semantics for this. You can
declare a [1] array for this to make ANSI happy, but then you have to
subtract in the allocation and besides that the [0] is self-documenting for
those who are familir with the technique--after all, there isn't anything
*else* you can do with a [0]-sized array.
3) Furthermore, on including sys/user.h, one then sees this:
In file included from /usr/include/sys/user.h:40,
from main.c:153:
/usr/include/machine/pcb.h:90: warning: struct has no members
In machine/pcb.h:
/*
* The pcb is augmented with machine-dependent additional data for
* core dumps. For the i386: ???
*/
struct md_coredump {
};
Nowhere under /usr/include is a more complete definition of md_coredump to
be found. This looks awfully kludgy to me.
A little guesswork here, but this seems pretty self-explanatory to me, too.
The md_coredump{} is a structure that includes the *extra* information
(beyond what's already in the portable structure) for coredumps on a given
architecture. In the case of the 386, there is no useful extra information,
so the structure is empty, but since there's a structure someplace that has
an instance of struct md_coredump, it must be declared. Since there's no
useful content, it is declared as being empty.
Seems pretty elegant to me.
If I'm off-base here, somebody please jump in!
I do hope someone can shed some light here. Thanks.
[Your point #1 seems valid to me, though.]
--
Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work)
Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal)
ME -- http://www.babbleon.org
http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: A few questions about a few includes
On Sunday 03 March 2002 01:00 pm, Erik Trulsson wrote:
On Sun, Mar 03, 2002 at 10:27:17AM -0700, Ian wrote:
In sys/proc.h:
/*
* pargs, used to hold a copy of the command line, if it had a sane
* length
*/
struct pargs {
u_int ar_ref; /* Reference count */
u_int ar_length; /* Length */
u_char ar_args[0]; /* Arguments */
};
It might be worth mentioning that this trick is not actually allowed
according to the C standard and in principle invokes undefined
behaviour. OTOH, AFAIK the trick does work on all existing compilers,
so while it is not standard-conforming it is quite portable.
I can't even imagine how one *would* write a compiler where this would
fail--does anybody know the putative risk that led ANSI to ban this (IMHO)
perfectly-reasonable bahvior?
--
Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work)
Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal)
ME -- http://www.babbleon.org
http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: A few questions about a few includes
Brian T.Schellenberger wrote:
I can't even imagine how one *would* write a compiler where this would
fail--does anybody know the putative risk that led ANSI to ban this (IMHO)
perfectly-reasonable bahvior?
Order of structure elements is undefined. Zero length arrays
are undefined. Also, packing is undefined.
You can basically get arouns all of this by declaring the
array to be 1 byte, e.g.:
struct pargs {
u_int ar_ref; /* Reference count */
u_int ar_length; /* Length */
u_char ar_args[1]; /* Arguments */
};
And then sizing the allocation unit relatively, e.g., dont
use:
sizeof(struct pargs) + byte_count
use instead:
(int)((struct pargs *)0)-ar_args + byte_count;
To get the size of the elements up to but not including
the one byte declared, regardless of alignment or packing.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: A few questions about a few includes
Terry Lambert wrote: | Order of structure elements is undefined. Zero length arrays | are undefined. Also, packing is undefined. Close, but no cigar. The /order/ is defined in C89 (Section 6.5.2.1) with the following words: Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. Greg To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: A few questions about a few includes
Thanks for all the very interesting followups, folks. I learned something today! I really must start reading this list more often. :-) -- Conrad Sabatier [EMAIL PROTECTED] Bennett's Laws of Horticulture: (1) Houses are for people to live in. (2) Gardens are for plants to live in. (3) There is no such thing as a houseplant. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
