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. (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) Nicholas Clark
