PyString_GET_SIZE() (was: CVS: python/dist/src/Objects classobject.c,2.89,2.90 object.c,2.72,2.73)
On Wed, Jun 28, 2000 at 02:57:20PM -0700, Guido van Rossum wrote:
Update of /cvsroot/python/python/dist/src/Objects In directory slayer.i.sourceforge.net:/tmp/cvs-serv5838
Modified Files: classobject.c object.c Log Message: Trent Mick: change a few casts for Win64 compatibility.
Index: classobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/classobject.c,v retrieving revision 2.89 retrieving revision 2.90 diff -C2 -r2.89 -r2.90 *** classobject.c 2000/06/23 19:37:01 2.89 --- classobject.c 2000/06/28 21:57:18 2.90 *************** *** 284,288 **** if (v == NULL || !PyString_Check(v)) return "__name__ must be a string object"; ! if ((long)strlen(PyString_AS_STRING(v)) != PyString_GET_SIZE(v)) return "__name__ must not contain null bytes"; set_slot(&c->cl_name, v); --- 284,288 ---- if (v == NULL || !PyString_Check(v)) return "__name__ must be a string object"; ! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v)) return "__name__ must not contain null bytes"; set_slot(&c->cl_name, v);
Actually, it would seem to make more sense to place the cast *inside* the PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE. May as well start some ANSI-fication while we can... Guido: any problem with my changing the macro? Cheers, -g -- Greg Stein, http://www.lyra.org/
On Wed, Jun 28, 2000 at 03:17:58PM -0700, Greg Stein wrote:
On Wed, Jun 28, 2000 at 02:57:20PM -0700, Guido van Rossum wrote:
Update of /cvsroot/python/python/dist/src/Objects In directory slayer.i.sourceforge.net:/tmp/cvs-serv5838
Modified Files: classobject.c object.c Log Message: Trent Mick: change a few casts for Win64 compatibility.
Index: classobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/classobject.c,v retrieving revision 2.89 retrieving revision 2.90 diff -C2 -r2.89 -r2.90 *** classobject.c 2000/06/23 19:37:01 2.89 --- classobject.c 2000/06/28 21:57:18 2.90 *************** *** 284,288 **** if (v == NULL || !PyString_Check(v)) return "__name__ must be a string object"; ! if ((long)strlen(PyString_AS_STRING(v)) != PyString_GET_SIZE(v)) return "__name__ must not contain null bytes"; set_slot(&c->cl_name, v); --- 284,288 ---- if (v == NULL || !PyString_Check(v)) return "__name__ must be a string object"; ! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v)) return "__name__ must not contain null bytes"; set_slot(&c->cl_name, v);
Actually, it would seem to make more sense to place the cast *inside* the PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE.
May as well start some ANSI-fication while we can...
I agree. Go to town, Greg. :) Trent -- Trent Mick trentm@activestate.com
! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v))
Actually, it would seem to make more sense to place the cast *inside* the PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE.
May as well start some ANSI-fication while we can...
Guido: any problem with my changing the macro?
Please leave the macro alone. The type of the macro should be the same as the type of the function -- PyString_Size() -- which is int. If you change this, you potentially get tons of warnings because of the signed / unsigned nature. ANSI-fication is a good project for after 1.6. But even then, it's a separate decision whether the size of a string should be a size_t instead of an int. (The ob_size field should also change, if so -- with even more consequences.) --Guido van Rossum (home page: http://www.python.org/~guido/)
On Wed, Jun 28, 2000 at 08:11:36PM -0500, Guido van Rossum wrote:
! if (strlen(PyString_AS_STRING(v)) != (size_t)PyString_GET_SIZE(v))
Actually, it would seem to make more sense to place the cast *inside* the PyString_GET_SIZE() macro. That is the "true" semantic for GET_SIZE.
May as well start some ANSI-fication while we can...
Guido: any problem with my changing the macro?
Please leave the macro alone. The type of the macro should be the same as the type of the function -- PyString_Size() -- which is int. If you change this, you potentially get tons of warnings because of the signed / unsigned nature.
ANSI-fication is a good project for after 1.6. But even then, it's a separate decision whether the size of a string should be a size_t instead of an int. (The ob_size field should also change, if so -- with even more consequences.)
Post 1.6, yes... I had figured on ob_size changing. Certainly not now :-) But I understand the point about different return types. No problem. [ of course, I would state that PyString_Size should also change and we fix those warnings... but I'll be patient :-) ] How about removing Py_PROTO() usage, and changing function definitions from K&R arg declaration to ANSI declarations? That kind of work is pretty simple, straight-forward, and if somebody has free time to plod through the work... so much the better. I believe that these changes would not introduce any stability problems, and could be done independently from your busy schedule. Hmm. Is there a good place to start listing these todo items? One that we can truly use for communicating this info? In Apache, we have a file named STATUS that everybody uses for dropping ideas, patch references, critical bugs, etc. As that file gets changed, we see it in the -checkins alias, so everybody is aware of the suggested changes/problems/available patches/etc. It also holds people's votes on particular changes. Can we institute something similar? Possibly Misc/STATUS? Should I post Apache's STATUS file as an example? Cheers, -g -- Greg Stein, http://www.lyra.org/
[Greg Stein]
... How about removing Py_PROTO() usage, and changing function definitions from K&R arg declaration to ANSI declarations? That kind of work is pretty simple, straight-forward, and if somebody has free time to plod through the work... so much the better.
I think it's too late in the cycle to suggest work for others to do and get any payback from that. Unless you're the one with the free time -- in which case full speed ahead and God bless! I previously volunteered to take the Py_PROTO crap on, as I use an editor with a symbol database that gets confused by that stuff, but I'm sure not going to start that this week.
... Hmm. Is there a good place to start listing these todo items?
Not that I know of. "Group whiteboards" and shared journals etc are darned useful, though.
One that we can truly use for communicating this info? In Apache, we have a file named STATUS that everybody uses for dropping ideas, patch references, critical bugs, etc. As that file gets changed, we see it in the -checkins alias, so everybody is aware of the suggested changes/problems/available patches/etc. It also holds people's votes on particular changes.
Can we institute something similar? Possibly Misc/STATUS? Should I post Apache's STATUS file as an example?
Yes, sure, no: just check one in! If Guido hates it, we can remove it later. In the meantime, I bet we'll find great ways to use it. In the spirit of Unix, maybe it should be called Misc/gwtbd <wink>. let-a-thousand-idiosyncracies-bloom-ly y'rs - tim
On Thu, 29 Jun 2000, Tim Peters wrote:
... Hmm. Is there a good place to start listing these todo items?
Not that I know of. "Group whiteboards" and shared journals etc are darned useful, though.
Wiki = Group whiteboard Zope could do a lot of this stuff well. As is, ZWiki offers some organizational features. I've held off on pushing them because they're still baking - things like change notifications, discretion about change privileges, versions (with differences, based on your ndiff.py), etc are coming soonish. (Exactly how soonish is hard to say, the way time and more direct business obligations are - but this stuff actually is important to us, we're using them a lot for collaboration, and need for the dynamics to scale...) I also have the feeling that our tracker would be good for patch management - except, i don't really know what the requirements are, there, and once again, tracker only gives notifications via email, it doesn't take input that way. Anyway, to see leads on both zwikis and tracker, see: http://www.zope.org/Members/klm/TrackerWiki Oh, and it would be easy to set up a wiki for python dev on zope.org somewhere - i could put it in my account, or we could situate one more centrally, in a storage that's never packed, so the version history is maintained. Or any of you could get a zope.org membership and set some up, yerselves. Or set up a zope somewhere - it'd be !cool! if sourceforge were willing... Ken klm@zope.org
On Thu, 29 Jun 2000, Ken Manheimer wrote:
Wiki = Group whiteboard [...] Oh, and it would be easy to set up a wiki for python dev on zope.org somewhere - i could put it in my account, or we could situate one more
http://www.zope.org/Members/klm/PythonDev/TodoLists There's nothing else of substance there, but anyone who's a member at zope.org can edit and add pages... Ken
[Tim]
... "Group whiteboards" and shared journals etc are darned useful, though.
[Ken Manheimer]
Wiki = Group whiteboard
Ya, I kind of picked that up from your last passionate advertisement for this stuff <wink>. Not knocking it! Never tried it. Believe it or not, I spend as little time on the web as possible. After I've gotten into a place to live here, and this current release crunch is behind us, I'm definitely going to check out your leads. For the past several years my development group worked thru Lotus Notes, which I didn't much care for at the time, but I'm increasingly realizing just how essential group-modifiable shared persistent documents were to our productivity. Notes is the purest example of a whole being greater than the sum of its parts I've ever seen (lousy mail system, lousy database, lousy change manager, lousy bug tracker, lousy workflow manager, worse than lousy native scripting ... but they all sucked in ways that were downright synergistic <0.9 wink>).
... Anyway, to see leads on both zwikis and tracker, see:
can-beopen-zwiki-2.0-be-far-behind<wink>?-ly y'rs - tim
Tim Peters writes:
productivity. Notes is the purest example of a whole being greater than the sum of its parts I've ever seen (lousy mail system, lousy database, lousy change manager, lousy bug tracker, lousy workflow manager, worse than lousy native scripting ... but they all sucked in ways that were downright synergistic <0.9 wink>).
I had to use Notes before working at CNRI, and wouldn't have described all those sucky components as "synergistic". ;) -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member
Hmm. Is there a good place to start listing these todo items? One that we can truly use for communicating this info? In Apache, we have a file named STATUS that everybody uses for dropping ideas, patch references, critical bugs, etc. As that file gets changed, we see it in the -checkins alias, so everybody is aware of the suggested changes/problems/available patches/etc. It also holds people's votes on particular changes.
Can we institute something similar? Possibly Misc/STATUS? Should I post Apache's STATUS file as an example?
Possibly, but I'm somewhat skeptical. I used to have a large TODO file -- still have it -- but it's so full of long-term ideas that never happened that I rarely look in it any more. I never got into the discipline of using it for my day-to-day priorities -- it was more of a place to write down long-term ideas so I could forget about them. I'll append it. I appreciate a copy of Apache's STATUS file. --Guido van Rossum (home page: http://www.python.org/~guido/) NEW TODO LIST FOR 1.6 ===================== IDLE: set window class? socket/ssl version mystery UNIFIED TODO LIST =================
guido wrote:
Hmm. Is there a good place to start listing these todo items? One that we can truly use for communicating this info? In Apache, we have a file named STATUS that everybody uses for dropping ideas, patch references, critical bugs, etc. As that file gets changed, we see it in the -checkins alias, so everybody is aware of the suggested changes/problems/available patches/etc. It also holds people's votes on particular changes.
Can we institute something similar? Possibly Misc/STATUS? Should I post Apache's STATUS file as an example?
Possibly, but I'm somewhat skeptical. I used to have a large TODO file -- still have it -- but it's so full of long-term ideas that never happened that I rarely look in it any more.
instead of a file, I suggest taking a look at ?!ng's Roundup (once 1.6 final is out, of course). </F>
On Thu, Jun 29, 2000 at 08:49:32AM -0500, Guido van Rossum wrote:
Hmm. Is there a good place to start listing these todo items? One that we can truly use for communicating this info? In Apache, we have a file named STATUS that everybody uses for dropping ideas, patch references, critical bugs, etc. As that file gets changed, we see it in the -checkins alias, so everybody is aware of the suggested changes/problems/available patches/etc. It also holds people's votes on particular changes.
Can we institute something similar? Possibly Misc/STATUS? Should I post Apache's STATUS file as an example?
Possibly, but I'm somewhat skeptical. I used to have a large TODO file -- still have it -- but it's so full of long-term ideas that never happened that I rarely look in it any more. I never got into the discipline of using it for my day-to-day priorities -- it was more of a place to write down long-term ideas so I could forget about them. I'll append it. I appreciate a copy of Apache's STATUS file.
Attached below... -- Greg Stein, http://www.lyra.org/ Apache 2.0 STATUS: Last modified at [$Date: 2000/06/28 11:41:14 $] Release: 2.0a5 : ??? 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 RELEASE SHOWSTOPPERS: * Win32: Get mod_auth_digest working under win32 - APR_HAS_RANDOM should be defined on windows and there is a lib/apr/misc/win32/rand.c which is basically a copy of what mod_auth_digest used to use. * Re-work configuration for top level Apache. Work should start with trying to clean the autoconf stuff. If and only if this proves impossible to do (very unlikely), autoconf should be removed and we will roll our own config implementation. * suEXEC doesn't work Status: Manoj has posted an patch to fix this. <19991103003605.A20612@samosa.mindspring.com> * Win32: Enable the Windows MPM to honor max_requests_per_child Status: Bill will fix this. * Win32: Get Apache working on Windows 95/98. The following work (at least) needs to be done: - winnt MPM: Fix 95/98 code paths in the winnt MPM. There is some NT specific code that is still not in NT only code paths - IOL binds to APR sendfile, implemented with TransmitFile, which is not available on 95/98. * Win32: Test access logging with multiple threads. Will the native file I/O calls serialize automagically like the CRT calls or do we need to add region locking each time we access the logs? Status: * Win32: Complete the revamp the service environment and relocation into the WinNT MPM. Changes ServerRoot service registry parameter into ConfigArgs for multiple service startup parameters. Problems to fix in the revamp: -k shutdown/restart are broken, signals are not being acknowledged. Close window and shutdown also seem out of sorts. OtherBill is working on this * Win32: fix build/run time environment to remove ApacheCore.dll linkage from ab.exe and htdigest.exe. * We need a thread-safe resolver, at least on Unix. Status: The best known candidate would be something from BIND v9. Status: Greg asks, "why? doesn't gethostbyname_r() handle this?" * Modify mod_cgi and mod_cgid to deal with directories. This allows a lot of directives to be removed from the core. RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * OS/2: Get loadable modules working again. Requires shared core support which doesn't appear to be catered for in the current build system. * OS/2: Make mod_status work for spmt_os2 MPM. * Build scripts do not recognise AIX 4.2.1 pthreads, so the pthread MPMs will not build. * Win32: Reuse accept socket after transmitfile/close This is not a bug, but would be nice to get this feature in before ship. * Win32: Enable the winnt MPM to use the new scoreboard API * Win32: Implement ap_shm_ functions in APR. * Win32: Win9x console window still won't play nice with the close window, logoff and shutdown scenarios. * Win32: Add a simple hold console open patch (wait for close or the ESC key, with a nice message) if the server died a bad death (non-zero exit code) in console mode. * Platforms that do not support fork (primarily Win32 and AS/400) Consider introducing HAVE_FORK feature macro. Architect start-up code that avoids initializing all the modules in the parent process on platforms that do not support fork. * Clean the code. There are a lot of places we used APR but didn't remove the hacks that were required for the cross-platform code in 1.3. We need to make the code look like APR was supposed to be there. * Go throught the 1.3 Bug DB and research the bugs marked "suspended". People were told these would be considered for inclusion in Apache 2.0, it would be nice to actually do so. * Win32: Migrate the MPM over to use APR thread/process calls. This would eliminate some code in the Win32 branch that essentially duplicates what is in APR. Bill says we need a new procattr, APR_CREATE_SUSPENDED (or something similar) to direct ap_create_process to create the process suspended. We also need a call to wake up the suspended process This may not be able to be implemented everywhere though. Status: * Move I/O layering into APR. * There are still a number of places in the code where we are loosing error status (i.e. throwing away the error returned by a system call and replacing it with a generic error code) * Win32: Implement reliable piped logs on Windows Status: * Use APR to get rid of more platform dependancies. Status: Ryan Bloom <rbb@covalenet.net> is working on this. * The connection status table is not very efficient. Also, very few stats are exported to the connection status table (easy to fix), and mod_status is ugly. * Mass vhosting version of suEXEC. * Replace tables with a proper opaque ADT that has pluggable implementations (including something like the existing data type, plus hash tables for speed, with options for more later). Status: fanf is working on this. * configuration option to use *DBM Status: Greg +1 (volunteers) * add SDBM into src/lib/sdbm/ as a default/fallback DBM implementation. SDBM is used by Perl, mod_dav, mod_sssl, others for basic DBM support. Status: Greg +1 (volunteers) * Integrate mod_dav. Message-id: <20000625173247.M29590@lyra.org> Status: in process. - APR does not provide a couple needed things: chmod() and ap_finfo_t.st_dev. - expat-lite needs to be brought up to parity with the 1.3 vsn and inserted into the config/build process - SDBM needs to go into the config/build process - fix up include dirs to pick up expat-lite, sdbm, dav/main - APR-ization to the dav/fs/ stuff - case_preserved_filename stuff * ap_core_translate() and its use by mod_mmap_static are a bit wonky. The function should probably be exposed as a utility function (such as ap_translate_url2fs() or ap_validate_fs_url() or something). Another approach would be a new hook phase after "translate" which would allow mod_mmap_static to munge what the translation has decided to do. Status: Greg +1 (volunteers), Ryan +1 * Go through ap_config.h and namespace-protect the symbols (e.g. USE_*). Some symbols can/should move to mpm_common.h where possible. * Explore use of a post-config hook for the code in http_main.c which calls ap_fixup_virutal_hosts(), ap_fini_vhost_config(), and ap_sort_hooks() [to reduce the logic in main()] * read the config tree just once, and process N times (as necessary) * add a version number to ap_initialize() as an extra failsafe against (APR) library version skew. MsgID: <Pine.LNX.4.10.10005231712380.31927-100000@nebula.lyra.org> Status: Greg +1 (volunteers), Jeff +1, Ryan +1, Tony -0(?) * mod_info to use the configuration tree * add output filtering. there are a couple variants for this. - The "link-based" variant is ready to go: MsgID: <20000627044436.N29590@lyra.org> (patch) MsgID: <20000627053302.O29590@lyra.org> (demo usage) MsgID: <Pine.LNX.4.21.0006270731240.4006-100000@koj.rkbloom.net> (problems with the patch) Status: Greg +1, Ryan -1 Other bugs that need fixing: * MaxRequestsPerChild measures connections, not requests. Until someone has a better way, we'll probably just rename it "MaxConnectionsPerChild". * Regex containers don't work in an intutive way Status: No one has come up with an efficient way to fix this behavior. Dean has suggested getting rid of regex containers completely. * SIGSEGV on Linux (glibc 2.1.2) isn't caught properly by a sigwaiting thread. We need to work around this, perhaps unless there is hope soon for a fixed glibc. * The mod_cgid daemon process isn't always cleaned up when httpd gets SIGTERM. Jeff thinks it may be as simple as registering the daemon process for cleanup with the proper pool, but he hasn't looked at it in enough detail. * The MM library is built as static and shared library. This should be set up to build only the required version. Other features that need writing: * Finish infrastructure in core for async MPMs Status: post 2.0 * TODO in source -- just do an egrep on "TODO" and see what's there Documentation that needs writing: * Mod_status docs are needed. * The concept of MPMs, especially if we ship more than one MPM for a given platform * New directives in the various MPMs and appropriate links from obsolete directives in core.html to the MPM documentation. * Revise manual/stopping.html and the last part of manual/misc/perf-tuning.html to take account of the MPMs. * API documentation Status: Ben Laurie has written some hooks documentation (apache-2.0/htdocs/hooks.html) * Changes since 1.3.9 can be more easily seen in the commitlog file dev.apache.org:/home/cvs/CVSROOT/commitlogs/apache-2.0 which includes some of Roy's comments when the changes were committed in rough change-sets by purpose. Note that the commitlog does not show the contents of new files until later. * mod_dav documentation (once integrated) Available Patches: * Mike Abbott's <mja@trudge.engr.sgi.com> patches to improve performance Status: These were written for 1.3, and are awaiting a port to 2.0 * Jim Winstead's <jimw@trainedmonkey.com> patch to add CookieDomain and other small mod_usertrack features Open issues: * What do we do about mod_proxy? * Which MPMs will be included with Apache 2.0? * Is conf/highperformance.conf-dist obsolete? It looks obsolete.
participants (7)
-
Fred L. Drake, Jr. -
Fredrik Lundh -
Greg Stein -
Guido van Rossum -
Ken Manheimer -
Tim Peters -
Trent Mick