Mailing List Archive: Cleanup patch

Cleanup patch

Aug 9, 2006, 6:18 AM

Post #1 of 5 (1960 views)

Hello,

I attached a larger cleanup patch for libgcrypt SVN:

It contains:
- usage of HAVE_CONFIG_H define
- Naming of unnamed data field in gcrypt.h to io.
--> This is a leftover from older days and not supported by all modern
compilers.
--> For some compilers this will break source code compatibility in case
this field is used (Seems to be very very seldom). Most compilers
should only issue a warning.
Adding some defines will fix the error, but I would not recommend
doing so.
- Fixed some build and path problems
- Added some free() functions, where they were missing.

All these are only cleanups to fix leaks or compiling stage (mainly for
Windows outside of Cygwin). The patches are fully public domain with no
legal restrictions of any form.

Ciao
--
http://www.dstoecker.de/ (PGP key available)

Re: Cleanup patch [ In reply to ]

gcrypt at dstoecker

Aug 30, 2006, 2:26 AM

Post #2 of 5 (1878 views)

Permalink

On Wed, 9 Aug 2006, Dirk Stoecker wrote:

> I attached a larger cleanup patch for libgcrypt SVN:

Well, I ask myself why I did that work when I'm totally ignored again.

May the bugs be with you.

Ciao
--
http://www.dstoecker.de/ (PGP key available)

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Re: Cleanup patch [ In reply to ]

wk at gnupg

Aug 30, 2006, 8:36 AM

Post #3 of 5 (1883 views)

Permalink

On Wed, 30 Aug 2006 11:26, Dirk Stoecker said:

> Well, I ask myself why I did that work when I'm totally ignored again.

I have not come around to reply. My reply would anyay be the usual:
We need legal papers for such patches. It might or might not be a
trivial patch but all together it would lead to extra work to check
whether this and possible future patches are trivial. Thus I can't
accept them.

I will also need to check the patch which is time consuming.

Salam-Shalom,

Werner

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Re: Cleanup patch [ In reply to ]

gcrypt at dstoecker

Aug 31, 2006, 11:37 PM

Post #4 of 5 (1876 views)

Permalink

On Wed, 30 Aug 2006, Werner Koch wrote:

> > Well, I ask myself why I did that work when I'm totally ignored again.
>
> I have not come around to reply. My reply would anyay be the usual:

After a month? In this really high-traffic mailinglist?

> We need legal papers for such patches. It might or might not be a

Quoting from the mail I send the patch with:
: The patches are fully public domain with no legal restrictions of any
: form.

> trivial patch but all together it would lead to extra work to check
> whether this and possible future patches are trivial. Thus I can't
> accept them.

You wont get any future patches from me.

> I will also need to check the patch which is time consuming.

Well, finding the bugs and quirks yourself is not? So my
internal patch file will grow with every update of libgcrypt (e.g.
implementing SEED added new build errors) and libgcrypt will keep its
bugs.

Ciao
--
http://www.dstoecker.de/ (PGP key available)

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Re: Cleanup patch [ In reply to ]

wk at gnupg

Sep 3, 2006, 11:12 AM

Post #5 of 5 (1870 views)

Permalink

On Fri, 1 Sep 2006 08:37, Dirk Stoecker said:

> Quoting from the mail I send the patch with:
> : The patches are fully public domain with no legal restrictions of any
> : form.

I have said this more timse than I am willing to count. We need legal
papers, really. See: http://www.gnu.org/copyleft/why-assign.html .

> Well, finding the bugs and quirks yourself is not? So my
> internal patch file will grow with every update of libgcrypt (e.g.

I you don't want to sign a CA it is best to report the problems
instead of lettung us come up with our own fix. And well, stuff like

+#ifdef HAVE_CONFIG_H
#include <config.h>
+#endif

is not very helpful. config.h is not an optional file in Libgcrypt.
Further it makes it very hard to figure things we should really fix,
like the trailing comman in an enum which is only allowed by c99.

Salam-Shalom,

Werner

p.s. Some times I even look into mails on Sundays ;-)

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Mailing List Archive

Mailing List Archive

Attached Files: