Xin LI | 1 Jun 10:10 2005
Picon

[PATCH RFC] Add a macro for null mount options to sbin/mount*

Hi, -arch <at> ,

In our mount* utilities, the null mount option, which is usually be used
as a terminator of an option vector, is defined with some hand-rolled
terms, e.g.: {NULL}, {NULL, 0, 0, 0}, etc.

I think it would be nice to have a new macro to deal with this, say,
MOPT_NULL, which would be extended to {NULL, 0, 0, 0}, which can act as
an explicit initialize.  And in my opinion, something like:

%%%
opt = {
	MOPT_STD,
	MOPT_NULL
};
%%%

Looks better than:

%%%
opt = {
	MOPT_STD,
	{ NULL }
};
%%%

That has lead to the attached patchset.  May I go ahead and commit it?

Thanks in advance!

(Continue reading)

Maxime Henrion | 1 Jun 11:17 2005
Picon

Re: [PATCH RFC] Add a macro for null mount options to sbin/mount*

Xin LI wrote:
> Hi, -arch <at> ,
> 
> In our mount* utilities, the null mount option, which is usually be used
> as a terminator of an option vector, is defined with some hand-rolled
> terms, e.g.: {NULL}, {NULL, 0, 0, 0}, etc.
> 
> I think it would be nice to have a new macro to deal with this, say,
> MOPT_NULL, which would be extended to {NULL, 0, 0, 0}, which can act as
> an explicit initialize.  And in my opinion, something like:
> 
> %%%
> opt = {
> 	MOPT_STD,
> 	MOPT_NULL
> };
> %%%
> 
> Looks better than:
> 
> %%%
> opt = {
> 	MOPT_STD,
> 	{ NULL }
> };
> %%%
> 
> That has lead to the attached patchset.  May I go ahead and commit it?

This is definitely nice.  Please commit!
(Continue reading)

Jean-Sébastien Pédron | 1 Jun 11:43 2005
Picon

Re: [PATCH RFC] Add a macro for null mount options to sbin/mount*

Xin LI wrote:
> Hi, -arch <at> ,
>
> In our mount* utilities, the null mount option, which is usually be used
> as a terminator of an option vector, is defined with some hand-rolled
> terms, e.g.: {NULL}, {NULL, 0, 0, 0}, etc.
>
> I think it would be nice to have a new macro to deal with this, say,
> MOPT_NULL, which would be extended to {NULL, 0, 0, 0}, which can act as
> an explicit initialize.  And in my opinion, something like:

This idea is really great, but may I suggest a name like MOPT_END or
MOPT_LIST_END? Because the macro should indicate the end of this vector,
  not by what it'll be replaced.

Regards,

--
Jean-Sébastien Pédron
http://www.dumbbell.fr/

PGP Key: http://www.dumbbell.fr/pgp/pubkey.asc
Bruce Evans | 1 Jun 13:23 2005
Picon

Re: [PATCH RFC] Add a macro for null mount options to sbin/mount*

On Wed, 1 Jun 2005, Xin LI wrote:

> In our mount* utilities, the null mount option, which is usually be used
> as a terminator of an option vector, is defined with some hand-rolled
> terms, e.g.: {NULL}, {NULL, 0, 0, 0}, etc.

"{ NULL }" is the documented way.  See getmntopts.3.

> I think it would be nice to have a new macro to deal with this, say,
> MOPT_NULL, which would be extended to {NULL, 0, 0, 0}, which can act as
> an explicit initialize.  And in my opinion, something like:
>
> %%%
> opt = {
> 	MOPT_STD,
> 	MOPT_NULL
> };
> %%%

MOPT_NULL is a poor name.  It is not a null option, but a terminator that
happens to have nulls in it.

Bruce
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"

Hajimu UMEMOTO | 1 Jun 14:44 2005

Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net

Hi,

>>>>> On Wed, 01 Jun 2005 03:00:10 +0900
>>>>> Hajimu UMEMOTO <ume <at> freebsd.org> said:

ume> In anyway, there is one more issue in my patch.  We cannot correct 1st
ume> argument of getnetbyaddr(3) without breaking ABI compatibility.
ume> Fortunately, getnetbyaddr(3) is not refered else where in our
ume> libraries.  So, I'll fix getnetbyaddr(3).

I've attached the patch to correct 1st argument of getnetbyaddr(3) in
this mail.  It is subset of my previous patch.  Since it breaks ABI
compatibility of getnetbyaddr(3), I think it is better to correct
n_net member of struct netent, too.  Since there is objection, the
patch leaves struct addrinfo as is.  So, it doesn't need to bump any
shlib major.  Is it okay?

Sincerely,
--
Hajimu UMEMOTO  <at>  Internet Mutual Aid Society Yokohama, Japan
ume <at> mahoroba.org  ume <at> {,jp.}FreeBSD.org
http://www.imasy.org/~ume/
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
(Continue reading)

Xin LI | 1 Jun 15:43 2005
Picon

Re: [PATCH RFC] Add a macro for null mount options to sbin/mount*

On Wed, Jun 01, 2005 at 09:23:23PM +1000, Bruce Evans wrote:
> On Wed, 1 Jun 2005, Xin LI wrote:
> 
> >In our mount* utilities, the null mount option, which is usually be used
> >as a terminator of an option vector, is defined with some hand-rolled
> >terms, e.g.: {NULL}, {NULL, 0, 0, 0}, etc.
> 
> "{ NULL }" is the documented way.  See getmntopts.3.
>
> >I think it would be nice to have a new macro to deal with this, say,
> >MOPT_NULL, which would be extended to {NULL, 0, 0, 0}, which can act as
> >an explicit initialize.  And in my opinion, something like:
> >
> >%%%
> >opt = {
> >	MOPT_STD,
> >	MOPT_NULL
> >};
> >%%%
> 
> MOPT_NULL is a poor name.  It is not a null option, but a terminator that
> happens to have nulls in it.

Agreed...  Will the patch found in attachment look better?  It also
updates the manpage.

Cheers,
--

-- 
Xin LI <delphij frontfree net>	http://www.delphij.net/
See complete headers for GPG key and other information.
(Continue reading)

David O'Brien | 1 Jun 17:03 2005
Picon

Re: [PATCH RFC] Add a macro for null mount options to sbin/mount*

On Wed, Jun 01, 2005 at 04:10:56PM +0800, Xin LI wrote:
> Hi, -arch <at> ,
> 
> In our mount* utilities, the null mount option, which is usually be used
> as a terminator of an option vector, is defined with some hand-rolled
> terms, e.g.: {NULL}, {NULL, 0, 0, 0}, etc.
> 
> I think it would be nice to have a new macro to deal with this, say,
> MOPT_NULL, which would be extended to {NULL, 0, 0, 0}, which can act as
> an explicit initialize.  And in my opinion, something like:

I think it is better to leave it alone.  The "NULL" termination of a list
like this is a C idiom that should be clear to any C programmer.  Hiding
the details in a macro (is MOPT_NULL an integer or a sentinel?) makes it
harder to see the idiom and know exactly what is going on and how this
list will be processed.

--

-- 
-- David  (obrien <at> FreeBSD.org)
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"

Luigi Rizzo | 1 Jun 17:06 2005

Re: [PATCH RFC] Add a macro for null mount options to sbin/mount*

On Wed, Jun 01, 2005 at 08:03:44AM -0700, David O'Brien wrote:
> On Wed, Jun 01, 2005 at 04:10:56PM +0800, Xin LI wrote:
> > Hi, -arch <at> ,
> > 
> > In our mount* utilities, the null mount option, which is usually be used
> > as a terminator of an option vector, is defined with some hand-rolled
> > terms, e.g.: {NULL}, {NULL, 0, 0, 0}, etc.
> > 
> > I think it would be nice to have a new macro to deal with this, say,
> > MOPT_NULL, which would be extended to {NULL, 0, 0, 0}, which can act as
> > an explicit initialize.  And in my opinion, something like:
> 
> I think it is better to leave it alone.  The "NULL" termination of a list
> like this is a C idiom that should be clear to any C programmer.  Hiding
> the details in a macro (is MOPT_NULL an integer or a sentinel?) makes it
> harder to see the idiom and know exactly what is going on and how this
> list will be processed.

on one side I have to agree here... however the alternative terms
might cause problems with stricter compile flags (e.g. when some
of the forms do not supply all fields), so perhaps a decent compromise
could be to find a more explicative name such as MOPT_END or the like.

	cheers
	luigi
> -- 
> -- David  (obrien <at> FreeBSD.org)
> _______________________________________________
> freebsd-arch <at> freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
(Continue reading)

Harti Brandt | 1 Jun 17:11 2005
Picon

Re: [PATCH RFC] Add a macro for null mount options to sbin/mount*

On Wed, 1 Jun 2005, David O'Brien wrote:

DO>On Wed, Jun 01, 2005 at 04:10:56PM +0800, Xin LI wrote:
DO>> Hi, -arch <at> ,
DO>> 
DO>> In our mount* utilities, the null mount option, which is usually be used
DO>> as a terminator of an option vector, is defined with some hand-rolled
DO>> terms, e.g.: {NULL}, {NULL, 0, 0, 0}, etc.
DO>> 
DO>> I think it would be nice to have a new macro to deal with this, say,
DO>> MOPT_NULL, which would be extended to {NULL, 0, 0, 0}, which can act as
DO>> an explicit initialize.  And in my opinion, something like:
DO>
DO>I think it is better to leave it alone.  The "NULL" termination of a list
DO>like this is a C idiom that should be clear to any C programmer.  Hiding
DO>the details in a macro (is MOPT_NULL an integer or a sentinel?) makes it
DO>harder to see the idiom and know exactly what is going on and how this
DO>list will be processed.

The problem is that with the right set of warning options gcc will warn if
you write {NULL}, but there are more fields than just a pointer. If the 
structure definition is stable enough this is no problem - just go through 
all the programs and fix it once. If the definition is likely to change 
from time to time, a macro is better because it just does the right thing.

harti
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
(Continue reading)

Tom Rhodes | 1 Jun 17:31 2005
Picon

Re: [PATCH RFC] Add a macro for null mount options to sbin/mount*

On Wed, 1 Jun 2005 21:23:23 +1000 (EST)
Bruce Evans <bde <at> zeta.org.au> wrote:

> On Wed, 1 Jun 2005, Xin LI wrote:

Here we go again!  :P

> 
> > In our mount* utilities, the null mount option, which is usually be used
> > as a terminator of an option vector, is defined with some hand-rolled
> > terms, e.g.: {NULL}, {NULL, 0, 0, 0}, etc.
> 
> "{ NULL }" is the documented way.  See getmntopts.3.

That manual page has been unhooked since it's import IIRC.

> 
> > I think it would be nice to have a new macro to deal with this, say,
> > MOPT_NULL, which would be extended to {NULL, 0, 0, 0}, which can act as
> > an explicit initialize.  And in my opinion, something like:
> >
> > %%%
> > opt = {
> > 	MOPT_STD,
> > 	MOPT_NULL
> > };
> > %%%
> 
> MOPT_NULL is a poor name.  It is not a null option, but a terminator that
> happens to have nulls in it.
(Continue reading)


Gmane