On Thu 03 Oct 2002 11:43, Nicholas Clark <[EMAIL PROTECTED]> wrote: > On Wed, Oct 02, 2002 at 05:07:20PM -0400, Michael G Schwern wrote: > > On Wed, Oct 02, 2002 at 10:26:32PM +0200, H.Merijn Brand wrote: > > > > > I realize that sbrk() is a familiar concept to deep C programmers on > > > > BSD-style systems, but in order for this to be useful to Perl programmers, > > > > or even users not familiar with BSD, you're going to have to name it > > > > something more descriptive than sbrk() and explain better what it does. > > Is it going to be useful (see below) to people who don't know this sort of > thing? > > > > That's why there /is/ an Internals.pm: to hide the gory details and > > > implementation specifics to the user. > > > > But you're not. You're just exposing sbrk(), which is a gory detail. My > > sbrk man page describes sbrk as being used to find "the current location of > > the program break" which means nothing to me. Nor does "returns the current > > memory top". > > > > It'll be even worse on an OS which doesn't have sbrk, which means no sbrk(2) > > man page to look at. > > > > Does sbrk() just return the current number of bytes allocated to the > > program? > > If it only returns the value from sbrk(), damn well call it sbrk. > That's what it is; don't invent a new name. It will only cause confusion > later for anyone who does migrate from perl to dealing with unix guts, or > needs to talk to someone who does know what sbrk() is.
Ahh, someone on /my/ side. I guess most of the discussion boils down to - sbrk () being unknown to people not familiar with unix - Devel::Internals being to wide. [ Gimme another namespace proposal ] - MemUsed interface to polymorphistic So far, all I got was criticism. I asked for it. But no-one said it was useful. (Or I didn't read between the lines enough). If you don't, I'll just use it for myself, with whatever interface *I* like. If there is some support, I'll change it to fit the more common crowd and put it on CPAN. > (Oh. we're going to call this concept pels. You may hear other people call > them pixels...) > > The reason I'm saying it might not be much use to people unfamiliar with > the internals of unix is precisely because it does return a precisely defined > but not directly useful value - the highest address on the heap. > If you read it, call perl code that creates a known perl structure, and read > it again, doesn't go up directly and exactly related to the amount of memory > that structure needed. Depending on how much other memory there is free, it > may not go up at all, or it may go up more if the allocation system grabs a > big block of free space. > > > However, the function returns something that may not be sbrk() on a system > without sbrk(), don't call it sbrk, because it ain't. > > (And do document what it does return on each different system) *THAT* my dear sir, I don't know :) You, might know. Are there systems where the sbrk () value /decreases/ after mallocs? Top-down stacks and heaps a.o.t. bottom-up. > Nicholas Clark -- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: [EMAIL PROTECTED] http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
