---- On Wed, 25 Jul 2018 09:11:23 +0100 Guy Harris <ghar...@sonic.net> wrote 
---- 
 > On Jul 25, 2018, at 12:57 AM, Denis Ovsienko <de...@ovsienko.info> wrote: 
 >  
 > > Roughly a half of the libpcap man pages text uses the values -1 and -2 to 
 > > discuss the return value of particular libpcap functions, the other half 
 > > uses PCAP_ERROR and PCAP_ERROR_BREAK. 
 > >  
 > > Is there a good reason to keep it this way instead of using 
 > > PCAP_ERROR/PCAP_ERROR_BREAK consistently in all man pages? 
 >  
 > About the only reason for *code* not to use PCAP_ERROR and PCAP_ERROR_BREAK 
 > would be if it has to compile with versions of libpcap prior to 1.0. 
 >  
 > The only reason not to use PCAP_ERROR and PCAP_ERROR_BREAK in man pages for 
 > APIs existing in pre-1.0 releases would be to discourage people from writing 
 > code that wouldn't compile with pre-1.0 releases. 
 >  
 > However, they could *also* just do 
 >  
 >     #ifndef PCAP_ERROR 
 >     #define PCAP_ERROR    -1 
 >     #endif 
 >     #ifndef PCAP_ERROR_BREAK 
 >     #define PCAP_ERROR_BREAK    -2 
 >     #endif 
 >  
 > in the files that use them with those APIs, or in a header file included by 
 > those files, so I'm not sure that's a strong enough reason not to just use 
 > them uniformly. 
 >  
 > And if they're making calls to APIs *not* present in pre-1.0 releases, their 
 > code won't compile with a pre-1.0 release anyway, so....

Thank you for explaining, Guy. Now I see it as follows.

If someone is writing a program for an old libpcap version, they should use the 
man pages that come with that old version, which say -1 and -2, so that's what 
they should put in the source code, so they do not even need the #define 
workaround.

If someone is compiling such an old program with new libpcap, the constants 
remain the same, so the only issue will be the code style.

If someone is writing a program for a new libpcap version, the #define comes 
with the library.

So it looks like there is no good reason to keep using -1 and -2 in the current 
man pages.

-- 
    Denis Ovsienko


_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Reply via email to