NetBSD Problem Report #22594
Received: (qmail 5996 invoked by uid 605); 25 Aug 2003 07:36:01 -0000
Message-Id: <200303231931.h2NJVP802272@vash.cel.plethora.net>
Date: Sun, 23 Mar 2003 13:31:25 -0600 (CST)
From: seebs <seebs@vash.cel.plethora.net>
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: seebs@plethora.net
To: gnats-bugs@gnats.netbsd.org
Subject: setkey(3) is in user namespace
X-Send-Pr-Version: 3.95
>Number: 22594
>Category: standards
>Synopsis: setkey(3) is in user namespace
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: kleink
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Aug 25 07:37:00 +0000 2003
>Closed-Date: Mon Sep 09 00:35:10 +0000 2024
>Last-Modified: Mon Sep 09 00:35:10 +0000 2024
>Originator: seebs
>Release: NetBSD 1.6Q
>Organization:
>Environment:
System: NetBSD vash.cel.plethora.net 1.6Q NetBSD 1.6Q (VASH) #0: Thu Mar 20 11:36:14 CST 2003 seebs@vash.cel.plethora.net:/usr/src/sys/arch/i386/compile/VASH i386
Architecture: i386
Machine: i386
>Description:
"setkey" is in user namespace, and user programs should be able to
define symbols named that.
>How-To-Repeat:
Define a function called setkey().
>Fix:
Maybe this needs to be a weak reference?
>Release-Note:
>Audit-Trail:
From: Klaus Klein <kleink@reziprozitaet.de>
To: seebs@vash.cel.plethora.net
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: standards/22594: setkey(3) is in user namespace
Date: Mon, 25 Aug 2003 10:09:24 +0200
seebs <seebs@vash.cel.plethora.net> writes:
>>Description:
> "setkey" is in user namespace, and user programs should be able to
> define symbols named that.
>>How-To-Repeat:
> Define a function called setkey().
>>Fix:
> Maybe this needs to be a weak reference?
Providing a weakly-aliased public name wouldn't change that, as far as
I can tell. setkey() is provided by libcrypt and libcrypto only, so
you'd have to link against those in the first place, and I'd expect
applications to be aware of those name space implications.
Hence I can't quite tell what your problem is exactly; as for its
declaration in <stdlib.h>, that can be avoided by defining the
appropriate feature test symbols (but keep in mind this is an XPG4.2
interface after all).
Please provide a little more information.
- Klaus
Responsible-Changed-From-To: standards-manager->kleink
Responsible-Changed-By: kleink
Responsible-Changed-When: Mon Aug 25 08:11:07 UTC 2003
Responsible-Changed-Why:
I'm tracking this.
From: seebs@plethora.net (Peter Seebach)
To: Klaus Klein <kleink@reziprozitaet.de>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: standards/22594: setkey(3) is in user namespace
Date: Mon, 25 Aug 2003 03:32:55 -0500
In message <87oeye2m6j.fsf@minor-variation.et.reziprozitaet.de>, Klaus Klein wr
ites:
>seebs <seebs@vash.cel.plethora.net> writes:
>>>Description:
>> "setkey" is in user namespace, and user programs should be able to
>> define symbols named that.
>>>How-To-Repeat:
>> Define a function called setkey().
>>>Fix:
>> Maybe this needs to be a weak reference?
>Providing a weakly-aliased public name wouldn't change that, as far as
>I can tell. setkey() is provided by libcrypt and libcrypto only, so
>you'd have to link against those in the first place, and I'd expect
>applications to be aware of those name space implications.
>Hence I can't quite tell what your problem is exactly; as for its
>declaration in <stdlib.h>, that can be avoided by defining the
>appropriate feature test symbols (but keep in mind this is an XPG4.2
>interface after all).
>Please provide a little more information.
Hmm. I don't know much about XPG4.2. My default assumption has been that,
if I don't do anything magical with #defines, and I include only ISO C
headers, that all ISO C programs will run correctly. You're right that a
weak reference won't solve this, if it's in the header.
Shouldn't it be provided only if you request it, given that it's an extension
to the basic language?
I believe the context of this was that I was working on a program to
manipulate a programmable keypad, and the obvious names for a couple of
functions were "getkey" and "setkey".
-s
From: Klaus Klein <kleink@reziprozitaet.de>
To: seebs@plethora.net (Peter Seebach)
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: standards/22594: setkey(3) is in user namespace
Date: Mon, 25 Aug 2003 13:01:34 +0200
seebs@plethora.net (Peter Seebach) writes:
> Hmm. I don't know much about XPG4.2. My default assumption has been that,
> if I don't do anything magical with #defines, and I include only ISO C
> headers, that all ISO C programs will run correctly. You're right that a
> weak reference won't solve this, if it's in the header.
[Actually it's even POSIX-2001. At the time of writing I wasn't sure
if it hadn't been obsoleted after XPG5. :-]
Actually, no. When I wrote this won't solve the problem, I referred
to your report of setkey() being _defined_, for which you need to link
against libcrypt or libcrypto.
> Shouldn't it be provided only if you request it, given that it's an
> extension to the basic language?
I don't think this is feasible. Restricting the default to C89/99
would result in a ~useless environment on the typical UNIX machine.
NetBSD is trying to provide a (useful?) POSIX-conforming environment
plus extensions. If you want to build a (strictly) conforming
application to either standard, you should define appropriate values
of _POSIX_C_SOURCE, _XOPEN_SOURCE or _ANSI_SOURCE. There used to be
some vendor divergence over either defaulting to make XPG4.2
interfaces available or doing so only if _XOPEN_SOURCE etc. are
defined, but with POSIX-2001 that's no longer relevant.
I'd like to add another such feature test macro for C99 eventually,
though.
Of course there's early implementation heritage left to blame, but
that happens when you develop a programming language and standard
library together with a full-blown OS. :-}
- Klaus
From: seebs@plethora.net (Peter Seebach)
To: Klaus Klein <kleink@reziprozitaet.de>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: standards/22594: setkey(3) is in user namespace
Date: Mon, 25 Aug 2003 11:51:35 -0500
In message <87wud20zn4.fsf@minor-variation.et.reziprozitaet.de>, Klaus Klein wr
ites:
>I don't think this is feasible. Restricting the default to C89/99
>would result in a ~useless environment on the typical UNIX machine.
You have a point. With a number of other extended features (e.g., "end"), the
environment has put in some defenses so that programs that try to define their
own don't get bitten too hard.
>Of course there's early implementation heritage left to blame, but
>that happens when you develop a programming language and standard
>library together with a full-blown OS. :-}
Yup.
-s
State-Changed-From-To: open->closed
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Mon, 09 Sep 2024 00:35:10 +0000
State-Changed-Why:
setkey declaration is restricted to:
- _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED, or
- _XOPEN_SOURCE >= 500, or
- _NETBSD_SOURCE,
which I think adequately covers this issue. Programs that define, say,
_POSIX_C_SOURCE=200809L will not have this exposed.
>Unformatted:
(Contact us)
$NetBSD: gnats-precook-prs,v 1.4 2018/12/21 14:20:20 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.