Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: 64bit time_t patch (S.P.Zeidler)
2. Re: 64bit time_t patch (Russ Allbery)
3. Re: Issue with DBM and CURRENT on RHEL/CentOS 6.5? (Jesse Rehmer)
----------------------------------------------------------------------
Message: 1
Date: Wed, 11 Dec 2013 21:41:52 +0100
From: "S.P.Zeidler" <[email protected]>
To: [email protected]
Subject: Re: 64bit time_t patch
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi,
[email protected] (Russ Allbery) writes:
>"S.P.Zeidler" <[email protected]> writes:
>> (64bit time_t on a 32bit machine)
>I suspect that will just be the first of a series of bugs that we'll find
>after the decision to make time_t longer than a long. :/ Lots of C code
>was written under the assumption that wasn't possible. For example, I bet
>there are lots of places where we printf a time_t by casting it to a long
>or an unsigned long.
The general idea in INN seems to be to cast time_t to long, and
in most places that does happen. Further exceptions I found:
Index: backends/ninpaths.c
===================================================================
--- backends/ninpaths.c (revision 9582)
+++ backends/ninpaths.c (working copy)
@@ -147,7 +147,7 @@
}
fprintf(f, "!!NINP " VERSION " %lu %lu %ld %ld %ld\n",
(unsigned long) starttime, (unsigned long) time(NULL), sites,
- total, (long)(atimes/total)+starttime);
+ total, (long)((atimes/total)+starttime));
n=j=0;
/* write the S-records (hosts), numbering them in the process */
for (i=0; i<HASH_TBL; ++i)
Index: innfeed/endpoint.c
===================================================================
--- innfeed/endpoint.c (revision 9582)
+++ innfeed/endpoint.c (working copy)
@@ -502,8 +502,8 @@
id = timerElemAdd (timeToWake,func,clientData) ;
#if 0
- d_printf (1,"Preparing wake %d at date %ld for %d seconds\n",
- (int) id, (long) now, timeToWake - now) ;
+ d_printf (1,"Preparing wake %d at date %ld for %ld seconds\n",
+ (int) id, (long) now, (long) (timeToWake - now)) ;
#endif
return id ;
@@ -519,8 +519,8 @@
id = timerElemAdd (now + timeToSleep,func,clientData) ;
#if 0
- d_printf (1,"Preparing sleep %d at date %ld for %d seconds\n",
- (int) id, (long) now, timeToSleep) ;
+ d_printf (1,"Preparing sleep %d at date %ld for %ld seconds\n",
+ (int) id, (long) now, (long) timeToSleep) ;
#endif
return id ;
where for the latter file it's a pre-emptive strike, not active code.
I haven't had time to inspect this thoroughly, but have the impression
that changing from "cast time_t to long" to a 2039 compatible version,
doing printf(" .. %jd ..", (intmax_t) timeval); would be too disruptive
for a minor version. Maybe for the next major?
regards,
spz
--
[email protected] (S.P.Zeidler)
------------------------------
Message: 2
Date: Wed, 11 Dec 2013 13:12:32 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: 64bit time_t patch
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
"S.P.Zeidler" <[email protected]> writes:
> I haven't had time to inspect this thoroughly, but have the impression
> that changing from "cast time_t to long" to a 2039 compatible version,
> doing printf(" .. %jd ..", (intmax_t) timeval); would be too disruptive
> for a minor version. Maybe for the next major?
This will definitely break compatibility with a variety of older systems,
as those printf flags are relatively new. I'm not sure if we care any
more, though.
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 3
Date: Wed, 11 Dec 2013 15:36:36 -0600
From: Jesse Rehmer <[email protected]>
To: Julien ?LIE <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Issue with DBM and CURRENT on RHEL/CentOS 6.5?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Julien,
Adding the include line gets me past the error with ckpasswd.c, but now
I have another:
gcc -g -O2 -I../include -c auth_krb5.c
auth_krb5.c:27:22: error: com_err.h: No such file or directory
make[1]: *** [auth_krb5.o] Error 1
make[1]: Leaving directory
`/usr/local/news/src/inn-CURRENT-20131208/authprogs'
make: *** [all-authprogs] Error 2
[root@nnrp authprogs]# find / -name com_err.h
/usr/include/et/com_err.h
I would think that "# include <et/com_err.h>" would include this, but it
seems not.
Cheers,
Jesse
Julien ?LIE wrote:
> Hi Jesse,
>
>> [root@nnrp inn-CURRENT-20131208]# grep DBM_LIBS Makefile.global
>> DBM_LIBS = -lgdbm
>>
>> This may help a bit:
>>
>> [root@nnrp inn-CURRENT-20131208]# rpm -ql gdbm-devel
>> /usr/include/gdbm
>> /usr/include/gdbm.h
>> /usr/include/gdbm/dbm.h
>> /usr/include/gdbm/gdbm.h
>> /usr/include/gdbm/ndbm.h
>> /usr/lib64/libgdbm.so
>> /usr/share/info/gdbm.info.gz
>> /usr/share/man/man3/gdbm.3.gz
>
> OK, thanks.
> Does the build work if you manually add in ckpasswd.c the line:
>
> #include <gdbm/ndbm.h>
>
> after for instance:
>
> #include <grp.h>
>
>
> I suggest this quick test because you do not have a recent enough
> autoconf
> version to regenerate a configure file.
>
>
> Incidentally, if you are currently blocked in your tests and wish to
> build
> INN, do not hesitate to comment the HAVE_DBM line in include/config.h;
> ckpasswd will then build fine because it will no longer try to include
> ndbm support.
>
------------------------------
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
End of inn-workers Digest, Vol 58, Issue 4
******************************************
