[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bluetooth-dev] SDP problem...
Le Lundi 25 Juin 2001 13:53, Peter Kjellerstedt a écrit :
> > -----Original Message-----
> > From: david LIBAULT [mailto:email@example.com]
> > Sent: 22 June 2001 11:21
> > To: firstname.lastname@example.org
> > 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 ?
Yes I am sure it is the problem as it works fine now.
> 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)?
Ok, I will try to explain the problem but I want to warn you as I am not a
specialist in this kind of issues.
If you define a structure on one computer and use it on one computer, it is
fine. No matter how data is stored in memory, struct.member or
p_struct->member will allways refer to the same physical address. Using a
struct is a very good idea to "structure" your data, pass a lot of arguments
to a function with only one pointer etc...
If you declare the structure struct, and then do a
u_char *p_char = (u_char *) &struct
Then you make an assumption on how physically the data is stored in memory,
i.e. the first element of the structure is stored first, and then the second
etc... on non aligned 32bits addresses (which is the case for x86
processors). But, depending on the compiler+processor that you use, data in
structres is stored in a different way in memory. Then, accessing
"struct.member" or "p_char[offset_value]" will give access to a different
physical address in memory. Of course if you do only "p_char[offset_value]"
you might be allright (although there is probably a risk of memory leak...)
but, then why use a struct ?
I'm not sure my explanation is clear, but it is worth trying. Probably a lot
of people on this list could explain this issue better than me... Gordon ?
> > 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).
Yes, we all live in the same world. When you are pressed for time and spend
precious time on silly issues, you can get mad sometimes :-)
> > 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)).
> > David.
> To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
> the body of a message to email@example.com
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to firstname.lastname@example.org