Lloyd Zusman | 7 Jun 2011 11:40

[skalibs] Why no negative numbers in the *_fmt routines?

I want to use skalibs to support some software that I'm writing,
instead of the standard unix libraries. This is generally working
well and resulting in smaller, more efficient binaries, but I
have come across one issue that is giving me some difficulties:
the integer-based *_fmt routines do not format negative numbers.

It seems that this is due to the fact that this group of *_fmt
routines are all built on top of uint64_fmt_base(), which only
knows about unsigned positive values. This makes sense for
routines like uint_fmt() and ulong_fmt(), but it is causes problems
when passing perfectly valid integers and longs to int_fmt() and
long_fmt(), when these valid values happen to be less than zero.

Of course, I know how to work around this, but it seems like the
most efficient solution to this problem would be for skalibs to
handle negative values at the lowest level, perhaps through a new
int64_fmt_base() routine that would underlie int_fmt(), long_fmt(),
etc.

Is there any reason for why such a routine should not be written,
so that fmtscan.h could use it to build the macros for all the
signed-value routines such as int_fmt() and long_fmt()?

If no one has any objections, I'd be happy to write a patch to
skalibs which provides this functionality.

Thoughts?

Thanks.

(Continue reading)

Lloyd Zusman | 7 Jun 2011 13:55

Re: [skalibs] Why no negative numbers in the *_fmt routines?

Lloyd Zusman <ljz <at> asfast.com> writes:

> I want to use skalibs to support some software that I'm writing,
> instead of the standard unix libraries. This is generally working
> well and resulting in smaller, more efficient binaries, but I
> have come across one issue that is giving me some difficulties:
> the integer-based *_fmt routines do not format negative numbers.

I'm sorry. I missed long_fmt.c and I misread fmtscan.h. I was getting
errors with negative numbers, and I mistakenly thought that this was
due to int_fmt failing with values < 0.

Sorry for all these mistakes and for the bandwidth.

--

-- 
 Lloyd Zusman
 ljz <at> asfast.com
 God bless you.

Lloyd Zusman | 7 Jun 2011 14:08

[skalibs] long_fmt fails with FMT_LEN (was: Why no negative numbers in the *_fmt routines?)

Lloyd Zusman <ljz <at> asfast.com> writes:

> Lloyd Zusman <ljz <at> asfast.com> writes:
> 
> > [ ... ]
> > the integer-based *_fmt routines do not format negative numbers.
> 
> I'm sorry. I missed long_fmt.c and I misread fmtscan.h. I was getting
> errors with negative numbers, and I mistakenly thought that this was
> due to int_fmt failing with values < 0.

Actually, this problem is due to a bug in long_fmt. It doesn't properly
handle the FMT_LEN argument when the value to be formatted is negative.
This is evident in the source code:

unsigned int long_fmt (char *fmt, long n)
{
  if (n >= 0) return ulong_fmt(fmt, n) ;
  *fmt++ = '-' ;
  return 1 + ulong_fmt(fmt, -n) ;
}

This should be changed as follows:

unsigned int long_fmt (char *fmt, long n)
{
  if (n >= 0) return ulong_fmt(fmt, n) ;
  if (fmt != 0) *fmt++ = '-' ;
  return 1 + ulong_fmt(fmt, -n) ;
}
(Continue reading)

Laurent Bercot | 7 Jun 2011 15:52
Favicon

Re: [skalibs] long_fmt fails with FMT_LEN (was: Why no negative numbers in the *_fmt routines?)

 Hi Lloyd,
 The skaware <at> list.skarnet.org list is the place to talk about skalibs...
it doesn't have much to do with supervision ;)
 Mail-Followup-To set.

> Actually, this problem is due to a bug in long_fmt. It doesn't properly
> handle the FMT_LEN argument when the value to be formatted is negative.

 Ah, the null buffer trick. Sorry, I hardly ever use either negative
numbers or null buffers, so I'm not surprised that case isn't handled. ^^'
 Thanks for the patch, applied.

 skalibs-1.0.0, with lot of fixes and new goodies, is going to be released
Real Soon Now (with incomplete documentation, but at this pace, completing
the doc would mean blasting the release date into the next century, so
complete doc will have to wait). RSN means in less than a month (really,
I swear, on my life, etc.), so I'd advise you to wait for it if you can.

 If you don't trust me when it comes to release dates (and I haven't exactly
been trustworthy about that), I can send you a pre tarball. It works, and
it's definitely better than the old 0.47 stuff you're stuck with for now.

--

-- 
 Laurent

Lloyd Zusman | 8 Jun 2011 02:13

Re: [skalibs] long_fmt fails with FMT_LEN (was: Why no negative numbers in the *_fmt routines?)

Laurent Bercot <ska-supervision <at> skarnet.org> writes:

> 
>  Hi Lloyd,
>  The skaware <at> list.skarnet.org list is the place to talk about skalibs...
> it doesn't have much to do with supervision ;)

I'll go to that mailing list. The only reason I went here is because
this newsgroup is specifically mentioned on the skarnet "Mailing-lists"
web page, and it's very easy for me to access this site ... and I'm
lazy. :)

>  Thanks for the patch, applied.

Thank you!

>  If you don't trust me when it comes to release dates (and I haven't exactly
> been trustworthy about that), I can send you a pre tarball. It works, and
> it's definitely better than the old 0.47 stuff you're stuck with for now.

No rush. I'll patiently wait for the new release, which I'm _sure_ will
arrive within the month.

I'll head over to the other mailing list from now on.

--

-- 
 Lloyd Zusman
 ljz <at> asfast.com
 God bless you.

(Continue reading)

Lloyd Zusman | 11 Jun 2011 15:31

[skalibs] Can't post on the skaware mailing list (was: long_fmt fails with FMT_LEN)

Laurent Bercot <ska-supervision <at> skarnet.org> writes:

> 
>  Hi Lloyd,
>  The skaware <at> list.skarnet.org list is the place to talk about skalibs...
> it doesn't have much to do with supervision ;)
>  Mail-Followup-To set.

I'm sorry to post again to this group, but I have encountered a problem
with the skaware <at> list.skarnet.org mailing list.

Yesterday, I subscribed to that list, and I received a "WELCOME" message
which told me that my subscription was successfully processed.

Today, I tried to post a message to skaware <at> list.skarnet.org from my
subscription email address. Unfortunately, I received an auto-response
which tells me, among other things, "Your request could not be processed
because the command you sent was not understood."

One of the things this auto-response mentions is that I can send commands
such as "lists" to the listserver (requests <at> list.pageplanetsoftware.com).
I did just that, and I received the following response: "The list of
available lists is not available."

So is there a problem with the skaware mailing list? If so, should I just
be patient and try posting again a little later? Or could I be doing
something wrong?

Thanks.

(Continue reading)

Laurent Bercot | 11 Jun 2011 17:37
Favicon

Re: [skalibs] Can't post on the skaware mailing list (was: long_fmt fails with FMT_LEN)

> I'm sorry to post again to this group, but I have encountered a problem
> with the skaware <at> list.skarnet.org mailing list.

 You can write to me directly: ska-skaware <at> skarnet.org.

> One of the things this auto-response mentions is that I can send commands
> such as "lists" to the listserver (requests <at> list.pageplanetsoftware.com).

 pageplanetsoftware.com ? Wow. That is not at all the skaware list server.
 Either you mistook something else for the skaware welcome message, or
I've been hacked, or something weird happened. I'll investigate and keep
you informed.

--

-- 
 Laurent

Robin Bowes | 13 Jun 2011 15:01
Favicon

Re: Problems Compiling with glibc 2.12.1

On 02/06/2011 11:12 PM, Lasse Kliemann wrote:
> This is with Glibc 2.13. Somewhat older Glibc versions work
> alright, for instance 2.11.2. As a workaround (or fix), I changed
> src/conf-ld to call "gcc" and not "gcc -s".

I'm seeing the same problem in NexentaStor (based on OpenSolaris).

Partial output from package/install:
...
./load runit unix.a byte.a -static
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
make: *** [runit] Error 1

Contents of compile/sysdeps:

sunos-5.11-nexentaos_134f-:i386-:i86pc-:genuineintel-000206c2-bfebfbff-:i86pc-
#!/bin/sh
# WARNING: This file was auto-generated. Do not edit!
exec gcc -O2 -Wall -c ${1+"$ <at> "}
#!/bin/sh
# WARNING: This file was auto-generated. Do not edit!
main="$1"; shift
exec gcc -s -o "$main" "$main".o ${1+"$ <at> "}
-lxnet
/* sysdep: +dirent */
/* sysdep: +waitpid */
/* sysdep: +sigaction */
/* sysdep: +sigprocmask */
/* sysdep: +sysselect */
(Continue reading)

Laurent Bercot | 13 Jun 2011 15:38
Favicon

Re: Problems Compiling with glibc 2.12.1

> ./load runit unix.a byte.a -static

 My nose is tingling.

> Anyone got any ideas how I can get runit built on NexentaStor/OpenSolaris ?

 What if you remove the -static from the Makefile ?
 The runit and runit-init binaries are always linked statically, in order
to avoid runtime libc dependencies; but maybe your gcc doesn't understand
-static when it's there on the command line, or your system simply does
not provide a static version of the libc. (Which would suck, but hey,
it's Solaris-based.)

--

-- 
 Laurent

Robin Bowes | 13 Jun 2011 19:19
Favicon

Re: Problems Compiling with glibc 2.12.1

On 06/13/2011 02:38 PM, Laurent Bercot wrote:
>> ./load runit unix.a byte.a -static
>
>   My nose is tingling.
>
>
>> Anyone got any ideas how I can get runit built on NexentaStor/OpenSolaris ?
>
>   What if you remove the -static from the Makefile ?
>   The runit and runit-init binaries are always linked statically, in order
> to avoid runtime libc dependencies; but maybe your gcc doesn't understand
> -static when it's there on the command line, or your system simply does
> not provide a static version of the libc. (Which would suck, but hey,
> it's Solaris-based.)

Removing -static from the Makefile worked. I even added back the "-s" in 
src/conf-ld.

I just did this before running package/install:

perl -pi -e 's/-static//' src/Makefile

which removes -static from the following two lines

runit: load runit.o unix.a byte.a
         ./load runit unix.a byte.a -static

runit-init: load runit-init.o unix.a byte.a
         ./load runit-init unix.a byte.a -static

(Continue reading)


Gmane