From owner-freebsd-arch@FreeBSD.ORG Fri May 12 15:24:33 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0DD816A4DD for ; Fri, 12 May 2006 15:24:33 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id C241E43D6B for ; Fri, 12 May 2006 15:24:31 +0000 (GMT) (envelope-from keramida@FreeBSD.org) Received: from gothmog.pc (aris.bedc.ondsl.gr [62.103.39.226]) (authenticated bits=128) by igloo.linux.gr (8.13.6/8.13.6/Debian-1) with ESMTP id k4CFO9o8031374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 12 May 2006 18:24:11 +0300 Received: from gothmog.pc (gothmog [127.0.0.1]) by gothmog.pc (8.13.6/8.13.6) with ESMTP id k4CFQLv4025995 for ; Fri, 12 May 2006 18:26:21 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Received: (from giorgos@localhost) by gothmog.pc (8.13.6/8.13.6/Submit) id k4CFQLg7025994 for freebsd-arch@freebsd.org; Fri, 12 May 2006 18:26:21 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Date: Fri, 12 May 2006 18:26:21 +0300 From: Giorgos Keramidas To: freebsd-arch@FreeBSD.org Message-ID: <20060512152621.GC25843@gothmog.pc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.964, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.43, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: Subject: [docs/96207: Comments of a sockaddr_un structure could confuse one] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2006 15:24:38 -0000 This is not an `architectural' change per se, but I believe the subscribers of this list will be more experienced to answer to the following PR. What do you all think about it? ----- Forwarded message from Rostislav Krasny ----- Date: Sun, 23 Apr 2006 15:41:45 GMT From: Rostislav Krasny Subject: docs/96207: Comments of a sockaddr_un structure could confuse one To: freebsd-gnats-submit@freebsd.org >Number: 96207 >Category: docs >Synopsis: Comments of a sockaddr_un structure could confuse one >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Sun Apr 23 15:50:14 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Rostislav Krasny >Release: 6.1-RC >Organization: >Environment: FreeBSD saturn.lan 6.1-RC FreeBSD 6.1-RC #0: Sun Apr 23 15:36:02 IDT 2006 root@saturn.lan:/usr/obj/usr/src/sys/MYKERNEL i386 >Description: In RELENG_6 (and others) a sys/un.h has following definitions: /* * Definitions for UNIX IPC domain. */ struct sockaddr_un { unsigned char sun_len; /* sockaddr len including null */ sa_family_t sun_family; /* AF_UNIX */ char sun_path[104]; /* path name (gag) */ }; /* actual length of an initialized sockaddr_un */ #define SUN_LEN(su) \ (sizeof(*(su)) - sizeof((su)->sun_path) + strlen((su)->sun_path)) Comments of the sockaddr_un definition, together with the SUN_LEN(su) definition, could confuse one. For example my first thought was that there is a bug in the SUN_LEN(su) definition. About 9 years ago the same confusion happened in the NetBSD project. Read a "SUN_LEN() definition change" thread: http://mail-index.netbsd.org/tech-kern/1997/02/ and commit logs of revisions 1.14 and 1.15: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/un.h Back to FreeBSD, I think the "/* sockaddr len including null */" should be changed to "/* sockaddr_un len without NUL */" and the "/* path name (gag) */" should be changed to "/* NUL-terminated path name */". The unix(4) manual page already gives the right information about that. >How-To-Repeat: >Fix: Already in the description >Release-Note: >Audit-Trail: >Unformatted: ----- End forwarded message -----