Re: bluetooth.h, c++ include error

[Maksim Yevmenkin]

On Sun, Oct 4, 2009 at 10:42 AM, Masoom Shaikh <masoom...@gmail.com> wrote:
> posting here after @current and @questions ignored
>
> Hello,
>
> while going through bluetooth.h, I observed
>
> int bt_devfilter(int s, struct bt_devfilter const *new, struct bt_devfilter
> *old);
>
> this line appears in bluetooth.h @ line # 166, rv197571
>
> see ? the variable named 'new' will cause trouble to c++ source files
> i honestly believe this is not intentional, c++ programmers will have to
> perform some acrobats to get past this

patches are welcome

thanks,
max

[Masoom Shaikh]

what i am requesting is just variable name change ;-)
my tree is at revision 197571, thus the patch i am presenting is also
generated against it
reject this if you want patch against latest revision

renamed second argument of bt_devfilter() from 'new' to 'dfnew'. df for
device filter
to maintain uniformity renamed third argument from 'old' to 'dfold'.

the patch follows

Index: bluetooth.h
===================================================================
--- bluetooth.h (revision 197571)
+++ bluetooth.h (working copy)
@@ -28,7 +28,7 @@
* SUCH DAMAGE.
*
* $Id: bluetooth.h,v 1.5 2003/09/14 23:28:42 max Exp $
- * $FreeBSD$
+ * $FreeBSD: stable/8/lib/libbluetooth/bluetooth.h 191388 2009-04-22
15:50:03Z emax $
*/

#ifndef _BLUETOOTH_H_
@@ -163,8 +163,8 @@
int bt_devsend (int s, uint16_t opcode, void *param, size_t plen);
ssize_t bt_devrecv (int s, void *buf, size_t size, time_t to);
int bt_devreq (int s, struct bt_devreq *r, time_t to);
-int bt_devfilter(int s, struct bt_devfilter const *new,
- struct bt_devfilter *old);
+int bt_devfilter(int s, struct bt_devfilter const *dfnew,
+ struct bt_devfilter *dfold);
void bt_devfilter_pkt_set(struct bt_devfilter *filter, uint8_t
type);
void bt_devfilter_pkt_clr(struct bt_devfilter *filter, uint8_t
type);
int bt_devfilter_pkt_tst(struct bt_devfilter const *filter, uint8_t
type);

[Iain Hibbert]

On Mon, 5 Oct 2009, Masoom Shaikh wrote:

> what i am requesting is just variable name change ;-) my tree is at
> revision 197571, thus the patch i am presenting is also generated
> against it reject this if you want patch against latest revision
>
> renamed second argument of bt_devfilter() from 'new' to 'dfnew'. df for
> device filter to maintain uniformity renamed third argument from 'old'
> to 'dfold'.

style(9) mentions that for kernel include files exposed to userland
(technically, this is always in userland but perhaps the same rules apply)
the prototype tag arguments should be made safe, eg starting with a _
perhaps for much this reason..

so, my suggestion would be to use _new and _old etc..

iain

(or, just don't use them, they are not especially required :)

[Masoom Shaikh]

> so this shall work
i just renamed bt_devfilter() variable names, because it was the one which
caused trouble
will someone commit this ?

Index: bluetooth.h
===================================================================
--- bluetooth.h (revision 197804)
+++ bluetooth.h (working copy)

@@ -163,8 +163,8 @@
int bt_devsend (int s, uint16_t opcode, void *param, size_t plen);
ssize_t bt_devrecv (int s, void *buf, size_t size, time_t to);
int bt_devreq (int s, struct bt_devreq *r, time_t to);
-int bt_devfilter(int s, struct bt_devfilter const *new,
- struct bt_devfilter *old);

+int bt_devfilter(int s, struct bt_devfilter const *_new,
+ struct bt_devfilter *_old);

[Maksim Yevmenkin]

On Tue, Oct 6, 2009 at 8:48 AM, Masoom Shaikh <masoom...@gmail.com> wrote:
>
>
> On Mon, Oct 5, 2009 at 5:26 PM, Iain Hibbert <plu...@rya-online.net> wrote:
>>
>> On Mon, 5 Oct 2009, Masoom Shaikh wrote:
>>
>> > what i am requesting is just variable name change ;-) my tree is at
>> > revision 197571, thus the patch i am presenting is also generated
>> > against it reject this if you want patch against latest revision
>> >
>> > renamed second argument of bt_devfilter() from 'new' to 'dfnew'. df for
>> > device filter to maintain uniformity renamed third argument from 'old'
>> > to 'dfold'.
>>
>> style(9) mentions that for kernel include files exposed to userland
>> (technically, this is always in userland but perhaps the same rules apply)
>> the prototype tag arguments should be made safe, eg starting with a _
>> perhaps for much this reason..
>>
>> so, my suggestion would be to use _new and _old etc..
>>
>> iain
>>
>> (or, just don't use them, they are not especially required :)
>>
> so this shall work
> i just renamed bt_devfilter() variable names, because it was the one which
> caused trouble
> will someone commit this ?

i just committed fix for this.

thanks
max

[Masoom Shaikh]

I am using

FreeBSD raptor 8.0-RELEASE FreeBSD 8.0-RELEASE #0 r201047:201048M: Mon Dec
28 10:42:01 UTC 2009 root@raptor:/usr/obj/usr/src/sys/GENERIC amd64

still I see the same variable names,

[Oliver Fromme]

Masoom Shaikh wrote:

> On Mon, Oct 26, 2009 at 5:43 PM, Maksim Yevmenkin wrote:
> > i just committed fix for this.
>

> I am using
>
> FreeBSD raptor 8.0-RELEASE FreeBSD 8.0-RELEASE #0 r201047:201048M: Mon Dec
> 28 10:42:01 UTC 2009 root@raptor:/usr/obj/usr/src/sys/GENERIC amd64
>
> still I see the same variable names,

The fix is only in head (i.e. -current), not in 8.0-RELEASE
because it was already in code-freeze at that time.

By the way, I recommend that you update your machine, at
leas to the latest release patch level or 8-stable.
There are serious security vulnerabilities in 8.0-RELEASE,
see: http://www.freebsd.org/security/advisories.html

Best regards
Oliver

--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Gesch�ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M�n-
chen, HRB 125758, Gesch�ftsf�hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd

"Whatever happened to the days when hacking started
at the cerebral cortex, and not at the keyboard?"
-- Sid on userfriendly.org by Illiad, 2007-06-20

[Maksim Yevmenkin]

On Mon, Jan 25, 2010 at 8:48 AM, Oliver Fromme <ol...@lurza.secnetix.de> wrote:
> Masoom Shaikh wrote:
> > On Mon, Oct 26, 2009 at 5:43 PM, Maksim Yevmenkin wrote:
> > > i just committed fix for this.
> >
> > I am using
> >
> > FreeBSD raptor 8.0-RELEASE FreeBSD 8.0-RELEASE #0 r201047:201048M: Mon Dec
> > 28 10:42:01 UTC 2009 root@raptor:/usr/obj/usr/src/sys/GENERIC amd64
> >
> > still I see the same variable names,
>
> The fix is only in head (i.e. -current), not in 8.0-RELEASE
> because it was already in code-freeze at that time.

i just mfc'ed it into stable/8

thanks
max