[OPEN-ILS-DEV] PATCH: WWW/SuperCat.pm
I am stuck in a maze of stacks, all alike, with only my handy PDA to
guide me. Currently, if I do that, the slimpac just reminds me where I
am (in a maze of stacks).
I have submitted two patches. The first, 'SuperCat.pm.patch.help',
will let me use the slimpac (which works better on my PDA) to find
helpful materials (to solve any problem, not just this maze one) by
searching for the keyword 'help' under any index. The second,
'SuperCat.pm.patch.whereami' does the same as the first, but will also
will helpfully remind me where I am if I ask the slimpac the slightly
more specific question, 'whereami'.
It goes without saying that only one of these patches ought to be applied.
Neither of these probably requires a DCO, but here one is anyway.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Signed-off-by: Brandon Uhlman ([EMAIL PROTECTED])
==
Brandon W. Uhlman, Systems Consultant
Public Library Services Branch
British Columbia Ministry of Education
Vancouver, BC (and Lillooet, BC)
Phone: (604) 660-2972 or (250) 256-0344
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
Index: Open-ILS/src/perlmods/OpenILS/WWW/SuperCat.pm
===
--- Open-ILS/src/perlmods/OpenILS/WWW/SuperCat.pm (revision 11222)
+++ Open-ILS/src/perlmods/OpenILS/WWW/SuperCat.pm (working copy)
@@ -1040,21 +1040,6 @@
}
my $flesh_feed = ($type =~ /-full$/o) ? 1 : 0;
- if ($terms eq 'help') {
- print $cgi-header(-type = 'text/html');
- printHTML;
- html
-head
- titlejust type something!/title
-/head
-body
- pYou are in a maze of dark, twisty stacks, all
alike./p
-/body
- /html
- HTML
- return Apache2::Const::OK;
-}
-
$terms = decode_utf8($terms);
$lang = 'eng' if ($lang eq 'en-US');
Index: src/perlmods/OpenILS/WWW/SuperCat.pm
===
--- src/perlmods/OpenILS/WWW/SuperCat.pm(revision 11222)
+++ src/perlmods/OpenILS/WWW/SuperCat.pm(working copy)
@@ -1040,12 +1040,12 @@
}
my $flesh_feed = ($type =~ /-full$/o) ? 1 : 0;
- if ($terms eq 'help') {
+ if ($terms eq 'whereami') {
print $cgi-header(-type = 'text/html');
printHTML;
html
head
- titlejust type something!/title
+ title(X) YOU ARE HERE./title
/head
body
pYou are in a maze of dark, twisty stacks, all
alike./p
Re: [OPEN-ILS-DEV] Booking Equipment or Rooms on Evergreen
Jason Etheridge wrote: Are there any other open source projects that do this? We might be able to integrate with them or leverage their code. -- MRBS (http://mrbs.sourceforge.net/) is popular and feaure-rich. We've been using it for 5-6 year to book meeting rooms (both public study rooms and staff meeting rooms) and also to book some types of equipment like staff laptops. Mark Mark Jordan Head of Library Systems W.A.C. Bennett Library, Simon Fraser University Burnaby, British Columbia, V5A 1S6, Canada Voice: 778.782.5753 / Fax: 778.782.3023 [EMAIL PROTECTED]
Re: [OPEN-ILS-DEV] PATCH: utils.h (OSRF_BUFFER_ADD_CHAR)
This patch fixes a bug in the OSRF_BUFFER_ADD_CHAR macro. Like the corresponding buffer_add_char function, this macro appends a specified character to a growing_buffer. Unlike the function, however, the existing version of the macro does not also append a terminal nul. This bug had gone unnoticed because, most of the time, the rest of the buffer is already filled with nuls, left over from the initial creation of the growing_buffer. I stumbled across the problem when, in the course of writing a test harness for some other changes, I called buffer_reset() in order to reuse an existing growing_buffer instead of destroying and re-creating it. With debugging turned on, buffer_reset() fills the buffer with exclamation points, leaving a nul only in the very last byte. Later, if we use buffer_add() or buffer_fadd() to extend the string stored in the growing_buffer, it uses strcat() to append the new characters. The result is a buffer overflow. Actually buffer_reset() should place a nul in the first byte of the buffer. Tomorrow I shall submit a patch to that effect. Hey, Scott! It's good to hear from you. Patch is applied with thanks. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
Re: [OPEN-ILS-DEV] PATCH: utils.c (miscellaneous)
This patch is mostly a couple of tweaks to the growing_buffer code, loosely related to my previous patch to utils.h. There is also a small tweak to uescape(). 1. in buffer_add() I replaced strcat() with strcpy() for appending the new string. Since we already know where the end of the old string is, we don't need to ask strcat() to find it for us. 2. In buffer_reset(), the old code contains the following: osrf_clearbuf( gb-buf, sizeof(gb-buf) ); The evident intent is to clear the buffer. However sizeof(gb-buf) is not the size of the buffer, it's the size of the pointer to the buffer. We were clearing only the first four bytes or so. I changed the line to: osrf_clearbuf( gb-buf, gb-size ); 3. Also in buffer_reset(), I added a line to populate the first byte of the buffer with a nul, to ensure that the length of the (empty) string matches the n_used member. 4. In uescape(), we were examining the contents of string[] without first verifying that string was not NULL. The result would be undefined behavior if string were ever NULL. I added a couple of lines to treat a NULL pointer as if it were a pointer to an empty string. Also applied. -- Together with yesterday's patch to utils.h, these changes are intended to guarantee that the length of the string stored in a growing_buffer always matches the value of n_used. buffer_data() relies on such a match. So did buffer_add() (and, indirectly, buffer_fadd()) until I changed it. So does every bit of code that calls buffer_release(). Previously the terminal nuls were supplied by filling the entire buffer with nuls before otherwise populating it. This practice always bothered me because it looked like a waste of CPU cycles. The use of osrf_clearbuf() in buffer_reset() is probably no longer necessary or useful. However, from an abundance of caution I have left it in there. I cannot guarantee that there is no other bit of code that fails to append a terminal nul where it should. It might be a useful experiment to eliminate the prenullification and see if anything breaks. Another possible experiment is to insert the assert() macro at the entry and exit of each of the growing_buffer functions: assert( strlen( gb-buf ) == gb-n_used ); Such an assertion would add overhead for development and debugging, but would reduce to a no-op when NDEBUG is #defined. I bet there are still some dragons lurking, so your caution is appreciated. Thanks again, -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / The Evergreen Experts | phone: 877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://esilibrary.com
