Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!umich!sharkey!cfctech!rphroy!tkacik
From: tkacik@rphroy.uucp (Tom Tkacik)
Newsgroups: comp.lang.perl
Subject: Re: Early returns
Message-ID: <35805@rphroy.UUCP>
Date: 19 Oct 90 12:24:01 GMT
References: <10009@jpl-devvax.JPL.NASA.GOV>
Sender: news@rphroy.UUCP
Reply-To: tkacik@rphroy.uucp (Tom Tkacik)
Organization: GM Research, Warren, Mi
Lines: 31

In article <10009@jpl-devvax.JPL.NASA.GOV>, lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes:
|> The other problem is on machines that only support old dbm, there is a
|> reference to a new dbm function call at line 405 in hash.c.  As a
|> workaround, you can throw in a 
|> 
|> 	#define dbm_nextkey(d, k) nextkey(k)
|> 
|> into perl.h where the other dbm defines are.
|> 
|> If this is all that goes wrong, I'll be a happy man.

I am trying to compile perl3 p36 on an Apollo.
The Apollo does have ndbm, so the above is not a problem,
dbm_nextkey if defined.
It thinks it has an ANSI C compiler, it doesn't really,
but it does have prototypes for many, (if not all library functions).
In particular, it has one for dbm_nextkey(),
	datum   dbm_nextkey(DBM *db);

Hash.c fails to compile because of the wrong number of arguments.
Wondering if the Apollo has it wrong, I also looked at the manuals for
SUN and SGI machines, and they also show the same thing,
(dbm_nextkey takes a single argument).

I can get it to compile be adding a -U__STDC__ option to CFLAGS,
(never a bad thing to do on the Apollo), but this really otta' be fixed.
-- 
Tom Tkacik				...uunet!edsews!rphroy!tkacik
GM Research Labs			tkacik@kyzyl.mi.org
"I'm president of the United States, and I'm not going to eat anymore broccoli."
						--- George Bush