Date: Fri, 5 May 2017 12:46:01 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Bruce Evans <brde@optusnet.com.au> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r317809 - head/share/man/man7 Message-ID: <20170505094601.GW1622@kib.kiev.ua> In-Reply-To: <20170505174957.B875@besplex.bde.org> References: <201705042131.v44LVokb076951@repo.freebsd.org> <20170505174957.B875@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 05, 2017 at 07:13:04PM +1000, Bruce Evans wrote: > On Thu, 4 May 2017, Konstantin Belousov wrote: > uintptr_t and size_t are are not synonyms for unsigned long on all arches. > They only have the same respresentation on 32-bit arches. On 32-bit arches, > they are synonyms for unsigned int, and thus have a lower rank than > unsigned long. This mainly causes problems printing them, but might cause > sign extension/overblow problems. For example, (size_t)0 + (long)-1 is > unsigned and large positive on 64-bit arches, but signed and small negative > on 32-bit arches. Ok. For now, for the commit of articles fixes, I changed this to note that uintptr_t has same size as ulong. I might revisit this part of text after the trivial fixes are done. > > > +.Pp > > +In order to maximize compatibility with future pointer integrity mechanisms, > > "pointer integrity mechanisms" sounds like management/marketingspeak. > "integrity" isn't a relevant property of integer types. "mechanism" might > mean the details of the representation (more than the size), but I think > you just mean the size. Most manipulations of pointers as integers > assume the same representation. You stated that the representation is > the same [in future] above, and didn't use the usual caveat "on all > supported arches". I don't like this, but lots of code depends on it. AFAIU, cheri is somewhat like Intel MPX, but more. I do not know fine details. For MPX, pointers are no longer plain pointers, there is a data behind the raw value, providing e.g. the range of bytes which are valid to dereference through the authentic value of the pointer and arithmetic manipulations of it. So the phrase is correct, and the below reformulation really removes the content. > > Translation of the above: "... compatibility with changes in the size of > pointers in future implementations". > > > +Compilers define > > +.Dv _LP64 > > +symbol when compiling for an > > +.Dv LP64 > > +ABI. > > Further minor grammar problems here and elsewhere: > - missing "the" before _LP64 > - "an" is confusing. First, "a" might be correct depending on how you > pronounce LP64. I pronounce it as "el ...", so "an" is better than > "a". But there is only 1 LP64, so "the" is more correct. "the LP64 > ABI" is confusing too. LP64 isn't an ABI or a collection of ABIs. > The collection is of arches, many using a single LP64 sub-ABI with > variations in other parts of their ABI. Of course there are architectures which have more that one LP64 ABI, eg. PowerPC ELF v1 and v2. Even i386, de facto, have two incompatible ABIs now: one older SysVR4 ABI where stack is 4-bytes aligned, and modern Linux ABI which claims that stack must be 16-bytes aligned, as enforced by modern gcc. The variation is not minor, it causes reliable user pain when mixed in. > > +Integers are represented as two-complement. > > +Alignment of integer and pointer types is natural, that is, > > +the address of the variable must be congruent to zero modulo type size. > > Missing "the" after "modulo". > > Is it natural for arm? arm has unnatural struct padding, at least at > the end of structs. I am not sure what exactly you mean about unnatural struct padding, AFAIR ARM has the same rule of structure having the alignment requirement of the most aligned member. ARMv7 has a requirement of uint64_t having 8-bytes alignment (unlike other 32bit platforms). Might be, indeed, this should be more accurate, but in fact ARM is correct for this sentence. Below are the small corrections. diff --git a/share/man/man7/arch.7 b/share/man/man7/arch.7 index 2add6ea3d3e..1c056849861 100644 --- a/share/man/man7/arch.7 +++ b/share/man/man7/arch.7 @@ -39,13 +39,13 @@ Differences between CPU architectures and platforms supported by If not explicitly mentioned, sizes are in bytes. .Pp FreeBSD uses flat address space for program execution, where -pointers have the same binary representation as +pointers have the same representation as .Vt unsigned long variables, and .Vt uintptr_t and .Vt size_t -types are synonyms for +types have same size as .Vt unsigned long . .Pp In order to maximize compatibility with future pointer integrity mechanisms, @@ -93,7 +93,7 @@ and .Vt void * are 8 bytes. .El -Compilers define +Compilers define the .Dv _LP64 symbol when compiling for an .Dv LP64 @@ -108,7 +108,7 @@ execution environment is accompanied by the .Dv ILP32 environment, which was historical 32-bit predecessor for 64-bit evolution. Examples are: -.Bl -column -offset indent "powerpc64" "Sy ILP32 counterpart" +.Bl -column -offset indent "Dv powerpc64" "Sy ILP32 counterpart" .It Sy LP64 Ta Sy ILP32 counterpart .It Dv amd64 Ta Dv i386 .It Dv powerpc64 Ta Dv powerpc @@ -133,7 +133,7 @@ On all supported architectures: .El Integers are represented as two-complement. Alignment of integer and pointer types is natural, that is, -the address of the variable must be congruent to zero modulo type size. +the address of the variable must be congruent to zero modulo the type size. .Pp Machine-dependent type sizes: .Bl -column -offset indent "Sy Architecture" "Sy void *" "Sy long double" "Sy time_t"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170505094601.GW1622>