From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 7 May 2014 05:42:26 -0400 To: 9fans@9fans.net Message-ID: In-Reply-To: References: <20140507073809.62e1138e@zinc.9fans.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] [GSOC] plan9 which arch code to use? Topicbox-Message-UUID: e07dbdda-ead8-11e9-9d60-3106f5b1d025 !/bin/upas/marshal -s 'Re: [9fans] [GSOC] plan9 which arch code to use?' -R /mail/fs/mbox/1815 9fans@9fans.net > > On 7 May 2014 10:05, erik quanstrom wrote: > > > > > the comment is wrong. it's "int ainc(int*)" > > > > > > h% grep ainc /sys/include/libc.h > > long ainc(long*); > > > > h% grep ainc /n/sources/plan9/sys/include/libc.h > > long ainc(long*); > > shouldn't that be aincl? these definitions were added to > libc.h very late in the game (2013), and iirc, the only > place ainc was actually used was the 64-bit kernel, and > its definition was int ainc(int*). sent too soon. so this allows a reference count to be just an int. i also felt int ainc(int*) fit better with the other atom(2) functions, which have a suffix of 32, 64, l or p added when the argument is not an int. so what i did assumes that there could be an aincl, aincp, ainc32, ainc64, but there just isn't. the definition "long ainc(long*)" seems to assume there is only one ainc. and i can't see why the argument should be a long. that would make it 64-bits in an lp64 model, which may not be what was intended. - erik