Dynamic linking with LD_PRELOAD - get it compiled - Linux

This is a discussion on Dynamic linking with LD_PRELOAD - get it compiled - Linux ; On Mar 12, 1:26 pm, Johannes Bauer wrote:
> > The best place to stop this chain is at the very first link. You
> > should need a damn good reason to do it wrong, not a good reason ...

Re: Dynamic linking with LD_PRELOAD - get it compiled

On Mar 12, 1:26 pm, Johannes Bauer wrote:
> > The best place to stop this chain is at the very first link. You
> > should need a damn good reason to do it wrong, not a good reason to do
> > it right.
> So essentialy what you're saying is that I should respond with "My code
> is poorly written, I'm not giving it out" rather then "My code is poorly
> written, do whatever you want with it" (as I did)?

No, please read what I wrote again. What I'm saying is that it was no
easier to write your code poorly, and your justification (that nobody
else would ever use the code with different libraries) turned out to
be bogus.
> I think when it is explicitly stated that the code is of poor quality,
> full of ridiculous hacks and induces undefined behavior as of the
> C-standard - what else would anyone expect who tried to use it other
> than the code breaking? And why do you blame me for this?

Because you chose to write code of poor quality and full of ridiculous
hacks, and you did so knowing that this was exactly what you were
doing.
> Actually I do not think anyone seriously wants to use the code - maybe
> take a peek, that's it. With the discussion here, all warnings are
> pretty clear (and its being handed out to a reader of c.o.l.d.s., so I
> guess he knows what he's doing).

I hope not. But there's a lesson here -- code has a way of outliving
its expected life and decisions to do things in a dirty way have a way
of coming back and biting someone. So don't do that unless you have a
really good reason and always be suspicious when you find yourself
thinking "nobody else will ever use this for anything else".

Tell me, did you wrap your code with appropriate 'ifdef's and
'#warning's? How much longer would that have taken?

DS

Re: Dynamic linking with LD_PRELOAD - get it compiled

David Schwartz schrieb:
> On Mar 12, 1:26 pm, Johannes Bauer wrote:
>
>>> The best place to stop this chain is at the very first link. You
>>> should need a damn good reason to do it wrong, not a good reason to do
>>> it right.
>
>> So essentialy what you're saying is that I should respond with "My code
>> is poorly written, I'm not giving it out" rather then "My code is poorly
>> written, do whatever you want with it" (as I did)?
>
> No, please read what I wrote again. What I'm saying is that it was no
> easier to write your code poorly, and your justification (that nobody
> else would ever use the code with different libraries) turned out to
> be bogus.

You make me sound like a liar, which I find kind of unfair. I did, in
fact, not know that anyone would have any interest in the code. My
assumtions turned out to be incorrect - but it's not like I knew that in
advance.
>> I think when it is explicitly stated that the code is of poor quality,
>> full of ridiculous hacks and induces undefined behavior as of the
>> C-standard - what else would anyone expect who tried to use it other
>> than the code breaking? And why do you blame me for this?
>
> Because you chose to write code of poor quality and full of ridiculous
> hacks, and you did so knowing that this was exactly what you were
> doing.

Yes, because it saved me an - warning, wild guess here - appriximate
300-500 lines of code in the generator which it would have taken if I
wanted to support all kinds of (pointer) types. It was a lot easier that
way.
>> Actually I do not think anyone seriously wants to use the code - maybe
>> take a peek, that's it. With the discussion here, all warnings are
>> pretty clear (and its being handed out to a reader of c.o.l.d.s., so I
>> guess he knows what he's doing).
>
> I hope not. But there's a lesson here -- code has a way of outliving
> its expected life and decisions to do things in a dirty way have a way
> of coming back and biting someone. So don't do that unless you have a
> really good reason and always be suspicious when you find yourself
> thinking "nobody else will ever use this for anything else".

And they should come back and bite everyone who uses them! They
absolutely should. Because the one thing we both seem to agree on is
that the generated code is crap. Whoever uses crap gets UB. Period.
> Tell me, did you wrap your code with appropriate 'ifdef's and
> '#warning's? How much longer would that have taken?

It actually emits a warning for each generated #define which replaces a
prototype. Do you want me to send you the source? ;-)

Re: Dynamic linking with LD_PRELOAD - get it compiled

On Mar 12, 3:13 pm, Johannes Bauer wrote:
> > No, please read what I wrote again. What I'm saying is that it was no
> > easier to write your code poorly, and your justification (that nobody
> > else would ever use the code with different libraries) turned out to
> > be bogus.
> You make me sound like a liar, which I find kind of unfair. I did, in
> fact, not know that anyone would have any interest in the code. My
> assumtions turned out to be incorrect - but it's not like I knew that in
> advance.

Right, just like the people who wrote code with Y2K bugs didn't know
in advance that their code would still be in use 30 years later. Every
link in the chain has a justification, but the end result is disaster.
So you have to stop the chain at the first link.
> > Tell me, did you wrap your code with appropriate 'ifdef's and
> > '#warning's? How much longer would that have taken?
> It actually emits a warning for each generated #define which replaces a
> prototype. Do you want me to send you the source? ;-)

No, let's stop it from spreading any further.

The point is not the particular thing you did in this particular case.
The point is that any time you find yourself thinking "this code will
never be used for anything other than precisely what I'm using it for
now", you're as likely to be wrong as right. And the next person will
find it "happens to work for me" and so on and so on.

At least try to document your assumptions when and where you make
them. Try to use appropriate 'ifdef's and '#warning's and whatever
else it takes.

DS

Re: Dynamic linking with LD_PRELOAD - get it compiled

On Wed, 12 Mar 2008 15:53:41 +0100 Johannes Bauer wrote:
| phil-news-nospam@ipal.net schrieb:
|
|> OK, so that works. It's a hack. What I'm curious about is why you could
|> not just define select to match the library declaration? Are you trying
|> to make this an intercept function that just passes on the arguments AND
|> can work no matter which way the function is declared/defined by libc?
|
| Exactly. It's a code generator which just passes on pointers in the
| gerneated code. It links together with user code which has knowledge
| about the pointers (so it casts appropriately).
|
| I've not thought about licensing the code itself, but if you want to see
| it, I'd like to make it GPL-2. It's a ~1000 lines C++ program which
| generates C code (that builds a shared lib which can be used to
| LD_PRELOAD and reverse engineer certain other libraries/programs). Is
| your mail valid? I'd send it to you then.

I'd rather you not email any code. If you want to make it public, put it
online somewhere and tell us where. If you don't, I'd rather not have it.

Re: Dynamic linking with LD_PRELOAD - get it compiled

On Wed, 12 Mar 2008 12:18:28 -0700 (PDT) David Schwartz wrote:
| On Mar 12, 12:06 pm, Johannes Bauer wrote:
|
|> Nope, you're wrong. I never ever intended to give the app away in the
|> first place - if someone asks, however, that's fine with me.
|
| You never intended to, but code has a way of being used outside the
| designer's intentions.

Lots of code gets used way beyond the intentions. Look at XML for example.
It was intended as a _document_ format. It's being used to store config
data and other non-document things. People are doing that because it has
parsers already built, ready to use. They don't want to write parsers for
what might otherwise be a more optimal format for what they are doing.

Just because code has a _narrow_ use doesn't mean someone else won't find
a reasonable use for it ... or merely be inspired by it.

| The first thought is, "it's only ever going to be used on this
| platform with this compiler, so there's no reason to make it
| portable". The next thought is, "hey, maybe it works on this other
| platform". Then, "hey, it seems to work, so let's use it". The next
| thing you know, it breaks.

And you want to protect people that are so stupid that they mis-port code,
by saying no one else should benefit by this narrow purpose code?

| The best place to stop this chain is at the very first link. You
| should need a damn good reason to do it wrong, not a good reason to do
| it right.

OTOH, maybe someone will look at that code, say "I can do better", and
write it all over from scratch to do the same thing, only better. I seem
to remember some Swedish speaking Finnish college student having that
attitude many years ago.

Re: Dynamic linking with LD_PRELOAD - get it compiled

On Wed, 12 Mar 2008 15:45:48 -0700 (PDT) David Schwartz wrote:
| On Mar 12, 3:13 pm, Johannes Bauer wrote:
|
|> > No, please read what I wrote again. What I'm saying is that it was no
|> > easier to write your code poorly, and your justification (that nobody
|> > else would ever use the code with different libraries) turned out to
|> > be bogus.
|
|> You make me sound like a liar, which I find kind of unfair. I did, in
|> fact, not know that anyone would have any interest in the code. My
|> assumtions turned out to be incorrect - but it's not like I knew that in
|> advance.
|
| Right, just like the people who wrote code with Y2K bugs didn't know
| in advance that their code would still be in use 30 years later. Every
| link in the chain has a justification, but the end result is disaster.
| So you have to stop the chain at the first link.

Ironically, over 90% of the code that failed Y2K where I was consulting
at the time specifically to rapidly deal with Y2K issues, had been written
within the prior 3 years.

Re: Dynamic linking with LD_PRELOAD - get it compiled

On Mar 12, 6:30 pm, phil-news-nos...@ipal.net wrote:
> | The best place to stop this chain is at the very first link. You
> | should need a damn good reason to do it wrong, not a good reason to do
> | it right.
> OTOH, maybe someone will look at that code, say "I can do better", and
> write it all over from scratch to do the same thing, only better. I seem
> to remember some Swedish speaking Finnish college student having that
> attitude many years ago.

You can almost always do it better from scratch if you get to start
out learning what goes wrong and what goes right when you try to do it
the way you thought was best. On the flip side, if you try to do it a
way that you know is wrong, you learn very little when it doesn't work
the way people hope.

A good programming adage is "do it once and throw it away". The second
time, you will be able to design it knowing the real strengths and
weaknesses of your first design.

The best code I've ever written has been at least the third of fourth
time I've tried to do something. Sometimes the re-writes are in-place,
sometimes they're total. It depends how wrong I got it the N-1th time.

But none of that will happen if you start out knowingly doing it
wrong.

DS

Re: Dynamic linking with LD_PRELOAD - get it compiled

David Schwartz writes:
> On Mar 12, 6:30 pm, phil-news-nos...@ipal.net wrote:
>> | The best place to stop this chain is at the very first link. You
>> | should need a damn good reason to do it wrong, not a good reason to do
>> | it right.
>
>> OTOH, maybe someone will look at that code, say "I can do better", and
>> write it all over from scratch to do the same thing, only better. I seem
>> to remember some Swedish speaking Finnish college student having that
>> attitude many years ago.
>
> You can almost always do it better from scratch if you get to start
> out learning what goes wrong and what goes right when you try to do it
> the way you thought was best. On the flip side, if you try to do it a
> way that you know is wrong, you learn very little when it doesn't work
> the way people hope.
>
> A good programming adage is "do it once and throw it away". The second
> time, you will be able to design it knowing the real strengths and
> weaknesses of your first design.

.... which will lead to gathering actual experience with the real
'strengths and weaknesses' of the 'first improved design' ...

Re: Dynamic linking with LD_PRELOAD - get it compiled

On Wed, 12 Mar 2008 23:14:59 -0700 (PDT) David Schwartz wrote:
| On Mar 12, 6:30 pm, phil-news-nos...@ipal.net wrote:
|
|> | The best place to stop this chain is at the very first link. You
|> | should need a damn good reason to do it wrong, not a good reason to do
|> | it right.
|
|> OTOH, maybe someone will look at that code, say "I can do better", and
|> write it all over from scratch to do the same thing, only better. I seem
|> to remember some Swedish speaking Finnish college student having that
|> attitude many years ago.
|
| You can almost always do it better from scratch if you get to start
| out learning what goes wrong and what goes right when you try to do it
| the way you thought was best. On the flip side, if you try to do it a
| way that you know is wrong, you learn very little when it doesn't work
| the way people hope.

I'm not talking about that. I'm talking about inspiration not in how to
do it, but in what to do. Someone will look at the bad code and see that
it clearly is done in a bad way, and decide to do it from scratch. But
they didn't get the idea to do it at all until the see that someone has
already written the code.

| A good programming adage is "do it once and throw it away". The second
| time, you will be able to design it knowing the real strengths and
| weaknesses of your first design.

I agree with this. But sometimes that "second time" is someone else.

| The best code I've ever written has been at least the third of fourth
| time I've tried to do something. Sometimes the re-writes are in-place,
| sometimes they're total. It depends how wrong I got it the N-1th time.

That's happened to me more than once.

| But none of that will happen if you start out knowingly doing it
| wrong.

Not necessarily. I call it "prototyping". I see no reason not to let it
loose, as as long as you don't make any claims that it is believed to be
done right.

Re: Dynamic linking with LD_PRELOAD - get it compiled

David Schwartz wrote:
> On Mar 12, 3:13 pm, Johannes Bauer wrote:
>
>> > No, please read what I wrote again. What I'm saying is that it was no
>> > easier to write your code poorly, and your justification (that nobody
>> > else would ever use the code with different libraries) turned out to
>> > be bogus.
>
>> You make me sound like a liar, which I find kind of unfair. I did, in
>> fact, not know that anyone would have any interest in the code. My
>> assumtions turned out to be incorrect - but it's not like I knew that in
>> advance.
>
> Right, just like the people who wrote code with Y2K bugs didn't know
> in advance that their code would still be in use 30 years later. Every
> link in the chain has a justification, but the end result is disaster.
> So you have to stop the chain at the first link.

Were you doing programming then? I was. When you have a machine with
perhaps 256KB of memory and 16 or so 100MB disks you store data as
efficiently as possible.

BTW, what exactly is your problem? Do you always need to get the last
word? The OP has a solution to _his_ problem, that it doesn't fit
_your_ ideas of perfection is of no matter. If he makes his code
available, with no warranty of course, for other people who may find
it useful it is certainly all the better.

Jerry

Re: Dynamic linking with LD_PRELOAD - get it compiled

On Mar 13, 1:31 pm, Jerry Peters wrote:
> Were you doing programming then? I was. When you have a machine with
> perhaps 256KB of memory and 16 or so 100MB disks you store data as
> efficiently as possible.

Right, but that mentality doesn't work any more. In the vast majority
of programming applications, maintainability, understandability, and
reusability are much more important than squeezing out a few bytes.
> BTW, what exactly is your problem? Do you always need to get the last
> word?

I don't always need to get the last word, but if I disagree with
someone and they raise new points, I will usually respond to them. If
I think there's a valuable lesson that might be missed, I'll usually
point it out.
> The OP has a solution to _his_ problem, that it doesn't fit
> _your_ ideas of perfection is of no matter.

It may not matter to the OP, but that's not how the give and take of
USENET works. It's not "you help me with this, and I'll help somebody
else". It's "you help me with this, and everybody will learn from it,
adding to the storehouse of knowledge we all have".

That's why when someone posts a very specific question about a very
specific one-in-a-million case, it's important that somebody somewhere
point out that this not the typical case and that following the
solutions in that thread will probably be wrong if you're not the
poster.

This preserves the usefulness of past USENET posts.
> If he makes his code
> available, with no warranty of course, for other people who may find
> it useful it is certainly all the better.

Maybe, maybe not. If it serves as an example or subsequently breaks in
production use in subtle and horrible ways, it is not all the better.
If people see this post and assume that's how things are typically
done, it is not all the better.

We need to lose the mentality from the 60s through the 90s that
performance and space efficiency are priority one. For the bulk of
code written today, correctness, understandability and maintainability
are extremely important. They should never be sacrificed for
performance or alleged convenience when there is no good reason to do
so.

When they are sacrificed for good reason, it is important that it be
understood that these are things we do when we have good reason.

DS

Re: Dynamic linking with LD_PRELOAD - get it compiled

David Schwartz wrote:
> We need to lose the mentality from the 60s through the 90s that
> performance and space efficiency are priority one. For the bulk of
> code written today, correctness, understandability and maintainability
> are extremely important. They should never be sacrificed for
> performance or alleged convenience when there is no good reason to do
> so.

I am horrified by this prose. This is the reason why most software today
(OpenOffice, etc.) is horribly bloated and inefficient, so that you need
more and more powerful machines to get reasonable performance. All
developers should be trained to get performance out of their code.

--

Michel TALON

Re: Dynamic linking with LD_PRELOAD - get it compiled

talon@lpthe.jussieu.fr (Michel Talon) writes:
> David Schwartz wrote:
>> We need to lose the mentality from the 60s through the 90s that
>> performance and space efficiency are priority one. For the bulk of
>> code written today, correctness, understandability and maintainability
>> are extremely important. They should never be sacrificed for
>> performance or alleged convenience when there is no good reason to do
>> so.
>
> I am horrified by this prose. This is the reason why most software today
> (OpenOffice, etc.) is horribly bloated and inefficient, so that you need
> more and more powerful machines to get reasonable performance.

This isn't exactly true. I mainly develop targetting an 'embedded'
ARM9-based system with a 200Mhz-CPU, no possibility for any paging
and 64M of RAM. While this would have been a top-of-line desktop some
dozen years ago, it is really 'limited' hardware nowadays. The base
operating system image has a (compressed) size of (presently) 2052K
(the uncompressed FS tree is 6M). The 'largest' application running on
these device has (on my development board) presently a RSS of 1020K,
mainly, because it needs to link against most of the Kerberos 5
libraries. All others are significantly smaller. Nothing running on
such a device has been 'heavily' optimized for either speed or space
efficiency. The most advanced thing I have done in this respect was to
rewrite the top-level AES- and MD5 interfacing code to avoid redundant
memory copies, of which there were plenty, and obviously useless
computations (like using cipertext stealing instead of padding
cleartext to the AES blocksize when encrypting IP datagrams to support
VPN functionality).

I am generally very much in favor of prefering simple, structured code
at the expense of both performance and speed except in situations
where there is a real need to do otherwise. Because I like to 'waste'
computer ressources in order to make code more accessible to humans,
I avoid obvious 'waste for no particular reason', to ensure that I
preferably never get into the situation where I have to contort the
code in order to make it faster or smaller. So far, this has proven to
be completely sufficient.

Re: Dynamic linking with LD_PRELOAD - get it compiled

On Mar 14, 2:01 am, ta...@lpthe.jussieu.fr (Michel Talon) wrote:
> David Schwartz wrote:
> > We need to lose the mentality from the 60s through the 90s that
> > performance and space efficiency are priority one. For the bulk of
> > code written today, correctness, understandability and maintainability
> > are extremely important. They should never be sacrificed for
> > performance or alleged convenience when there is no good reason to do
> > so.
> I am horrified by this prose. This is the reason why most software today
> (OpenOffice, etc.) is horribly bloated and inefficient, so that you need
> more and more powerful machines to get reasonable performance.

Nope, that's a myth. Reusable code is efficient.
> All
> developers should be trained to get performance out of their code.

Absolutely, by creating reusable code.

You could never have a product like OpenOffice if every element had to
be generated from scratch just for OpenOffice. And you could never
implement everything OpenOffice has to do efficiently if you had to do
it just for OpenOffice. But someone has written an efficient XML
parser. And someone has written an efficient text renderer. And with
those pieces, you can produce an efficient complete product with
reasonable effort.

If a bug is found in the XML parser, and you used that XML parser, you
just upgrade it to the version with the bug fix.

Sure, you could write your own XML parser that had just the features
you needed. But it will probably perform worse, because you don't need
enough XML features to justify optimizing it. And it sure as hell
won't be maintained, because you don't particularly care about XML
parsing.

It used to be that you had no choice. A general-purpose whatever would
be too bulky and slow to be an option. But now you have a choice.
Ironically, performance will typically be better, because more effort
can go into optimizing each component if it's reusable.

DS

Re: Dynamic linking with LD_PRELOAD - get it compiled

David Schwartz writes:
> On Mar 14, 2:01 am, ta...@lpthe.jussieu.fr (Michel Talon) wrote:
>> David Schwartz wrote:
>> > We need to lose the mentality from the 60s through the 90s that
>> > performance and space efficiency are priority one. For the bulk of
>> > code written today, correctness, understandability and maintainability
>> > are extremely important. They should never be sacrificed for
>> > performance or alleged convenience when there is no good reason to do
>> > so.
>
>> I am horrified by this prose. This is the reason why most software today
>> (OpenOffice, etc.) is horribly bloated and inefficient, so that you need
>> more and more powerful machines to get reasonable performance.
>
> Nope, that's a myth. Reusable code is efficient.

'Reusable code' is 'efficient' for people paying for software
development, provided they are not using it themselves. If they do,
any preceived benefit will be eaten over time.
>> All developers should be trained to get performance out of their
>> code.
>
> Absolutely, by creating reusable code.
>
> You could never have a product like OpenOffice if every element had to
> be generated from scratch just for OpenOffice.

Funnily enough, the people who wrote the original StarWriter did just
that. They even coded a signifcant part of it in assembly, because
this means it ran well (extremly well, actually) on then-current PC
hardware.

[...]
> But someone has written an efficient XML parser.

Considering that 'parsing XML' necessitates dealing with more than
enough overhead to make anything 'slow', optimizing the hell out of an
XML-parser to make it 'faster' is a stupid waste of time: Just not
using XML would increase the 'performance' of the thing using it and
decrease the time needed to develop it more.

But the crucial point is, of course, that _somebody else has written
an XML parser_ and that 'mere users', if only because of lack of
alternatives, are willing to accept that their 3.x Ghz-PCs with 4G of
RAM enable them to at least not spend more time waiting for the
computer than they already did wait for a 4.77Mhz-machine with 640M of
RAM twenty years ago. 'Fortunately', the waste of electricity and the
corresponding, ever incresing heap of toxic rubbish does not yet have
to be paid by the people causing it, so, their particular method of
socializing cost to increase private gain still works.

[...]
> If a bug is found in the XML parser, and you used that XML
> parser, you just upgrade it to the version with the bug fix.

It's more likely that 'you' just add some code to workaround this
particular issue in the 'frontend-code', because 'the bug in
the XML parser' will never be fixed, either, because the people who
wrote don't care or consider it to actually be a feature, or because
nobody feels comfortable touching this particular piece of code, given
that this could break one of the other 567 workarounds for bugs and
quirks in it nobody understand entirely anymore, too.

There is method to this madness, and the method cause each
'sufficiently complicated' program to exhibit a tumor-like growth over
time.
> Sure, you could write your own XML parser that had just the features
> you needed. But it will probably perform worse, because you don't need
> enough XML features to justify optimizing it.

Simpler, and especially, less code, will usually perform better than
more complicated or more code.

[...]
> Ironically, performance will typically be better, because more effort
> can go into optimizing each component if it's reusable.

If there is a need to even think about 'optimizing components', that's
usually a sign that the baby already drowned. Computers are fast
enough nowadays that simple code will almost always perform 'well
enough'. What remains to be done would be to convince the clever
people spending enormous amounts of time trying to fix their design
errors by means of 'hyper-clever optimimzations' to go looking for
another playing field. Maybe complicated crossword puzzles coud be
one. This would help to increase both the actual performance and
reliablity of software quite a bit, because suddenly, the time to
develop it sensibly would be there because the need to 'clever around'
350 KLoC of inerithed deficiencies would be gone.

Re: Dynamic linking with LD_PRELOAD - get it compiled

On Mar 14, 7:11 pm, David Schwartz wrote:
> [a lot of stuff]

David, while everything you say about reusability and proper software
design is true and valid, unless you actually cite the specific source
for this "all software must be properly designed, modular, reusable,
and portable" that you seemed to have made up, your entire original
attack on poor Mr. Bauer completely falls apart.

Can you fill us all in on where that rule is? Is that part of a
standard or something? This may be hard to believe, but Johannes
Bauer's kludgey application is not the only one of it's kind out
there. In fact, there may be hundreds of thousands, even millions, of
programs that people have written that don't get the International
Organization of Perfectly Designed Application's 100% Seal of Quality
Approval. Millions! How can you sleep at night, knowing that somewhere
there is a program that compiles on somebody's computer, but not on
yours? How can you sleep at night, knowing that somewhere there is an
application with source code that can't be infinitely copied, pasted,
expanded, and reused? How do you feel knowing that your kids may be
using computers with poorly designed applications on them?? Your own
children, for God's sake! Using improperly designed applications! What
is this world coming to?
> It used to be that you had no choice. A general-purpose whatever would
> be too bulky and slow to be an option. But now you have a choice.

Precisely. The last sentence hits the nail on the head.

Jason

Re: Dynamic linking with LD_PRELOAD - get it compiled

| David, while everything you say about reusability and proper software
| design is true and valid, unless you actually cite the specific source
| for this "all software must be properly designed, modular, reusable,
| and portable" that you seemed to have made up, your entire original
| attack on poor Mr. Bauer completely falls apart.

It's actually a rather common principle. OTOH, I think that principle
is overused and too often misapplied ... especially the reusable part.
I separate a lot of the software I write into library functions and main
programs. The library functions are intended to be reusable. The main
programs are not.

When writing a new program, I try to understand how widely it could be
used for its purpose. But I won't consider making it usable for purposes
I cannot imagine.

| Can you fill us all in on where that rule is? Is that part of a
| standard or something? This may be hard to believe, but Johannes
| Bauer's kludgey application is not the only one of it's kind out
| there. In fact, there may be hundreds of thousands, even millions, of
| programs that people have written that don't get the International
| Organization of Perfectly Designed Application's 100% Seal of Quality
| Approval. Millions! How can you sleep at night, knowing that somewhere
| there is a program that compiles on somebody's computer, but not on
| yours? How can you sleep at night, knowing that somewhere there is an
| application with source code that can't be infinitely copied, pasted,
| expanded, and reused? How do you feel knowing that your kids may be
| using computers with poorly designed applications on them?? Your own
| children, for God's sake! Using improperly designed applications! What
| is this world coming to?

Whenever I need to write something that is very machine specific to one
single machine, I have no qualms about doing that. I have done it many
times. And there are plenty of examples around of programs and functions
that are very machine specific. And device drivers are, too, but that is
an obvious special case.

|> It used to be that you had no choice. A general-purpose whatever would
|> be too bulky and slow to be an option. But now you have a choice.
|
| Precisely. The last sentence hits the nail on the head.

You mean we should still have a choice between a highly optimized machine
specific program and a (relatively) slow and bulky (but comfortably fast
on today's machines) portable version, where one can run 20 of the former
or 3 of the latter at the same time on a given modern machine?

Re: Dynamic linking with LD_PRELOAD - get it compiled

On Mar 17, 9:33 am, phil-news-nos...@ipal.net wrote:
> [snip a lot of reasonable stuff that I agree with]
> |> It used to be that you had no choice. A general-purpose whatever would
> |> be too bulky and slow to be an option. But now you have a choice.
> |
> | Precisely. The last sentence hits the nail on the head.
>
> You mean we should still have a choice between a highly optimized machine
> specific program and a (relatively) slow and bulky (but comfortably fast
> on today's machines) portable version, where one can run 20 of the former
> or 3 of the latter at the same time on a given modern machine?

That's probably not what I meant, as it doesn't make sense in the
context of what I said. More likely, I meant that a programmer still
has a choice between a portable, reusable application (which doesn't
necessarily have to be slow and bulky, even relatively), and a non-
portable, not-so-reusable application that he puts together quickly
and gets the job done. I should have been less vague.

My major point is that it's unreasonable to claim that all
applications should consist of portable and reusable code. Another
point I am making is that it is equally unreasonable to criticize
(even mildly) an application that does not consist of portable/
reusable code and that also makes no claims otherwise (of course, if
somebody claims to have written a "cross-platform food processing
library" but it only chops carrots on Windows, you're definitely
justified in smacking them around a bit).

Jason

Re: Dynamic linking with LD_PRELOAD - get it compiled

| My major point is that it's unreasonable to claim that all
| applications should consist of portable and reusable code. Another
| point I am making is that it is equally unreasonable to criticize
| (even mildly) an application that does not consist of portable/
| reusable code and that also makes no claims otherwise (of course, if
| somebody claims to have written a "cross-platform food processing
| library" but it only chops carrots on Windows, you're definitely
| justified in smacking them around a bit).

Re: Dynamic linking with LD_PRELOAD - get it compiled

On Mar 17, 9:33 am, "jason.cipri...@gmail.com" wrote:
> My major point is that it's unreasonable to claim that all
> applications should consist of portable and reusable code.

Well, since nobody claimed that, ...
> Another
> point I am making is that it is equally unreasonable to criticize
> (even mildly) an application that does not consist of portable/
> reusable code and that also makes no claims otherwise

Why not? What if the code would have been more robust, easier to
understand, portable, and reusable with even less effort than it took
to make it non-portable and not reusable? Would you still argue that
it's unreasonable to criticize it just because it doesn't claim to be
portable or reusable?
> (of course, if
> somebody claims to have written a "cross-platform food processing
> library" but it only chops carrots on Windows, you're definitely
> justified in smacking them around a bit).

Bad design and bad code is still bad even if nobody claims it's good.
In many cases, it's actually harder to write the non-portable, non-
reusable code than it would have been to do it right.

A good example would be writing your own XML library because you "only
need a few simple capabilities". Not only is this likely to be more
work than using one that's already made, but it will likely mishandle
a large number of corner cases that maintained XML libraries work hard
to get right.

It's likely not even faster in execution. And if it is, that doesn't
matter anyway since the assumption was that this was a limited-purpose
program. And, of course, that would be premature optimization.

It might take up less memory, but who cares? And in many cases, it
actually won't.