headers
Thad Stahl | 1 May 2010 01:11

Visiting nurses & rn's - 91,386 total records

Here's a business list package on sale this week only:

Business List Gold Package

Real Estate Agents - 1 million records with emails
US New Business Database - 4.8 million records all with emails
Manufacturers Database - 1,057,119 records with 476,509 emails

All complete lists above: $296

There are more packages and not just for business. we also have healthcare, consumers and more. Contact me
here for more info or to get samples: Tanner.Magee <at> qualitylists.co.cc

Send email to disappear <at> qualitylists.co.cc to ensure no further communication
Permalink | Reply | 0 comments |
headers
Kristaps Dzonsons | 3 May 2010 22:26
Picon

Google SoC, mandoc, and PostScript

Hello,

This mail introduces another GSoC project: adding postscript output to
mandoc ("mandoc -Tps"), http://mdocml.bsd.lv/.  My mentors are T Klauser
(wiz <at> ), J Sonnenberger (joerg <at> ), and D Baron (dillo <at> ).  A copy of the
proposal, edited for brevity, is included below.  It has details.  The
abstract follows:

 "mandoc -Tps is missing. While mandoc is fast becoming
  byte-compatible with GNU troff for terminal output (-Tascii)
  and has advanced X/HTML  output (-Thtml, -Txhtml), there does
  not yet exist PostScript output (-Tps). I propose implementing
  -Tps, initially as a shim over terminal output, then, with this
  milestone complete, bringing in more typographic awareness
  (variable-font, justification, etc.)."

The project will involve an initial implementation of the driver
(1,5/2,0 months), then focus on typography (1,5/1,0 months).  In my
experience, most of the first part will be spent hair-pulling regarding
lists (cf. mdoc_term.c, mdoc_html.c in mandoc).

If I finish ahead of time, I plan on adding -Tpdf, although this is
beyond the scope of GSoC.  I'll be calling upon Dieter's expertise to
pull this part off.

Prior to SoC, I'll add initial typographic cues, such as for sentential
spacing, which must occur before AST serialisation  This will relieve
front-ends of considerable complexity (see, e.g., the OpenBSD local
patches for EOS spacing).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nhat Minh Le | 14 May 2010 00:28

_DIAGASSERT(), noreturn attribute and static analysis

Hello,

I've been trying out the clang static analyzer, recently, and as it
is, NetBSD assert.h definitions don't play well with static
analysis. Basically, the analyzer always predicts the opposite of the
assertion predicate whenever it comes across an assert() or
_DIAGASSERT() call that is actually compiled (with NDEBUG undefined or
with _DIAGNOSTIC defined, respectively), which is pretty bad.

As far as NetBSD is concerned, it all boils down to the __assert(),
__assert13(), __diagassert() and __diagassert13() routines not being
declared __dead in assert.h. However, __diagassert() and
__diagassert13() are not dead, actually; but they ought to be
considered dead as far as analysis is concerned. LLVM has a special
attribute for that, it's called analyzer_noreturn.

The point of my post is: I think we should be nice to LLVM. :) (And
besides, having the static analyzer not spout loads of false positives
on NetBSD code without having to use an alternate system header would
be nice too!)

My suggestion is to either support analyzer_noreturn through
a #define, say __terminal in constrast to __dead, in sys/cdefs.h, the
same way we support other GCC-specific attributes, or conditionally
define __diagassert13() as __dead when, say, __lint__ is defined, and
have LLVM -D__lint__ when it does its analysis (which is actually not
quite straightforward, with their scripts as they are...).

The first solution would add something like this to sys/cdefs.h:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Valeriy E. Ushakov | 14 May 2010 02:32
Picon

Re: _DIAGASSERT(), noreturn attribute and static analysis

Nhat Minh Le <nhat.minh.le <at> huoc.org> wrote:

> I've been trying out the clang static analyzer, recently, and as it
> is, NetBSD assert.h definitions don't play well with static
> analysis. Basically, the analyzer always predicts the opposite of the
> assertion predicate whenever it comes across an assert() or
> _DIAGASSERT() call that is actually compiled (with NDEBUG undefined or
> with _DIAGNOSTIC defined, respectively), which is pretty bad.

Do you mean that for assert(foo != NULL); it predicts that
foo == NULL?  I'm not sure I understand the problem. 

> As far as NetBSD is concerned, it all boils down to the __assert(),
> __assert13(), __diagassert() and __diagassert13() routines not being
> declared __dead in assert.h. However, __diagassert() and
> __diagassert13() are not dead, actually; but they ought to be
> considered dead as far as analysis is concerned. LLVM has a special
> attribute for that, it's called analyzer_noreturn.
>
> The point of my post is: I think we should be nice to LLVM. :) (And
> besides, having the static analyzer not spout loads of false positives
> on NetBSD code without having to use an alternate system header would
> be nice too!)
> 
> My suggestion is to either support analyzer_noreturn through
> a #define, say __terminal in constrast to __dead, in sys/cdefs.h, the

__terminal is a very vague and so a very bad name.  I can't think of
something good, though __undead comes to mind :)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Nhat Minh Le | 14 May 2010 02:51

Re: _DIAGASSERT(), noreturn attribute and static analysis

At Fri, 14 May 2010 00:32:47 +0000 (UTC),
Valeriy E. Ushakov wrote:
> 
> Nhat Minh Le <nhat.minh.le <at> huoc.org> wrote:
> 
> > I've been trying out the clang static analyzer, recently, and as it
> > is, NetBSD assert.h definitions don't play well with static
> > analysis. Basically, the analyzer always predicts the opposite of the
> > assertion predicate whenever it comes across an assert() or
> > _DIAGASSERT() call that is actually compiled (with NDEBUG undefined or
> > with _DIAGNOSTIC defined, respectively), which is pretty bad.
> 
> Do you mean that for assert(foo != NULL); it predicts that
> foo == NULL?  I'm not sure I understand the problem. 

Sort of. Actually, from the outside (I haven't looked at the code),
I'm guessing it goes something like this:

1. The analyzer comes across an assert(foo != NULL) call, which gets
   expanded to something like:

        ((foo != NULL) ? (void)0 : __assert13(...))

2. Since the programmer has written a test for it, the analyzer
   assumes the condition *can* occur.

3. The analyzer sees that this conditional tests whether foo is NULL,
   and since it doesn't know that __assert13() doesn't return, it
   deduces that the branch might be taken and will fallthrough onto
   the rest of the code.
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Holland | 14 May 2010 04:51
Picon

Re: _DIAGASSERT(), noreturn attribute and static analysis

On Fri, May 14, 2010 at 02:51:29AM +0200, Nhat Minh Le wrote:
 > I see... the point was just that AFAIK, this little reasoning should
 > apply to about all static analyzers out there. Some may handle
 > assert() specially, but since _DIAGASSERT() is pretty much
 > NetBSD-specific, there's no chance they'll consider that. So it'd be
 > nice to be able to turn it on/off at will, somehow.

Well, they're all different; anyway, I'd expect that most of them,
including in the long run probably clang too, will want

   #define assert(x) __builtin_assert(x)

or similar, because the fact that the programmer is explicitly
asserting something is a highly useful piece of information.

--

-- 
David A. Holland
dholland <at> netbsd.org
Permalink | Reply | 0 comments |
headers
David Holland | 14 May 2010 08:15
Picon

Re: silly behavior of factor(6)

On Wed, Apr 28, 2010 at 08:16:09PM +0000, David Holland wrote:
 > [...] the whole point of this thread is to strike a balance between
 > what's strictly meaningful and what makes the most ad hoc sense.

Specifically, I see four criteria:

   1. The numbers printed, when multiplied together, should equal the
      input number.
   2. The numbers printed should be uniquely determined.
   3. The numbers printed should be prime except for special cases.
   4. The numbers printed should be prime in the strictest sense.

For numbers > 1 the behavior is clear. Otherwise the following
possibilities have been suggested:
   - for 1: print 1, print no factors, or error;
   - for 0: print 0, print no factors, error, or exit silently;
   - for negatives, insert -1 and factor the absolute value, or error.

Erroring on 1 does not make much sense; neither does exiting silently
or skipping to the next input (POLA); printing no factors for zero is
incorrect (violates the first criterion). This leaves these
possibilities:
   - for 1: print 1, or print no factors;
   - for 0: print 0, or error;
   - for negatives, insert -1 and factor the absolute value, or error.

For each of these, the first case satisfies the first three criteria
but not the fourth; the second case satisfies the fourth as well.
Therefore it seems that there are only two real possibilities here,
and the choice is whether to adopt the fourth criterion or relax it.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Martin Husemann | 14 May 2010 13:20
Picon

Re: _DIAGASSERT(), noreturn attribute and static analysis

On Fri, May 14, 2010 at 02:51:29AM +0200, Nhat Minh Le wrote:
> 4. Then the analyzer tries out every possible branching scenario up to
>    some depth and sees that if the __assert13() route is taken, then
>    foo == NULL and the next dereference is a bug.

This all sounds an analyzer bug to me - note that for example Coverity gets
it right.

Martin
Permalink | Reply | 0 comments |
headers
Thomas Klausner | 15 May 2010 12:39
Picon

vi: invalid conversion, truncated file

Hi!

When opening a file in vi in a UTF-8 environment, doing changes and
saving-and-quitting, I sometimes open files that are not valid UTF-8
files (e.g. iso-8859-1).

vi then claims "invalid conversion" and truncates the file at the
first invalid character.

I don't see how this can _ever_ be what the user wants (well, perhaps
sometimes, but not in >90% of the cases -- definitely not in 100% of
my usage cases).

Can we come up with a better handling of these files? For example, one
of:

. just skip the character(s), possibly replacing it with some special
  character sequence so it's obvious where a character was removed, and
  continue writing the rest
. not save, but go to the position so the user can decide what to do
. just leave the character alone and write the file as it was before

 Thomas
Permalink | Reply | 3 comments |
headers
Christopher Berardi | 15 May 2010 21:58

Re: silly behavior of factor(6)

On Fri, May 14, 2010 at 06:15:43AM +0000, David Holland wrote:
> Specifically, I see four criteria:
> 
>    1. The numbers printed, when multiplied together, should equal the
>       input number.
>    2. The numbers printed should be uniquely determined.
>    3. The numbers printed should be prime except for special cases.
>    4. The numbers printed should be prime in the strictest sense.
> 
> [...] This leaves these possibilities:
>    - for 1: print 1, or print no factors;
>    - for 0: print 0, or error;
>    - for negatives, insert -1 and factor the absolute value, or error.
> 
> For each of these, the first case satisfies the first three criteria
> but not the fourth; the second case satisfies the fourth as well.
> Therefore it seems that there are only two real possibilities here,
> and the choice is whether to adopt the fourth criterion or relax it.
> 

Perhaps I missed something in your analysis, but it seems like criterion 3 and 4
are somewhat mutually exclusive. For how can criterion 3 allow special cases if
those special cases would then violate criterion 4?

--

-- 
Christopher Berardi
http://www.natoufa.com/

Be still, and know that I am God (Psalms 46:10)
(Continue reading)

Permalink | Reply | 1 comment |

Gmane