> My only worry is that the (char *)to parameter passed in has to be
> long enough to hold the (char*)from parameter. I assume it is.
>
> Craig
>
Clearly this was also the concern of the original author, who, to avoid
any assumption, decided to use strncpy to avoid buffer overflows. Simply
he/
Dear Craig,
if you read more carefully my post you will see I have *perfectly* clear
the difference between the size of a structure and the length of the
string. Using strncpy instead of strcpy is the first rule to avoid a
buffer overflow - strcpy is deprecated by all good programming
practic
I guessed "_openbabel.so" has tanimoto formula and calculates it, but I
cannot see inside of "_openbabel.so".
Can I get the code of tanimoto calculate function?
>From that... I want to calculate substructure coefficient.
I'll be thank full for your help and kindness ;)
Park.
---
Hi Paolo,
I think you (and the original author) have mixed up the size of the
structures with the length of the string. There's no need to do a sizeof()
or to define a constant OB_ATOM_TYPE_LENGTH.
Here's what I think is needed ... it's actually simpler than the original.
Just use strcpy() inste
Actually that sizeof in Translate (data.cpp) is plain wrong, since it
refers to sizeof(char *) which is 8 on a 64-bit OS and 4 on a 32-bit OS;
build the attached test.c with -m64 and -m32 and run to verify that:
$ gcc -m64 test.c -o test64
$ ./test64
This is really 6: 6
This is machine-dependen
Dear Craig,
sorry, of course you are right. I was at home when I replied to your
e-mail and I thought to remember that I had put printf() before and
after Clear(), but I did not remember correctly; actually I had put them
before and after AddAtom().
The real issue was the length of _type in
HI Paolo,
On Thu, May 17, 2012 at 11:16 AM, Paolo Tosco wrote:
> I may be wrong here, but my impression is that both OBMol and OBAtom =
> operators work fine, the problem is that formal charges are zeroed after
> the call to Clear() in the OBMol = operator, as can ve verified printing
> the res
I may be wrong here, but my impression is that both OBMol and OBAtom =
operators work fine, the problem is that formal charges are zeroed after
the call to Clear() in the OBMol = operator, as can ve verified printing
the results of GetFormalCharge() before and after Clear(). Therefore
what OBAt
I have narrowed down the "lost charge" problem to atomtyper.cpp.
OBMol::operator= calls OBAtom::operator=, which calls the atom typer to
figure out the type of the *source* atom. During that process, the atom
typer erases the charge on the source atoms.
I'm still digging, but I'm way beyond my ar
Hi Paolo,
On Thu, May 17, 2012 at 9:43 AM, Paolo Tosco wrote:
> RIght, that's why my modification to the copy constructor fixes the issue
> :-)
>
You are correct ... my apologies for not examining your patch more closely
when you sent it. I updated to the latest from SVN and applied your patc
On Thu, May 17, 2012 at 9:04 AM, Chris Morley wrote:
> Craig's failing example works fine for me under Windows with both 2.3.1
> and the development code. As he suggested, this inconsistency suggests
> that there is something not being initialized properly. The logic around
> the flag OB_TCHARGE_
Dear Chris,
you are right that my patch seemingly duplicates the copying of atom
formal charges which is already done in the OBAtom::Duplicate();
however, OBAtom::Duplicate() comes after Clear() has been called, so
formal charges have been reset. I have verified that, and this is why my
patch
Craig's failing example works fine for me under Windows with both 2.3.1
and the development code. As he suggested, this inconsistency suggests
that there is something not being initialized properly. The logic around
the flag OB_TCHARGE_MOL is a bit tricky and so is a candidate, but I
cannot see
Here is another observation on this problem of lost charges during SDF to
SMILES. The first metal ion always retains the correct charge. All the
other metal ions lose their charge. Does this ring any bells? Thanks ...
this problem is holding up a major project.
Here's the example. Notice that
Hi Paolo,
Thanks very much for the patch. Unfortunately, the OBForceField functions
that you patched are never called at all during the SDF-to-SMILES
conversion process, so the patch doesn't resolve my issue. OBForceField
only seems to be called if I use the --gen3D option.
Best regards,
Craig
Dear Craig,
I have faced the identical problem with MMFF94, and I have previously
submitted a similar patch which has already been applied to SVN
OpenBabel. However, now I realize that my fix had only solved my own
problem, but not a more general problem connected with formal charges.
So I hav
16 matches
Mail list logo
