Re: RFS: ustr (updated package)
Vaclav Ovsik <[EMAIL PROTECTED]> writes:
> I have setup gcc-4.3 from experimental on a sid xen guest.
> The warning is emitted for example on following (simplified) code:
>
> extern inline char func( int arg )
> {
> static const char foomap[4] = {2, 4, 8, 16};
>
> return foomap[arg & 3];
> }
Yes, from the link Bernd provided the warning is emitted basically
for anything that uses the static keyword. The above is correct
though, IMO, as is:
extern inline char func( int arg )
{
static const char foomap[] = "abc";
return foomap[arg & 3];
}
> I have red several times the ISO paragraph :). It seems to me, that
> paragraph applies to this situation.
> IMHO foomap is `reference to an identifier with internal linkage'.
> Or no? :)
From ISO 9899:1999 6.2.2 Linkages of identifiers:
#1
An identifier declared in different scopes or in the same scope more
than once can be made to refer to the same object or function by a
process called linkage. There are three kinds of linkage: external,
internal, and none.
#2
If the declaration of a file scope identifier for an object or a
function contains the storage-class specifier static, the identifier
has internal linkage.
[...]
#6
The following identifiers have no linkage: an identifier declared to
be anything other than an object or a function; an identifier declared
to be a function parameter; a block scope identifier for an object
declared without the storage-class specifier extern.
...from that #2 doesn't apply because the identifier isn't at file
scope, and so the last part of #6 does apply.
Also it's "well known" that in:
void foobar(void)
{
const char *const foo = "abcd";
static const char bar[] = "abcd";
}
...foo and bar do the same thing, point to some constant data, but bar
is the better version.
As with foo you have a allocated two objects (the pointer being the
second object), and have to use/manage them both, but with bar you
have just "named" a single object.
--
James Antill -- [EMAIL PROTECTED]
C String APIs use too much memory? ustr: length, ref count, size and
read-only/fixed. Ave. 44% overhead over strdup(), for 0-20B strings
http://www.and.org/ustr/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ustr (updated package)
Bernd Zeimetz <[EMAIL PROTECTED]> writes:
> James Antill wrote:
>> That code is basically:
>>
>> extern inline size_t ustr_xi__pow2(int use_big, unsigned char len)
>> {
>> static const unsigned char map_big_pow2[4] = {2, 4, 8, 16};
>> static const unsigned char map_pow2[4] = {0, 1, 2, 4};
>>
>> ...so I'm pretty sure it's correct as is, and the version of GCC
>> used is giving out false warnings.
>
> I doubt that.
> http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00182.html
From the above email:
This patch makes GCC's inline function support more like the C99
support. To be precise, it implements 6.7.4 paragraph 3
ISO 9899:1999, 6.7.4 paragraph 3 says:
An inline definition of a function with external linkage shall not
contain a definition of a modifiable object with static storage
duration, and shall not contain a reference to an identifier with
internal linkage.
...as both of the declarations are "static const", 6.7.4#3 doesn't
apply.
--
James Antill -- [EMAIL PROTECTED]
C String APIs use too much memory? ustr: length, ref count, size and
read-only/fixed. Ave. 44% overhead over strdup(), for 0-20B strings
http://www.and.org/ustr/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ustr (updated package)
Bernd Zeimetz <[EMAIL PROTECTED]> writes:
> V.ANaclav OvsNmk wrote:
>> Dear mentors,
>>
>> I am looking for a sponsor for the new version 1.0.2-1
>> of my package "ustr".
>
> I neither checked your package very carefully, nor am I a DD - but here
> are my comments:
Well I'm not trying to package it, just the upstream, but these look
like upstream issues so...
> - read http://www.debian.org/doc/debian-policy/ch-files.html#s-libraries
> again. On the first look it seems the library is not being build with
> -fPIC everywhere, also the static library (which is part of the -dev
> package) is using -fPIC on some places. You need to clean up after
> building the shared lib and build the static one (or the other way round...)
Hmm, I doubt Vaclav changed the Makefile and I'm pretty sure that
isn't the case in the upstream Makefile.
Note that it builds 4 versions of each file by default that look like:
*-so-dbg.o
*-so-opt.o
*-a-dbg.o
*-a-opt.o
...the first two are put into the shared libraries (and all should be
compiled with -FPIC), and the later two the static libraries.
If the debian build also does the make check phase, it'll also be
compiling a bunch of stuff like tst_*.o ... which are test cases that
link against the library, and so don't have -fPIC.
> Also the following warning appears pretty often:
> ustr-main.h:859: warning: .FN!map_big_pow2N" is static but declared in
> inline function .FN!ustr_xi__pow2N" which is not static
> ustr-main.h:860: warning: .FN!map_pow2N" is static but declared in inline
> function .FN!ustr_xi__pow2N" which is not static
> ustr-main.h:863: warning: .FN!map_big_pow2N" is static but used in inline
> function .FN!ustr_xi__pow2N" which is not static
> ustr-main.h:865: warning: .FN!map_pow2N" is static but used in inline
> function .FN!ustr_xi__pow2N" which is not static
>
> That sounds fixable.
That code is basically:
extern inline size_t ustr_xi__pow2(int use_big, unsigned char len)
{
static const unsigned char map_big_pow2[4] = {2, 4, 8, 16};
static const unsigned char map_pow2[4] = {0, 1, 2, 4};
...so I'm pretty sure it's correct as is, and the version of GCC
used is giving out false warnings.
--
James Antill -- [EMAIL PROTECTED]
"Please, no. Let's not pull in a dependency for something as simple as a
string library." -- Kristian H.ANxgsberg <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Request for sponsor: timer-q1 and socket-poll1
I'm in n the NM queue, and would like someone to sponsor my packages "timer-q1", "timer-q1--dev", "socket-poll1" and "socket-poll1-dev". Adding... deb-src ftp://ftp.and.org/debian/james_debs/ ./ ...to your sources.list will get the source. -- # James Antill -- [EMAIL PROTECTED] :0: * ^From: [EMAIL PROTECTED] /dev/null
Request for sponsor: timer-q1 and socket-poll1
I'm in n the NM queue, and would like someone to sponsor my packages "timer-q1", "timer-q1--dev", "socket-poll1" and "socket-poll1-dev". Adding... deb-src ftp://ftp.and.org/debian/james_debs/ ./ ...to your sources.list will get the source. -- # James Antill -- [EMAIL PROTECTED] :0: * ^From: .*james@and\.org /dev/null -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Q. about the way libc6 is packaged (looking for inspiration)
Josip Rodin <[EMAIL PROTECTED]> writes: > On Sat, Oct 14, 2000 at 01:57:40AM -0400, James Antill wrote: > > > > So I'm thinking about splitting into: > > > > > > > > libicu16: just the lib*.so.* > > > > icu: the rest, depends on libicu16. > > > > > > This is the correct way to do it. > > > > Doesn't this mean that you have to upgrade both packages if you need > > to change the *.so.* files in a binary incompatible manner. > > Even if it was only one package you'd have to upgrade it. True. [snip ...] > > Ie. wouldn't it be better to have something like... > > > > libicu: virtual package, requires icu and libicu16 > > > > ...or am I missing something. > > That's not how the virtual packages are used usually... note also that users > don't know much about virtual packages, since they don't see them in package > selection programs. Well I didn't really like dselect, so I've only really used gnome-apt and that shows the virtual packages. I'm also probably abusing the name virtual package, as I meant a package which just requires other packages (maybe has a README.debian in /usr/share/doc but still...). -- James Antill -- [EMAIL PROTECTED] "If we can't keep this sort of thing out of the kernel, we might as well pack it up and go run Solaris." -- Larry McVoy.
Re: Q. about the way libc6 is packaged (looking for inspiration)
Josip Rodin <[EMAIL PROTECTED]> writes: > On Sat, Oct 14, 2000 at 01:57:40AM -0400, James Antill wrote: > > > > So I'm thinking about splitting into: > > > > > > > > libicu16: just the lib*.so.* > > > > icu: the rest, depends on libicu16. > > > > > > This is the correct way to do it. > > > > Doesn't this mean that you have to upgrade both packages if you need > > to change the *.so.* files in a binary incompatible manner. > > Even if it was only one package you'd have to upgrade it. True. [snip ...] > > Ie. wouldn't it be better to have something like... > > > > libicu: virtual package, requires icu and libicu16 > > > > ...or am I missing something. > > That's not how the virtual packages are used usually... note also that users > don't know much about virtual packages, since they don't see them in package > selection programs. Well I didn't really like dselect, so I've only really used gnome-apt and that shows the virtual packages. I'm also probably abusing the name virtual package, as I meant a package which just requires other packages (maybe has a README.debian in /usr/share/doc but still...). -- James Antill -- [EMAIL PROTECTED] "If we can't keep this sort of thing out of the kernel, we might as well pack it up and go run Solaris." -- Larry McVoy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Q. about the way libc6 is packaged (looking for inspiration)
Josip Rodin <[EMAIL PROTECTED]> writes: > On Fri, Oct 13, 2000 at 03:26:17PM -0700, Yves Arrouye wrote: > > So I'm thinking about splitting into: > > > > libicu16: just the lib*.so.* > > icu: the rest, depends on libicu16. > > This is the correct way to do it. Doesn't this mean that you have to upgrade both packages if you need to change the *.so.* files in a binary incompatible manner. Ie. wouldn't it be better to have something like... libicu: virtual package, requires icu and libicu16 ...or am I missing something. -- James Antill -- [EMAIL PROTECTED] "If we can't keep this sort of thing out of the kernel, we might as well pack it up and go run Solaris." -- Larry McVoy.
Re: Q. about the way libc6 is packaged (looking for inspiration)
Josip Rodin <[EMAIL PROTECTED]> writes: > On Fri, Oct 13, 2000 at 03:26:17PM -0700, Yves Arrouye wrote: > > So I'm thinking about splitting into: > > > > libicu16: just the lib*.so.* > > icu: the rest, depends on libicu16. > > This is the correct way to do it. Doesn't this mean that you have to upgrade both packages if you need to change the *.so.* files in a binary incompatible manner. Ie. wouldn't it be better to have something like... libicu: virtual package, requires icu and libicu16 ...or am I missing something. -- James Antill -- [EMAIL PROTECTED] "If we can't keep this sort of thing out of the kernel, we might as well pack it up and go run Solaris." -- Larry McVoy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
