[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [bluetooth-dev] SDP problem...
> -----Original Message-----
> From: david LIBAULT [mailto:firstname.lastname@example.org]
> Sent: 22 June 2001 11:21
> To: email@example.com
> Subject: Re: [bluetooth-dev] SDP problem...
> Ok, I found the problem.
> Someone has modified the structure data_struct in sdp.c and
> sdp_server.c changing the s32 member variables to u16 and
> not giving the packed attribute to this structure.
Are you sure that is the problem?
As the structs are written on the same computer as they are
read and created by the same compiler, they ought to be the
same even without the packed attribute. It isn't that you
have used the old version of the data_struct in the kernel
and the new in sdp_server (or vice versa)?
> I would like to tell to this one person, that I am sick of
> having the same bugs again, and again. I am sick not to be
> heard when I say not to cast a struct to an (u8*). This person,
> instead of modify this dirty code, should have rewritten
> properly the code which in the case of SDP is not such a big
> deal. I will not do it as I have lost enough of my time.
I can but agree with you. Unfortunately, when you are pressed
for time, the simple solution sometimes wins (and as we work
on a processor that has no problem with addressing ints on a
byte boundary, we are not bitten by this kind of problems).
> In fact it makes sense not to include this stack in the
> standard kernel tree as porting issues are prohibitive...
> This kind of recurent problem could make people work on the
> bluez stack instead of the openbt (although the rfcomm of
> bluez also uses these silly structures (probably copied
> from openbt)).
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to firstname.lastname@example.org