Re: cvs commit: apr/include apr_lib.h
[ bringing back to list; OtherBill apparently misfired the reply ] On Sun, Feb 11, 2001 at 09:37:31PM -0600, William A. Rowe, Jr. wrote: > From: "Greg Stein" <[EMAIL PROTECTED]> > Sent: Sunday, February 11, 2001 8:05 PM > > > > > wrowe 01/02/11 15:31:04 > > > > > > Modified:.CHANGES > > >passwd apr_getpass.c > > >include apr_lib.h > > > Log: > > > result(?) What result? Stop mauling the size_t arg and overwrite the > > > system buffer before returning from apr_password_get, and clean up > > > doc. > > > >APR_DECLARE(apr_status_t) apr_password_get(const char *prompt, char > > > *pwbuf, > > > - size_t *bufsize); > > > + size_t *bufsize); > > > Um... couldn't that bufsize just be an apr_size_t rather than "size_t *" ?? > > If you aren't going to return a value, then drop the indirection, right? > > Absolutely apr_size_t. And that is a question, do we want to return the > actual > size needed/used? I personally don't care, but wasn't going to make that call > when I was fixing the fn (returned 0 before, rather useless.) So I'd agree in > part, either apr_size_t bufsize, or apr_size_t *bufsize returning the size > used > or needed (len as returned by getpass). I don't think we need to return the size. The caller can always use strlen() if that is needed. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/include apr_lib.h
On Sun, Feb 11, 2001 at 11:31:04PM -, [EMAIL PROTECTED] wrote: > wrowe 01/02/11 15:31:04 > > Modified:.CHANGES >passwd apr_getpass.c >include apr_lib.h > Log: > result(?) What result? Stop mauling the size_t arg and overwrite the > system buffer before returning from apr_password_get, and clean up doc. >... > --- apr_lib.h 2001/02/11 00:12:11 1.51 > +++ apr_lib.h 2001/02/11 23:31:04 1.52 > @@ -220,12 +220,12 @@ >/** > * Display a prompt and read in the password from stdin. > * @param prompt The prompt to display > - * @param pwbuf Where to store the password > - * @param bufsize The length of the password string. > + * @param pwbuf Buffer to store the password > + * @param bufsize The length of the password buffer. > * @deffunc apr_status_t apr_password_get(const char *prompt, char *pwbuf, > size_t *bufsize) > */ >APR_DECLARE(apr_status_t) apr_password_get(const char *prompt, char > *pwbuf, > - size_t *bufsize); > + size_t *bufsize); Um... couldn't that bufsize just be an apr_size_t rather than "size_t *" ?? If you aren't going to return a value, then drop the indirection, right? Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/include apr_lib.h
On Sun, Dec 03, 2000 at 09:49:11AM -0800, [EMAIL PROTECTED] wrote: > > > > What do you mean the syntax doesn't translate well? Does it compile at > > > all? Does it run? If this doesn't work on BeOS, we have real problems, > > > because we haven't accomplished our goal of a Portable Run-Time. > > > > The problem is that we don't have the logic in the Makefile for the test > > program to tell it how to build libraries on different platforms at the > > moment. ISTR we talked about this a long time ago but I can't remember what > > we decided on. Changing the settings gets it all working. > > I hate to suggest this, but libtool would solve this problem. :-( *snicker* I'll take a look at libtoolize'ing the main APR. Once that is done, then I can look at the test directory, too. [ unless somebody beats me to it. I won't get to it until late tonite. ] Cheers, -g -- Greg Stein, http://www.lyra.org/
Autobook (was: Re: cvs commit: apr/include apr_lib.h)
For all the libtool illiterates :-)) out there, you might want to consider reading autobook, a free book featuring two chapters about libtool. The first one is directly applicable to Apache and APR: http://sources.redhat.com/autobook/ TOC: http://sources.redhat.com/autobook/autobook/autobook_toc.html - Sascha
Re: cvs commit: apr/include apr_lib.h
> > What do you mean the syntax doesn't translate well? Does it compile at > > all? Does it run? If this doesn't work on BeOS, we have real problems, > > because we haven't accomplished our goal of a Portable Run-Time. > > The problem is that we don't have the logic in the Makefile for the test > program to tell it how to build libraries on different platforms at the > moment. ISTR we talked about this a long time ago but I can't remember what > we decided on. Changing the settings gets it all working. I hate to suggest this, but libtool would solve this problem. :-( Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: cvs commit: apr/include apr_lib.h
> > What do you mean the syntax doesn't translate well? Does it compile at > > all? Does it run? If this doesn't work on BeOS, we have real problems, > > because we haven't accomplished our goal of a Portable Run-Time. > > I meant the command line compiler option syntax, not the C syntax. > Naturally, the metroworks compiler doesnt handle --enable-dynamic and > -fPIC too well. I'll try to figure out how to do this properly. Ahhh. That makes much more sense. Thanks for the clarification. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: cvs commit: apr/include apr_lib.h
> > After that, the only proble was testdso, which is a dynamically loaded > > binary. Naturally the syntax didn't translate well, so I just > > commented it out entirely. However, this mean that I couldn't run > > most of the tests. So, the upshot is, here's the test results: > > What do you mean the syntax doesn't translate well? Does it compile at > all? Does it run? If this doesn't work on BeOS, we have real problems, > because we haven't accomplished our goal of a Portable Run-Time. The problem is that we don't have the logic in the Makefile for the test program to tell it how to build libraries on different platforms at the moment. ISTR we talked about this a long time ago but I can't remember what we decided on. Changing the settings gets it all working. david
Re: cvs commit: apr/include apr_lib.h
On Sun, Dec 03, 2000 at 09:42:22AM -0800, [EMAIL PROTECTED] wrote: > The type problems probably shouldn't be solved with a cast. This is > happening because we changed a bunch on arguments from apr_ssize_t to > apr_size_t in the function prototypes, but neglected to update the > tests. We need to convert the actual functions. I'll let someone a little more familiar with the code do that. > > After that, the only proble was testdso, which is a dynamically loaded > > binary. Naturally the syntax didn't translate well, so I just > > commented it out entirely. However, this mean that I couldn't run > > most of the tests. So, the upshot is, here's the test results: > > What do you mean the syntax doesn't translate well? Does it compile at > all? Does it run? If this doesn't work on BeOS, we have real problems, > because we haven't accomplished our goal of a Portable Run-Time. I meant the command line compiler option syntax, not the C syntax. Naturally, the metroworks compiler doesnt handle --enable-dynamic and -fPIC too well. I'll try to figure out how to do this properly. sam th [EMAIL PROTECTED] http://www.abisource.com/~sam/ GnuPG Key: http://www.abisource.com/~sam/key pgpLl1alZ6AGf.pgp Description: PGP signature
Re: cvs commit: apr/include apr_lib.h
> As for the tests, there were a bunch of type mismatches, virtually all > related to the signedness of character strings. Then there was the The type problems probably shouldn't be solved with a cast. This is happening because we changed a bunch on arguments from apr_ssize_t to apr_size_t in the function prototypes, but neglected to update the tests. We need to convert the actual functions. > function apr_socket_from_file, which wasn't implemented on BeOS at > all. So I copied the function exactly from the Unix implementation, > and that worked. I'm surprised that wasn't done before. Rather than duplicate the code, I would prefer to just use the Unix implementation. I'll look into that. > After that, the only proble was testdso, which is a dynamically loaded > binary. Naturally the syntax didn't translate well, so I just > commented it out entirely. However, this mean that I couldn't run > most of the tests. So, the upshot is, here's the test results: What do you mean the syntax doesn't translate well? Does it compile at all? Does it run? If this doesn't work on BeOS, we have real problems, because we haven't accomplished our goal of a Portable Run-Time. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: cvs commit: apr/include apr_lib.h
Well I knew that was coming :) There are a few problems with some of the test programs but as they've been so low on the priority list of things to do I haven't fixed them for BeOS. Looks like I'll have to get to them now doesn't it? :) david
Re: cvs commit: apr/include apr_lib.h
On Sun, Dec 03, 2000 at 08:21:35AM -0800, [EMAIL PROTECTED] wrote:
>
> > This still doesn't work. It turns out that neither BEOS nor
> > __POWER_PC__ is defined at the point in Subversion that this gets used
> > and likely not in other APR-using apps either. So, new patch, using
> > HAVE_isascii, which doesn't require including apr_private.h, despite
> > Ryan's worry. Also, defining it before using it is helpful. :-)
>
> Well, David already committed a very good patch, but I'll comment anyway
> :-)
>
> I had gone to bed before the rest of this stuff was discussed, so
> obviously I didn't get to comment last night.
>
> I just search all of the include directory, and the only place
> HAVE_isascii is defined is apr_private.h.in, so I can't see how
> we could check HAVE_isascii without that file.
My guess is, as Greg suggested, that it just wasn't defined, and
therefore was treated as false. Which gives the desired behavior on
Be/PPC, but not anywhere else. Good to see we now have this done
right.
As for the tests, there were a bunch of type mismatches, virtually all
related to the signedness of character strings. Then there was the
function apr_socket_from_file, which wasn't implemented on BeOS at
all. So I copied the function exactly from the Unix implementation,
and that worked.
After that, the only proble was testdso, which is a dynamically loaded
binary. Naturally the syntax didn't translate well, so I just
commented it out entirely. However, this mean that I couldn't run
most of the tests. So, the upshot is, here's the test results:
User data is working ok
Testing file functions.
Opening file...OK
Checking file...OK
OK
Moving to start of file...OK
This platform supports files_like_sockets
Making file look like a socket...OK
Select caused an error
Checking for incoming data/testfile failed
Here are the patches:
First, all the casts. Greg, feel free to do this correctly.
RCS file: /home/cvspublic/apr/test/client.c,v
retrieving revision 1.21
diff -u -r1.21 client.c
--- test//client.c 2000/11/21 19:15:27 1.21
+++ test//client.c 2000/12/03 17:26:23
@@ -150,7 +150,7 @@
fprintf(stdout, "\tClient: Trying to send data over socket...");
length = STRLEN;
-if (apr_send(sock, datasend, &length) != APR_SUCCESS) {
+if (apr_send(sock, datasend, (unsigned long *)&length) != APR_SUCCESS) {
apr_close_socket(sock);
fprintf(stderr, "Problem sending data\n");
exit(-1);
@@ -170,7 +170,7 @@
length = STRLEN;
fprintf(stdout, "\tClient: Trying to receive data over socket...");
-if ((stat = apr_recv(sock, datarecv, &length)) != APR_SUCCESS) {
+if ((stat = apr_recv(sock, datarecv, (unsigned long *)&length)) !=
APR_SUCCESS) {
apr_close_socket(sock);
fprintf(stderr, "Problem receiving data: %s (%d)\n",
apr_strerror(stat, msgbuf, sizeof(msgbuf)), stat);
Index: test//server.c
===
RCS file: /home/cvspublic/apr/test/server.c,v
retrieving revision 1.22
diff -u -r1.22 server.c
--- test//server.c 2000/12/03 06:50:31 1.22
+++ test//server.c 2000/12/03 17:26:28
@@ -213,7 +213,7 @@
length = STRLEN;
fprintf(stdout, "\tServer: Trying to recv data from socket...");
-if (apr_recv(sock2, datasend, &length) != APR_SUCCESS) {
+if (apr_recv(sock2, datasend, (unsigned long *)&length) != APR_SUCCESS) {
apr_close_socket(sock);
apr_close_socket(sock2);
fprintf(stderr, "Problem recving data\n");
@@ -229,7 +229,7 @@
length = STRLEN;
fprintf(stdout, "\tServer: Sending data over socket...");
-if (apr_send(sock2, datarecv, &length) != APR_SUCCESS) {
+if (apr_send(sock2, datarecv, (unsigned long *)&length) != APR_SUCCESS) {
apr_close_socket(sock);
apr_close_socket(sock2);
fprintf(stderr, "Problem sending data\n");
Index: test//testfile.c
===
RCS file: /home/cvspublic/apr/test/testfile.c,v
retrieving revision 1.18
diff -u -r1.18 testfile.c
--- test//testfile.c2000/11/15 21:46:38 1.18
+++ test//testfile.c2000/12/03 17:26:42
@@ -124,10 +124,10 @@
fprintf(stdout, "OK\n");
}
-fprintf(stdout, "\tWriting to file...");
+printf((const char *)stdout, "\tWriting to file...");
nbytes = (apr_ssize_t)strlen("this is a test");
-if (apr_write(thefile, "this is a test", &nbytes) != APR_SUCCESS) {
+if (apr_write(thefile, "this is a test", (unsigned long *)&nbytes) !=
APR_SUCCESS) {
perror("something's wrong");
exit(-1);
}
@@ -177,7 +177,7 @@
fprintf(stdout, "\tReading from the file...");
nbytes = (apr_ssize_t)strlen("this is a test");
buf = (char *)apr_palloc(context, nbytes + 1);
-if (apr_r
Re: cvs commit: apr/include apr_lib.h
On Sun, 3 Dec 2000, Sam TH wrote: > On Sun, Dec 03, 2000 at 04:08:50PM -, David Reid wrote: > > Sam, can you cvs update and try the fix I committed? Thanks. > > > > Looks like it works. So APR appears not to have any obvious > difficulties on my end. :-) Great! Can you try running the test programs in the test directory? Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: cvs commit: apr/include apr_lib.h
> This still doesn't work. It turns out that neither BEOS nor > __POWER_PC__ is defined at the point in Subversion that this gets used > and likely not in other APR-using apps either. So, new patch, using > HAVE_isascii, which doesn't require including apr_private.h, despite > Ryan's worry. Also, defining it before using it is helpful. :-) Well, David already committed a very good patch, but I'll comment anyway :-) I had gone to bed before the rest of this stuff was discussed, so obviously I didn't get to comment last night. I just search all of the include directory, and the only place HAVE_isascii is defined is apr_private.h.in, so I can't see how we could check HAVE_isascii without that file. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: cvs commit: apr/include apr_lib.h
On Sun, Dec 03, 2000 at 04:08:50PM -, David Reid wrote: > Sam, can you cvs update and try the fix I committed? Thanks. > Looks like it works. So APR appears not to have any obvious difficulties on my end. :-) Thanks lots sam th [EMAIL PROTECTED] http://www.abisource.com/~sam/ GnuPG Key: http://www.abisource.com/~sam/key pgpZnPB74NPZq.pgp Description: PGP signature
Re: cvs commit: apr/include apr_lib.h
Sam, can you cvs update and try the fix I committed? Thanks. david
Re: cvs commit: apr/include apr_lib.h
> Don't worry about it... we'll get a solution worked out. I got the > impression David was looking into it :-) I've just committed a patch that should fix this. If we don't have isascii we don't really need to define it as we'll just hide it in apr_isascii, so we just define apr_isascii accordingly. If there is code that uses isascii it should be changed to use apr_isascii anyway, so this should work gfor everyone. Sam, can you test and let me know? david
Re: cvs commit: apr/include apr_lib.h
On Sun, Dec 03, 2000 at 07:42:55AM -0600, Sam TH wrote: > On Sun, Dec 03, 2000 at 10:11:43AM -, [EMAIL PROTECTED] wrote: > > gstein 00/12/03 02:11:43 > > > > Modified:include apr_lib.h > > Log: > > isascii() is not available on PowerPC versions of BeOS. Supply a > > definition. > > This still doesn't work. It turns out that neither BEOS nor > __POWER_PC__ is defined at the point in Subversion that this gets used > and likely not in other APR-using apps either. So, new patch, using > HAVE_isascii, which doesn't require including apr_private.h, despite > Ryan's worry. That isn't going to work. HAVE_isascii MUST be defined before reaching that point, which means *some* kind of config header must be included. It may happen to work for you simply because the darn thing isn't defined. Don't worry about it... we'll get a solution worked out. I got the impression David was looking into it :-) > Also, defining it before using it is helpful. :-) Those are macros. It doesn't matter at all, which is why I put it later. I felt it more important to see the "real" macros first and foremost. Then, as an extra bit of support, the definition comes in later. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/include apr_lib.h
On Sun, Dec 03, 2000 at 10:11:43AM -, [EMAIL PROTECTED] wrote: > gstein 00/12/03 02:11:43 > > Modified:include apr_lib.h > Log: > isascii() is not available on PowerPC versions of BeOS. Supply a definition. This still doesn't work. It turns out that neither BEOS nor __POWER_PC__ is defined at the point in Subversion that this gets used and likely not in other APR-using apps either. So, new patch, using HAVE_isascii, which doesn't require including apr_private.h, despite Ryan's worry. Also, defining it before using it is helpful. :-) Index: apr_lib.h === RCS file: /home/cvspublic/apr/include/apr_lib.h,v retrieving revision 1.45 diff -u -r1.45 apr_lib.h --- apr_lib.h 2000/12/03 10:11:43 1.45 +++ apr_lib.h 2000/12/03 13:41:59 @@ -107,6 +107,11 @@ * that's legacy libc for ya. These new macros do not support EOF like * the standard macros do. Tough. */ + +#if !HAVE_isascii +#define isascii(c) (((c) & ~0x7f)==0) +#endif + #define apr_isalnum(c) (isalnum(((unsigned char)(c #define apr_isalpha(c) (isalpha(((unsigned char)(c #define apr_iscntrl(c) (iscntrl(((unsigned char)(c @@ -121,10 +126,6 @@ #define apr_isxdigit(c) (isxdigit(((unsigned char)(c #define apr_tolower(c) (tolower(((unsigned char)(c #define apr_toupper(c) (toupper(((unsigned char)(c - -#if BEOS && __POWER_PC__ -#define isascii(c) (((c) & ~0x7f)==0) -#endif /* * Small utility macros to make things easier to read. Not usually a sam th [EMAIL PROTECTED] http://www.abisource.com/~sam/ GnuPG Key: http://www.abisource.com/~sam/key pgpZZn3lvATFP.pgp Description: PGP signature
