Mailing List Archive

Hello gentlemen,
I am new here but I've been lurking for some time.

On Sun, 2004-02-08 at 18:47, James Couzens wrote:

> libspf v0.23 beta is available for download from http://libspf.org

I am planning to implement SPF for Zmailer MTA (http://www.zmailer.org/)
using libspf, but there are some issues with the code:

1. There are no u_intXX_t typedefs on many systems It sould be easy to
check their existence from ./configure and supply if needed

2. There are no such things as __BEGIN_DECL and __END_DECL on many
systems. In fact, are they really necessary?

3. There are no long options in any getopt other than GNU. It's better
to either avoid long options, or supply GNU getopt.[ch] with the
distribution.

4. Shared objects are created very differently on different systems.
It's best to use libtool for compatibility.

5. Resolver library is a very sensitive thing. Some people install
replacement libraries from BIND or other source. It's better to make
location of libresolv configurable.

And the last thing, more about style than functionality: it is generally
not considered a right way to #include system header files from the
package header file. This is because on different systems, different
set of header files may be required, and on some older systems, same
header may not be #included more than once.

I think that I could provide diffs to address these things, if you
like...

Thanks for your work

Eugene

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

On Mon, Feb 09, 2004 at 06:29:50PM +0300, Eugene Crosser wrote:
|
| I think that I could provide diffs to address these things, if you
| like...
|

patches are always welcome ...

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

In <1076340590.1635.129.camel@ariel.sovam.com> Eugene Crosser <crosser@rol.ru> writes:

> 3. There are no long options in any getopt other than GNU. It's better
> to either avoid long options, or supply GNU getopt.[ch] with the
> distribution.

This one is my doing. I tried to make the C spfquery program
compatible with the Perl version and the perl version uses long
options.

The idea is that the various implementations of SPF can create
spfquery commands that all function the same way. Then, they can all
use the identical regression testing to make sure the implementations
are consistent.


If I understand things correctly, at least FreeBSD has a
gnu-compatible getopt package. Do you know if OpenBSD/NetBSD also
have this package?

Is it mostly the commercial Unixes that (still) don't have long
options? What about the MS-Windows stuff?


I will have to investigate this issue some.


Maybe the solution is to provide the FreeBSD gnu-compatible getopt
package and/or the GNU package.


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

On Mon, Feb 09, 2004 at 07:41:22PM -0600, wayne wrote:
|
| This one is my doing. I tried to make the C spfquery program
| compatible with the Perl version and the perl version uses long
| options.
|
| The idea is that the various implementations of SPF can create
| spfquery commands that all function the same way. Then, they can all
| use the identical regression testing to make sure the implementations
| are consistent.

Or the perl version can support short options also.


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h

On Mon, 2004-02-09 at 07:29, Eugene Crosser wrote:
> Hello gentlemen,
> I am new here but I've been lurking for some time.

> 1. There are no u_intXX_t typedefs on many systems It sould be easy to
> check their existence from ./configure and supply if needed

I will manually include the typedefs into main and library header file.

> 2. There are no such things as __BEGIN_DECL and __END_DECL on many
> systems. In fact, are they really necessary?

Necessary no, but i'm a linux/bsd programmer and its quite common on
both of these platforms although I believe its more of a Linux thing.
Can we do with out it, likely.. If I need to makes changes to make it
compatible with other platforms please let me know whats needed or
supply me with the necessary code and i'll see it gets taken care of.

> 3. There are no long options in any getopt other than GNU. It's better
> to either avoid long options, or supply GNU getopt.[ch] with the
> distribution.

I'll let Wayne speak up here as he is the author of spfquery.

> 4. Shared objects are created very differently on different systems.
> It's best to use libtool for compatibility.

That can be arranged.

> 5. Resolver library is a very sensitive thing. Some people install
> replacement libraries from BIND or other source. It's better to make
> location of libresolv configurable.

I will be removing the rest of the gethostbyname calls and restrict all
DNS related things to the custom functions written within. This is
because of the problems associated with gethostbyname/gethostbyaddr
etc.. etc.. As for linking other resolver libraries, as long as they
maintain the same API I see no problem in doing that.

I had planned to either integrate or provide the ability to link the djb
dns library at some point. What other common libraries or
implementations are you aware of?

> And the last thing, more about style than functionality: it is generally
> not considered a right way to #include system header files from the
> package header file. This is because on different systems, different
> set of header files may be required, and on some older systems, same
> header may not be #included more than once.

I know, but thats how I like to do it. Its a lot cleaner and easier to
deal with, at least from a development perspective where things keep
changing. Perhaps once everything is locked down tight, if its still an
issue I may consider changing the way its down, however its more of a
personal preference thing than I can tell after doing some research on
the matter a year or so ago.

> I think that I could provide diffs to address these things, if you
> like...

What helps me most right now, would be looking for bugs, overflows, and
anything that is going to cause a problem. In addition to this,
providing diff's to implement support for an alternate DNS library of
your choosing is helpful but likely won't see its way into the code as
fast as the aforementioned items.

The primary goal with libspf is indeed portability, so raising any issue
regarding a possibly portability problem to win32, sparc, or other major
architecture is of particular interest.

Thanks for taking the time to submit your thoughts on the project and I
look forward to any contributions you may provide.

Cheers,

James

--
James Couzens,
Programmer

Current projects:
http://libspf.org

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ï#ÄÏÉæGã!'Rzš´ˆ»£‡Æ~3com