From owner-freebsd-current Mon Jun 1 12:55:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA17020 for freebsd-current-outgoing; Mon, 1 Jun 1998 12:55:23 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA17004 for ; Mon, 1 Jun 1998 12:55:21 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id LAA00742; Mon, 1 Jun 1998 11:49:31 -0700 (PDT) Message-Id: <199806011849.LAA00742@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Joerg Schilling cc: mike@smith.net.au, freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet In-reply-to: Your message of "Mon, 01 Jun 1998 18:30:15 +0200." <199806011630.SAA17075@sherwood.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Mon, 01 Jun 1998 11:49:30 -0700 From: Mike Smith Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id MAA17008 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >From mike@antipodes.cdrom.com Mon Jun 1 18:17:40 1998 > > >> You cannot deal with this problem: > >> = > > >> Systems that define _SC_PAGESIZE or _SC_PAGE_SIZE (HP-UX) > >> don't support getpagesize() so there is no way to fix this > >> in runtime except if you introduce an additional = > > >> = > > >> HAVE_GETPAGESIZE > >> = > > >> in the autoconfiguration. > >> = > > >> But even then the code would be badly readable. = > > >This is a problem with the design of cdrecord, insofar as it's fairly > > Sorry, this is a problem for evryone who wants to write portable code. > But FreeBSD seems to ignore this issue. It's not an operating system issue, it's an application issue. Obtaining the page size is something that needs to be abstracted out of the application's space into the operating system interface for the application, simply because it's something that's traditionally platform-specific. In your case, you would probably want a vector mechanism, eg. struct { int (* pagesize)(); ... } sysdep; so then in your application context you say: pagesize = sysdep.pagesize(); and in the BSD layer you would say: int bsd_pagesize(void) { int pagesize; if ((pagesize = sysconf(_SC_PAGESIZE)) == -1) pagesize = getpagesize(); return(pagesize); } ... void appsetup(void) { ... sysdep.pagesize = bsd_pagesize; ... } This is really basic portability design. > You may have a functional sysconf(_SC_PAGESIZE) _and_ getpagesize() if you > like to be able to run portable applications but you cannot have a non > functional sysconf(_SC_PAGESIZE). That's an opinion. It's not one that others share. I would be inclined to say that if you want to call sysconf() at all, you need to be prepared to handle it properly, and that includes setting/checking errno when you make the call. > This looks to me like Microsofts tried to create a Posix environment that > is Posix compliant on the paper but would prevent you from running real world > Posix applications on it. This is more of a commentary on the usefulness of the Posix standard than anything else. > I would call a sysconf implementation that is not functional for sysconf(_SC_PAGESIZE) > although getpagesize() exists buggy. That's one interpretation. I'd be curious to know whether the functionality of one given sysconf() argument implies the functionality of others though. Peter? Is this something that your reading of the Posix words would let us get away with? It'd certainly reduce the noise on this one a little. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message