«

On 26 Aug 2005 12:59:15 GMT, (Michael Wojcik)
wrote:

>
>In article <dekq2u$prp$>, Christopher Benson-Manica <> writes:
>> Default User <> wrote:
>>
>> > I think it's dumb to [set followups].
>> > I find it rude and obnoxious.
>>
>> For that I humbly apologize; consider the lesson learned.
>
>What lesson? That Brian doesn't like the Followup-To header? I
>wouldn't recommend tailoring your posting habits solely to his
>preferences. Setting Followup-To on crossposted messages is
>recommended by a number of netiquette guides and Son-of-1036. Some
>people dislike it; other people - some of whom felt sufficiently
>animated by the subject to formalize their thoughts in usage guides -
>do not.
>
>My inclination, frankly, is to follow the recommendations of the
>group which can be bothered to promulgate guidelines, over the
>complaints of those who can't be bothered to do more than complain.
>Sometimes there are good reasons (a clear majority of opinion or
>well-established practice in a given group, for example) for
>observing other conventions, but I don't see any of those here. What
>I see is one poster (well, two, since I've seen Alan chime in as well)
>complaining about a widely-recommended practice.

It's really very simple. If one doesn't want discussion in a
newsgroup, don't post to it.

That's my guideline, hereby promulgated. Complain if you like.
--
Al Balmer
Balmer Consulting

In article <>, Alan Balmer <> writes:
> On 26 Aug 2005 12:59:15 GMT, (Michael Wojcik)
> wrote:
>
> >What
> >I see is one poster (well, two, since I've seen Alan chime in as well)
> >complaining about a widely-recommended practice.
>
> It's really very simple. If one doesn't want discussion in a
> newsgroup, don't post to it.
>
> That's my guideline, hereby promulgated.

Posting it hardly constitutes promulgation. When you include it in a
serious, substantial discussion of netiquette, made available as a
separate document, and preferably submitted to a standards mechanism
(say, as an Internet-Draft), then I'll consider it promulgated.
Promulgation must mean something other than "writing in public", or
why have the term at all?

There's a difference between, on the one hand, taking the time to
consider the nature of discourse in a medium, developing from that
theories of how best to use that medium, formulating those theories
as claims about best practices, constructing arguments in favor of
those practices, setting the lot down in a durable public document,
and submitting it for review; and on the other tossing out some
statement of preference in a note dashed off in a few seconds in some
conversation on a newsgroup where the question isn't even topical.

For me, that's a significant difference. For others, no doubt, it
is not; but it suffices for me to justify, to myself, disregarding
complaints about, say, cross-posting and followup-to when those
features are used in a manner that accords with most promulgated
guidelines.

> Complain if you like.

I don't, particularly, since I don't really care what guidelines
people toss out in Usenet postings. What I do care about are the
ones that are arrived at by serious consideration and presented
with substantial justification.

Of course, that doesn't mean that there should be no discussion
of the question - quite the opposite, since it informs those who
might go on to produce the latter sort of guideline.

Tangentially, I might note that the reason I originally replied to
Christopher's post was that I feared he might believe that Brian's
opinion represented a consensus. It does not. (Should Christopher
choose to shape his behavior to it anyway, that's his business.)

--
Michael Wojcik

How can I sing with love in my bosom?
Unclean, immature and unseasonable salmon. -- Basil Bunting

Walter Roberson wrote:
> It seems to me that you are implying that the maximum
> object size that a C implementation may support, is only
> half of the memory addressible in that address mode --

No, I was saying that *if* a C implementation doesn't
support some integer type with more bits than are needed
to represent an address, *and if* the compiler supports
objects larger than half the available address space,
*then* then the definition of ptrdiff_t becomes
problematic. Note all the conditions..

> The machines I use most often -happen- to have that property
> anyhow, because the high-bit on a pointer is reserved for
> indicating kernel memory space, but I wonder about the extent
> to which this is true on other machines?

Now that 64-bit integer support is required for C
conformance, there should be a suitable ptrdiff_t type
available except on systems that support processes with
data sizes greater than 2^63 bytes. I don't know of
many systems like that..

Antoine Leca wrote:
> The straightforward idea (using strstr() in a loop and returning the last
> not-NULL answer, as strrchr() usually does) won't be a good one?

Well, it won't be optimal, since it searches the entire string
even when a match could have been found immediately if the
scan progressed from the end of the string. Finding the end
of the string initially has relatively high overhead, alas,
due to the representation of C strings. It isn't immediately
obvious just what the trade-off is between starting at the end
and scanning backward vs. the algoritm you suggested. Probably,
unless strrstr() is a bottleneck in the app, what you suggested
will be good enough.

> At least it would take profit from the optimized form of strstr()

Yes, that is useful.

What I was actually concerned about was that people might
implement the naive "brute-force" method of attempting matches
at each incremental (decremental?) position, which is okay for
occasional use but certainly not nearly the fastest method.

> (several people reported here that the shipped strstr()'s
> regularly outperform crafted algorithms like Boyer-Moore.)

I compared various algorithms in the book to which I referred.

> Not that I see any use for strrstr(), except perhaps to do the same as
> strrchr() when c happens to be a multibyte character in a stateless
> encoding.

Even then it's problematic, because the search would not respect
alignment with boundaries between character encodings.

Keith Thompson wrote:
> I don't think anyone has posted the real reason: it's arbitrary. The
> C standard library isn't a coherently designed entity. It's a
> collection of functionality from historical implementations,
> consisting largely of whatever seemed like a good idea at the time,
> filtered through the standards committee. ...

That is far from arbitrary. The evolution of C library
functions was substantially influenced by the demands of
practical programming, and many of the interfaces went
through several iterations in the early years of C, as
deficiencies in earlier versions were identified. The C
standards committee quite reasonably chose to standardize
existing interfaces rather than try to design totally new
ones. Many of the standard interfaces are not at all
what we would come up with in a new design.

Michael Wojcik wrote:


> Tangentially, I might note that the reason I originally replied to
> Christopher's post was that I feared he might believe that Brian's
> opinion represented a consensus. It does not. (Should Christopher
> choose to shape his behavior to it anyway, that's his business.)

You have no idea whether it represents a consensus or not. A
"consensus" is not necessarily complete unanimity.



Brian

Keith Thompson wrote:
> Christopher Benson-Manica <> writes:
> > strchr() is to strrchr() as strstr() is to strrstr(), but strrstr()
> > isn't part of the standard. Why not?
>
> I don't think anyone has posted the real reason: it's arbitrary. The
> C standard library isn't a coherently designed entity. It's a
> collection of functionality from historical implementations,
> consisting largely of whatever seemed like a good idea at the time,
> filtered through the standards committee. Just look at the continuing
> existence of gets(), or the design of <time.h>.
>
> It's remarkable (and a tribute to the original authors and to the
> committee) that the whole thing works as well as it does.

When you look at the world through rose color glasses ...

Remember that almost every virus, buffer overflow exploit, core
dump/GPF/etc is basically due to some undefined situation in the ANSI C
standard. I consider the ANSI C standard committee basically coauthors
of every one of these problems.

---
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

wrote
(in article
< om>):

> Keith Thompson wrote:
>> Christopher Benson-Manica <> writes:
>>> strchr() is to strrchr() as strstr() is to strrstr(), but strrstr()
>>> isn't part of the standard. Why not?
>>
>> I don't think anyone has posted the real reason: it's arbitrary. The
>> C standard library isn't a coherently designed entity. It's a
>> collection of functionality from historical implementations,
>> consisting largely of whatever seemed like a good idea at the time,
>> filtered through the standards committee. Just look at the continuing
>> existence of gets(), or the design of <time.h>.
>>
>> It's remarkable (and a tribute to the original authors and to the
>> committee) that the whole thing works as well as it does.
>
> When you look at the world through rose color glasses ...

Well, at least some seem to have their eyes fully open.

> Remember that almost every virus, buffer overflow exploit, core
> dump/GPF/etc is basically due to some undefined situation in the ANSI C
> standard.

Not really. Those that defined early C, and later standard C
are not responsible for bad programming. If a programmer has
access to the standard (which they do), and they decide to do
something which 'invokes undefined behavior', then it is their
fault. The standard says do not do that, and they did it
anyway.

> I consider the ANSI C standard committee basically coauthors
> of every one of these problems.

I couldn't disagree more. If programmers themselves were held
responsible for their mistakes, instead of trying to blame it on
loopholes or missing words in a huge document, we would be much
better off. If you could be fined or perhaps even jailed for
gross neglicence in software development the way doctors can be
today, I suspect the problem would be all but nonexistent.


--
Randy Howard (2reply remove FOOBAR)

Randy Howard wrote:
> wrote:
> > Keith Thompson wrote:
> >> Christopher Benson-Manica <> writes:
> >>> strchr() is to strrchr() as strstr() is to strrstr(), but strrstr()
> >>> isn't part of the standard. Why not?
> >>
> >> I don't think anyone has posted the real reason: it's arbitrary. The
> >> C standard library isn't a coherently designed entity. It's a
> >> collection of functionality from historical implementations,
> >> consisting largely of whatever seemed like a good idea at the time,
> >> filtered through the standards committee. Just look at the continuing
> >> existence of gets(), or the design of <time.h>.
> >>
> >> It's remarkable (and a tribute to the original authors and to the
> >> committee) that the whole thing works as well as it does.
> >
> > When you look at the world through rose color glasses ...
>
> Well, at least some seem to have their eyes fully open.
>
> > Remember that almost every virus, buffer overflow exploit, core
> > dump/GPF/etc is basically due to some undefined situation in the ANSI C
> > standard.
>
> Not really. Those that defined early C, and later standard C
> are not responsible for bad programming.

Bad programming + good programming language does not allow for buffer
overflow exploits. You still need a bad programming language to
facilitate the manifestation of these worst case scenarios.

> [...] If a programmer has access to the standard (which they
> do), and they decide to do something which 'invokes undefined
> behavior', then it is their fault. The standard says do not
> do that, and they did it anyway.

Ok, this is what I was talking about when I mentioned rose colored
glasses. If programmers are perfect, then what you are saying is fine,
because you can expect perfection. But real people are not. And I
think expectations of perfection in programming is really nonsensical.

Remember NASA put a priority inversion (a truly nasty bug to deal with)
in the mars pathfinder. The Arianne rocket blew up because of an
overflow triggering an interrupt handler that was faulty. You think
the programmers for these projects were not trying their best to do a
good job? Perfect programmers/programming is a pipedream. There is a
reason we paint lines on the roads, wear seatbelts, put guardrails on
stairs and bridges.

The problem of programmer safety can be attacked quite successfully at
the level of the programming language itself. There isn't actually a
downside to removing gets() and deprecating strtok and strnc??. (Hint:
Legacy code uses legacy compilers.)

> > I consider the ANSI C standard committee basically coauthors
> > of every one of these problems.
>
> I couldn't disagree more. If programmers themselves were held
> responsible for their mistakes, instead of trying to blame it on
> loopholes or missing words in a huge document, we would be much
> better off.

And what if its not the programmer's fault? What if the programmer is
being worked to death? What if he's in a dispute with someone else
about how something should be done and lost the argument and was forced
to do things badly?

> [...] If you could be fined or perhaps even jailed for
> gross neglicence in software development the way doctors can be
> today, I suspect the problem would be all but nonexistent.

Ok, that's just vindictive nonsense. Programmers are generally not
aware of the liability of their mistakes. And mistakes are not
completely removable -- and there's a real question as to whether the
rate can even be reduced.

But if you were to truly enforce such an idea, I believe both C and C++
as programming languages would instantly disappear. Nobody in their
right mind, other than the most irresponsible daredevils would program
in these langauges if they were held liable for their mistakes.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

wrote
(in article
<. com>):

>>> Remember that almost every virus, buffer overflow exploit, core
>>> dump/GPF/etc is basically due to some undefined situation in the ANSI C
>>> standard.
>>
>> Not really. Those that defined early C, and later standard C
>> are not responsible for bad programming.
>
> Bad programming + good programming language does not allow for buffer
> overflow exploits.

For suitably high-level languages that might be true (and
provable). Let us not forget that C is *not* a high-level
language. It's not an accident that it is called high-level
assembler.

I'd love for you to explain to us, by way of example, how you
could guarantee that assembly programmers can not be allowed to
code in a way that allows buffer overflows.

> You still need a bad programming language to
> facilitate the manifestation of these worst case scenarios.

If you wish to argue that low-level languages are 'bad', I will
have to disagree. If you want to argue that too many people
write code in C when their skill level is more appropriate to a
language with more seatbelts, I won't disagree. The trick is
deciding who gets to make the rules.

>> [...] If a programmer has access to the standard (which they
>> do), and they decide to do something which 'invokes undefined
>> behavior', then it is their fault. The standard says do not
>> do that, and they did it anyway.
>
> Ok, this is what I was talking about when I mentioned rose colored
> glasses. If programmers are perfect, then what you are saying is fine,
> because you can expect perfection. But real people are not. And I
> think expectations of perfection in programming is really nonsensical.

/Exactly/ Expecting zero buffer overruns is nonsensical.

> Remember NASA put a priority inversion (a truly nasty bug to deal with)
> in the mars pathfinder. The Arianne rocket blew up because of an
> overflow triggering an interrupt handler that was faulty. You think
> the programmers for these projects were not trying their best to do a
> good job?

No, I do not. I expect things to go wrong, because humans are
not infallible. Especially in something as inherently difficult
as space travel. It's not like you can test it (for real)
before you try it for all the marbles. You can't just hire an
army of monkey to sit in a lab beating on the keyboarrd all day
like an application company.

Anyway, a language so restrictive as to guarantee that nothing
can go wrong will probably never be used for any real-world
project.

> Perfect programmers/programming is a pipedream.

So is the idea of a 'perfect language'.

> There is a
> reason we paint lines on the roads, wear seatbelts, put guardrails on
> stairs and bridges.

Yes. And we require licenses for dangerous activities
elsewhere, but anyone can pick up a compiler and start playing
around.

> The problem of programmer safety can be attacked quite successfully at
> the level of the programming language itself.

It's quite easy to simply make the use of gets() and friends
illegal for your code development. Most of us have already done
so, without a standard body telling us to do it.

> There isn't actually a downside to removing gets() and deprecating
> strtok and strnc??. (Hint: Legacy code uses legacy compilers.)

Hint: Legacy code doesn't have to stay on the original platform.
Even so, anyone dusting off an old program that doesn't go
sifting through looking for the usual suspects is a fool.

I don't have a problem with taking gets() out of modern
compilers, but as you already pointed out, this doesn't
guarantee anything. People can still fire up an old compiler
and use it. I don't see a realistic way for the C standard to
enforce such things.

>>> I consider the ANSI C standard committee basically coauthors
>>> of every one of these problems.
>>
>> I couldn't disagree more. If programmers themselves were held
>> responsible for their mistakes, instead of trying to blame it on
>> loopholes or missing words in a huge document, we would be much
>> better off.
>
> And what if its not the programmer's fault?

It is the fault of the development team, comprised of whoever
that involves for a given project. If the programmer feels like
his boss screwed him over, let him refuse to continue, swear out
an affidavit and have it notarized the bad software was
knowingly shipped, and that you refuse to endorse it.

> What if the programmer is being worked to death?

That would be interesting, because although I have worked way
more than my fair share of 120 hour weeks, I never died, and
never heard of anyone dying. I have heard of a few losing it
and checking themselves into psycho wards, but still. If you
are being overworked, you can either keep doing it, or you can
quit, or you can convince your boss to lighten up. ESPECIALLY
in this case, the C standard folks are not to blame.

> What if he's in a dispute with someone else
> about how something should be done and lost the argument and
> was forced to do things badly?

Try and force me to write something in a way that I know is
wrong. Go ahead, it'll be a short argument, because I will
resign first.

Try and force a brain surgeon to operate on your head with a
chainsaw. good luck.

>> [...] If you could be fined or perhaps even jailed for
>> gross neglicence in software development the way doctors can be
>> today, I suspect the problem would be all but nonexistent.
>
> Ok, that's just vindictive nonsense.

Why? We expect architects, doctors, lawyers, pretty much all
other real 'professions' to meet and typically exceed a higher
standard, and those that do not are punished, fined, or stripped
of their license to practice in the field. Why should
programmers get a pass? Is it because you do not feel it is a
professional position?

We don't let anyone that wants to prescribe medicine, why should
we let anyone that wants to put software up for download which
could compromise system security?

> Programmers are generally not aware of the liability of
> their mistakes.

Then those you refer to must be generally incompetent. Those
that are good certainly are aware, especially when the software
is of a critical nature.

> And mistakes are not completely removable --

Correct. It's also not possible to completely remove medical
malpractice, but it gets punished anyway. It's called a
deterrent.

> and there's a real question as to whether the rate can even be reduced.

As long as there is no risk of failure, it almost certainly will
not be reduced by magic or wishing.

> But if you were to truly enforce such an idea, I believe both C and C++
> as programming languages would instantly disappear.

I highly doubt that. Low-level language programmers would be
the cream of the crop, not 'the lowest bidder' as is the case
today. You would not be hired to work based upon price, but on
skill. Much as I would go look for the most expensive attorney
I could find if I was on trial, I would look for the most highly
skilled programmers I could find to work on a nuclear reactor.

Taking bids and outsourcing to some sweatshop in a jungle
somewhere would not be on the list of options.

> Nobody in their right mind, other than the most irresponsible
> daredevils would program in these langauges if they were held
> liable for their mistakes.

I guess all the professionals in other fields where they are
held up to scrutiny must be irresponsible daredevils too. For
example, there are operations that have very low success rates,
yet there are doctors that specialize in them anyway, despite
the low odds.

If you don't want to take the risk, then go write in visual
whatever#.net and leave it to those that are.


--
Randy Howard (2reply remove FOOBAR)