twitter: comp.lang.c - 26 new messages in 4 topics

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* The C FAQ - 6 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/b75c0ae09abf3345?hl=en
* Motivation of software professionals - 8 messages, 6 authors
http://groups.google.com/group/comp.lang.c/t/21a3fdec4dd53e6a?hl=en
* Efficency and the standard library - 10 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/ad9fea19f2f7dd61?hl=en
* HOW this program is executing plz explain the program - 2 messages, 2
authors
http://groups.google.com/group/comp.lang.c/t/3fb552296fac02d8?hl=en

==============================================================================
TOPIC: The C FAQ
http://groups.google.com/group/comp.lang.c/t/b75c0ae09abf3345?hl=en
==============================================================================

== 1 of 6 ==
Date: Sat, Feb 13 2010 8:51 am
From: Seebs

On 2010-02-13, jacob navia <jacob@spamsink.net> wrote:
> Seebs a écrit :
>> On 2010-02-12, jacob navia <jacob@nospam.org> wrote:
>>> Linux is even more fragmented that the different Unix flavors at that time.

>> I wrote a hunk of code which has one meaningful #ifdef in it, which is
>> working on every Linux system we know of currently available.

> First bet:

> It doesn't use any GUI

Right you are!

> Second bet:

> It doesn't use any sound/video/multimedia

Right you are!

> Third bet:

> It doesn't use any graphics, or mouse

Three for three!

> Obviously, THEN... it is portable. But it would be portable to
> Mac/windows/whatever too without much pain.

And here you've got a Nilges-grade error.

Lemme tell you what this hunk of code is. This'll drift a bit off topic,
but it's a very good example of how very non-portable a piece of code can
be. I would guess that I could get it running on OS X in a month or so,
but I am pretty sure it is semantically incoherent to talk about "porting"
it to Windows.

Background:
* Nearly all executables on Linux systems are dynamically linked, meaning
that they pick up the C library at runtime.
* Unix-like systems distinguish between "library" calls (made to code in
the C library) and "system" calls (made to the kernel).
* But actually, nearly all syscalls exist as tiny little stubs that are
found in the library and which contain the raw inline code to make a
syscall.
* The dynamic linker on Linux checks certain environment variables when
starting up, BEFORE it loads anything (including even the C library).
* These can cause it to do things like check paths other than the usual
system-wide linker path, and/or to load libraries BEFORE the shared
libraries a program was linked with, and which it was not linked with and
it has no knowledge of.
* The product I work on involves creating filesystems for embedded Linux
systems.
* Creating filesystems nearly always involves operations that require
root (sysadmin) privileges.
* It is extremely desireable that users not need root access on their
workstations to do it, though.

So.

The "hunk of code" alluded to above is a two-part thing. One part is a shared
library. Another part is a server. The shared library is designed such that,
if you put its name in the LD_PRELOAD environment variable, and a path to it
in the LD_LIBRARY_PATH environment variable, it will get picked up by any
dynamically-linked executable, and lookups of calls in it will pick up the
versions in this library BEFORE they pick up versions in the C library.

And it provides functions with the same names as a few dozen system calls,
and a couple of C-level library calls.

When you first hit one of these functions, it builds itself a table of the
"next" versions of all these calls (usually the ones in the C library, but
there could be other similar libraries; we don't care). And then it sets
up wrappers so that when you call the syscall open(), what you actually get
is my implementation of open(), which does some interesting magic stuff.

What this ends up doing is allowing me to intercept every system call that
deals with the filesystem and is affected by privileges, and act as though
you had root privileges, or at least, make it look as though it acted as
though you had root privileges. The client code does this by finding out
whether it has a server, and if not, starting a server, to which it then
sends messages informing the server about operations, or querying the server
about filesystem objects; the server maintains a database of files and
what to claim they are. So if you try to create a "device node" (a special
kind of Unix "file" which instead of having contents provides access to
the userspace interface of a device driver; e.g., a file named "sda1" might
end up hooked up to the first partition of the first SCSI disk on the
machine), what actually happens is:
1. I verify that there's not a file there, and if there is, fail
the same way the real syscall would have.
2. I create a plain file with no contents of that name.
3. If that succeeded, I send a note to the server telling it that
the file I just created should LOOK like it's a device node
with the given attributes.

Later, if you try to look at that file with, say, "ls -l", what actually
happens is:
1. I check the real file on disk.
2. I query the server about that path and file dev/inode (magic ID
uniquely identifying a file).
3. If I got anything back from the server, I replace the file's
"real" attributes with the attributes the server gave me.
4. I report back as though nothing happened.

There's a lot more, and some of it gets extremely arcane; there's magic
to intercept dozens of calls and do very surprising stuff.

The net result is that you can run an entire system install process and
end up with something which, viewed through this tool, looks just like a
properly-installed filesystem, complete with files owned by many different
users, device nodes, and everything. And then you can use other tools
which do things like create raw filesystem images or archives, and run
them in this magic mode, and get raw filesystem images which, dumped to disk
or flash, actually are working filesystem images with all the right modes.

The concept of porting this to Windows is frankly laughable. I could probably
get it working on BSD or OS X in about a month, give or take, but I'm not
totally sure; there's some pretty crazy assumptions in there, although I've
developed some neat trickery to allow this code to work even if some of the
"extra" calls it has don't exist on a given target. (e.g., some systems have
a family of calls with names like "openat()" or "unlinkat()" which allow you
to operate relative to a directory without having to specify the path to
that directory, others don't; my program wraps them if they exist, but works
fine even if they don't.)

Porting this between BSD and SysV in 1989 would have been much harder than
simply rewriting nearly all of it from scratch completely differently for
each, if it had even been possible to do it at all. (By 1990, you could
at least get ELF and dynamic linking on SVR4, so it might have been
possible there.) So, no, the Linux environment is NOT more fragmented than
the historical Unix market. They have greater code portability than anything
we ever saw back then.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 2 of 6 ==
Date: Sat, Feb 13 2010 9:09 am
From: Richard

Seebs <usenet-nospam@seebs.net> writes:

> On 2010-02-13, jacob navia <jacob@spamsink.net> wrote:
>> Seebs a écrit :
>>> On 2010-02-12, jacob navia <jacob@nospam.org> wrote:
>>>> Linux is even more fragmented that the different Unix flavors at that time.
>
>>> I wrote a hunk of code which has one meaningful #ifdef in it, which is
>>> working on every Linux system we know of currently available.
>
>> First bet:
>
>> It doesn't use any GUI
>
> Right you are!
>
>> Second bet:
>
>> It doesn't use any sound/video/multimedia
>
> Right you are!
>
>> Third bet:
>
>> It doesn't use any graphics, or mouse
>
> Three for three!
>
>> Obviously, THEN... it is portable. But it would be portable to
>> Mac/windows/whatever too without much pain.
>
> And here you've got a Nilges-grade error.
>
> Lemme tell you what this hunk of code is. This'll drift a bit off topic,
> but it's a very good example of how very non-portable a piece of code can
> be. I would guess that I could get it running on OS X in a month or so,
> but I am pretty sure it is semantically incoherent to talk about "porting"
> it to Windows.
>
> Background:
> * Nearly all executables on Linux systems are dynamically linked, meaning
> that they pick up the C library at runtime.
> * Unix-like systems distinguish between "library" calls (made to code in
> the C library) and "system" calls (made to the kernel).
> * But actually, nearly all syscalls exist as tiny little stubs that are
> found in the library and which contain the raw inline code to make a
> syscall.
> * The dynamic linker on Linux checks certain environment variables when
> starting up, BEFORE it loads anything (including even the C library).
> * These can cause it to do things like check paths other than the usual
> system-wide linker path, and/or to load libraries BEFORE the shared
> libraries a program was linked with, and which it was not linked with and
> it has no knowledge of.
> * The product I work on involves creating filesystems for embedded Linux
> systems.
> * Creating filesystems nearly always involves operations that require
> root (sysadmin) privileges.
> * It is extremely desireable that users not need root access on their
> workstations to do it, though.
>
> So.
>
> The "hunk of code" alluded to above is a two-part thing. One part is a shared
> library. Another part is a server. The shared library is designed such that,
> if you put its name in the LD_PRELOAD environment variable, and a path to it
> in the LD_LIBRARY_PATH environment variable, it will get picked up by any
> dynamically-linked executable, and lookups of calls in it will pick up the
> versions in this library BEFORE they pick up versions in the C library.
>
> And it provides functions with the same names as a few dozen system calls,
> and a couple of C-level library calls.
>
> When you first hit one of these functions, it builds itself a table of the
> "next" versions of all these calls (usually the ones in the C library, but
> there could be other similar libraries; we don't care). And then it sets
> up wrappers so that when you call the syscall open(), what you actually get
> is my implementation of open(), which does some interesting magic stuff.
>
> What this ends up doing is allowing me to intercept every system call that
> deals with the filesystem and is affected by privileges, and act as though
> you had root privileges, or at least, make it look as though it acted as
> though you had root privileges. The client code does this by finding out
> whether it has a server, and if not, starting a server, to which it then
> sends messages informing the server about operations, or querying the server
> about filesystem objects; the server maintains a database of files and
> what to claim they are. So if you try to create a "device node" (a special
> kind of Unix "file" which instead of having contents provides access to
> the userspace interface of a device driver; e.g., a file named "sda1" might
> end up hooked up to the first partition of the first SCSI disk on the
> machine), what actually happens is:
> 1. I verify that there's not a file there, and if there is, fail
> the same way the real syscall would have.
> 2. I create a plain file with no contents of that name.
F> 3. If that succeeded, I send a note to the server telling it that
> the file I just created should LOOK like it's a device node
> with the given attributes.
>
> Later, if you try to look at that file with, say, "ls -l", what actually
> happens is:
> 1. I check the real file on disk.
> 2. I query the server about that path and file dev/inode (magic ID
> uniquely identifying a file).
> 3. If I got anything back from the server, I replace the file's
> "real" attributes with the attributes the server gave me.
> 4. I report back as though nothing happened.
>
> There's a lot more, and some of it gets extremely arcane; there's magic
> to intercept dozens of calls and do very surprising stuff.
>
> The net result is that you can run an entire system install process and
> end up with something which, viewed through this tool, looks just like a
> properly-installed filesystem, complete with files owned by many different
> users, device nodes, and everything. And then you can use other tools
> which do things like create raw filesystem images or archives, and run
> them in this magic mode, and get raw filesystem images which, dumped to disk
> or flash, actually are working filesystem images with all the right modes.
>
> The concept of porting this to Windows is frankly laughable. I could probably
> get it working on BSD or OS X in about a month, give or take, but I'm not
> totally sure; there's some pretty crazy assumptions in there, although I've
> developed some neat trickery to allow this code to work even if some of the
> "extra" calls it has don't exist on a given target. (e.g., some systems have
> a family of calls with names like "openat()" or "unlinkat()" which allow you
> to operate relative to a directory without having to specify the path to
> that directory, others don't; my program wraps them if they exist, but works
> fine even if they don't.)
>
> Porting this between BSD and SysV in 1989 would have been much harder than
> simply rewriting nearly all of it from scratch completely differently for
> each, if it had even been possible to do it at all. (By 1990, you could
> at least get ELF and dynamic linking on SVR4, so it might have been
> possible there.) So, no, the Linux environment is NOT more fragmented than
> the historical Unix market. They have greater code portability than anything
> we ever saw back then.
>
> -s

So you basically admit its unportable "junk"?

You do realise that dont you?

--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

== 3 of 6 ==
Date: Sat, Feb 13 2010 9:49 am
From: Simon Connah

On 2010-02-13 17:09:17 +0000, Richard said:

> Seebs <usenet-nospam@seebs.net> writes:
>
>> On 2010-02-13, jacob navia <jacob@spamsink.net> wrote:
>>> Seebs a écrit :
>>>> On 2010-02-12, jacob navia <jacob@nospam.org> wrote:
>>>>> Linux is even more fragmented that the different Unix flavors at that time.
>>
>>>> I wrote a hunk of code which has one meaningful #ifdef in it, which is
>>>> working on every Linux system we know of currently available.
>>
>>> First bet:
>>
>>> It doesn't use any GUI
>>
>> Right you are!
>>
>>> Second bet:
>>
>>> It doesn't use any sound/video/multimedia
>>
>> Right you are!
>>
>>> Third bet:
>>
>>> It doesn't use any graphics, or mouse
>>
>> Three for three!
>>
>>> Obviously, THEN... it is portable. But it would be portable to
>>> Mac/windows/whatever too without much pain.
>>
>> And here you've got a Nilges-grade error.
>>
>> <snip>

>> Porting this between BSD and SysV in 1989 would have been much harder than
>> simply rewriting nearly all of it from scratch completely differently for
>> each, if it had even been possible to do it at all. (By 1990, you could
>> at least get ELF and dynamic linking on SVR4, so it might have been
>> possible there.) So, no, the Linux environment is NOT more fragmented than
>> the historical Unix market. They have greater code portability than anything
>> we ever saw back then.
>>
>> -s
>
> So you basically admit its unportable "junk"?
>
> You do realise that dont you?

Unportable != junk.

Some things just have to be tied to a specific operating system. There
is only so much abstraction one can do before one has to get into the
nitty gritty of implementation specific software.

== 4 of 6 ==
Date: Sat, Feb 13 2010 9:53 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <slrnhndmbn.2el.usenet-nospam@guild.seebs.net>, Seebs <usenet-nospam@seebs.net> writes:

> Lemme tell you what this hunk of code is.

This was very interesting, thanks.

> When you first hit one of these functions, it builds itself a table of the
> "next" versions of all these calls (usually the ones in the C library, but
> there could be other similar libraries; we don't care).

I guess you use some kind of static variable (umm, an object of
integer type with static storage duration, internal linkage, file
scope) for checking if the preloaded lib was already initialized. Is
this thread-safe and/or async-signal safe?

Have you considered the "constructor" gcc function attribute?

http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Function-Attributes.html
http://tldp.org/HOWTO/Program-Library-HOWTO/miscellaneous.html#INIT-AND-CLEANUP
http://tldp.org/HOWTO/Program-Library-HOWTO/miscellaneous.html#INIT-AND-FINI-OBSOLETE

As a lame "trick" question, how does the expression look where you
assign the value returned by dlsym(RTLD_NEXT, "open") to your
"orig_open" function pointer? :)

> What this ends up doing is allowing me to intercept every system call that
> deals with the filesystem and is affected by privileges, and act as though
> you had root privileges, or at least, make it look as though it acted as
> though you had root privileges. The client code does this by finding out
> whether it has a server, and if not, starting a server,

What were the arguments against implementing this with FUSE?

Also, how does the client start a server? Does it fork()? Or by
posix_spawn()? Or by messaging a super-server?

Thanks,
lacos

== 5 of 6 ==
Date: Sat, Feb 13 2010 10:02 am
From: Seebs

On 2010-02-13, Simon Connah <simon.connah@googlemail.com> wrote:
> Unportable != junk.

If you are expecting to communicate with one of our standard trolls,
you have missed the point greatly.

> Some things just have to be tied to a specific operating system. There
> is only so much abstraction one can do before one has to get into the
> nitty gritty of implementation specific software.

Exactly. Boot loaders are only marginally portable, but a good boot loader
is EXTREMELY valuable. (This lesson is driven home forcefully once you
have used some bad boot loaders.)

I would guess that I could extend this work to cover other modern Unix-like
systems with a reasonadble amount of effort; I've gone to great lengths to
make large hunks of the code reliable, clean, and portable. But
fundamentally, the task under discussion is inherently constrained to
particular environments.

== 6 of 6 ==
Date: Sat, Feb 13 2010 10:08 am
From: Seebs

On 2010-02-13, Ersek, Laszlo <lacos@ludens.elte.hu> wrote:
> In article <slrnhndmbn.2el.usenet-nospam@guild.seebs.net>, Seebs <usenet-nospam@seebs.net> writes:
>> When you first hit one of these functions, it builds itself a table of the
>> "next" versions of all these calls (usually the ones in the C library, but
>> there could be other similar libraries; we don't care).

> I guess you use some kind of static variable (umm, an object of
> integer type with static storage duration, internal linkage, file
> scope) for checking if the preloaded lib was already initialized. Is
> this thread-safe and/or async-signal safe?

Sort of. Actually, in the versions currently under use, it's not -- there
were no threaded programs we cared about, and the original version simply
ignored threading. The current version is nearly-thread-safe, as long as
one call completes before the various threads start. I could fix that,
but it hasn't been an issue.

> Have you considered the "constructor" gcc function attribute?

No.

> As a lame "trick" question, how does the expression look where you
> assign the value returned by dlsym(RTLD_NEXT, "open") to your
> "orig_open" function pointer? :)

I don't. :)

What I have is:

1. I define a function named open() with the same signature as the syscall.
2. I define a function named dummy_open() with that same signature, too.
3. I define a pointer-to-function named real_open() with the same signature.
4. I define a function named wrap_open() with the same signature.

My open() looks roughly like
if (setup_wrappers()) {
if (get_lock()) {
if (magic_mode)
wrap_open(args);
else
real_open(args);
drop_lock()
} else {
fail
}
} else {
dummy_open();
}

The "magic mode" thing is so that the library internals can bypass all
this magic, and is one of the reasons we need thread safety -- otherwise,
a second thread making calls while a first one has turned off the magic
will bypass the magic unintentionally. (Interestingly, if this imposes
a performance cost, I can't measure it.)

> What were the arguments against implementing this with FUSE?

Long story. Basically, it turns out to be very useful to be able to do
this in arbitrary directories without requiring special hackery, and as
I recall, FUSE requires that you have at SOME point had root privileges
to set up the mounting. This one can be configured, installed, and used
without ever having any special privileges. Also, I think we support at
least one host without FUSE support!

> Also, how does the client start a server? Does it fork()? Or by
> posix_spawn()? Or by messaging a super-server?

The client forks.

==============================================================================
TOPIC: Motivation of software professionals
http://groups.google.com/group/comp.lang.c/t/21a3fdec4dd53e6a?hl=en
==============================================================================

== 1 of 8 ==
Date: Sat, Feb 13 2010 8:58 am
From: Arved Sandstrom

Seebs wrote:
> On 2010-02-12, Arved Sandstrom <dcest61@hotmail.com> wrote:
>> In a similar vein, what about the free software around which an
>> ecosystem of "support" developers has grown, who sell their expertise in
>> deploying the software in a client environment, or doing a job for a
>> client using the program?
>
> Well, in that case, I think you might have a contract. $DAYJOB sells stuff
> which is in large part "linux and free software", but there are contractual
> terms above and beyond the stuff given in the license.
>
> But if you don't like it, you talk to us about the contract under which you
> bought it, not to Mr. Torvalds.
>
>> Even more specifically, what about software
>> given out for free, around which the _author_ offers such support
>> services? This practise is not uncommon. By doing so, has not the author
>> implicitly guaranteed the fitness of his application? How can he then
>> simultaneously provide the program free of charge for anyone who wants
>> it, and claim that it is so unreliable that he can offer no guarantees
>> for it? This is rather at odds with his own use of it in a commercial
>> setting.
>
> I don't think so. If you want a guarantee, you buy it. If you didn't
> buy anything, you haven't established a commercial relationship giving you
> a reasonable expectation of support or fitness for a particular purpose;
> after all, the entire point of selling support is to sell the promise that
> you'll make it fit for a particular purpose if it isn't, which it might
> not be.
>
> -s

Everything you say is regrettably where our field is at right now. Which
is pretty sad.

The whole point of the discussion was, I thought, to see if we can't do
better than this. I don't have all the answers, and I don't purport to
have all the answers. I am simply describing what I see to be a
desirable goal, that of an elevated level of professionalism in our
field. I don't think we'll get there by just hoping that individuals do
a better job.

AHS

== 2 of 8 ==
Date: Sat, Feb 13 2010 9:02 am
From: Seebs

On 2010-02-13, Arved Sandstrom <dcest61@hotmail.com> wrote:
> The whole point of the discussion was, I thought, to see if we can't do
> better than this. I don't have all the answers, and I don't purport to
> have all the answers. I am simply describing what I see to be a
> desirable goal, that of an elevated level of professionalism in our
> field. I don't think we'll get there by just hoping that individuals do
> a better job.

Perhaps, but I think it's important to understand that there are sound reasons
for which free software is in many cases much more "professional" than
commercial software, and there are sound reasons for which it would be
completely crippling to our industry to make it harder, rather than easier,
to make and distribute free software.

== 3 of 8 ==
Date: Sat, Feb 13 2010 9:42 am
From: Brian

On Feb 13, 6:19 am, James Kanze <james.ka...@gmail.com> wrote:
> On 12 Feb, 22:37, Arved Sandstrom <dces...@hotmail.com> wrote:
>
>
>
>
>
> > Seebs wrote:
> > > On 2010-02-12, Leif Roar Moldskred <le...@huldreheim.homelinux.org> wrote:
> > >> In comp.lang.java.programmer Brian <c...@mailvault.com> wrote:
> > >>> That is true in a traditional model of exchanging money
> > >>> for a product or service. If you don't pay for the good
> > >>> or service, you have no "rights."
> > >> That's quite simply not correct.
> > > It had better become correct, if we don't want to trash all
> > > our economies again.
> > > If you have liabilities to people who grabbed free stuff off
> > > the internet labeled as providing no warranty, no one can
> > > afford to give anything away, and it turns out that there's
> > > a huge economic efficiency boost to allowing people to give
> > > away software. Solution: Let people give away software
> > > with no liability or warranty.
> > I don't think we know anything of the sort. If software is
> > needed it gets written, free or with a price tag. And you
> > can't ignore the huge economic inefficiencies occasioned by
> > having copious amounts of turgid broken crap available for
> > free, that wastes everyone's time.
>
> The problem is that we already have copious amounts of turgid
> broken crap available commercially. I don't see why adding free
> software to the mix changes anything.
>
> Logically, I think that most of the techniques necessary for
> making really high quality software would be difficult to apply
> in the context of a free development. And at least up to a
> point, they actually reduce the cost of development.

I'm not sure what you are referring to, but one thing we
agree is important to software quality is code reviewing.
That can be done in a small company and I'm sometimes
given feedback on code in newsgroups and email.

> So
> theoretically, the quality of commercial software should be
> considerably higher than that of free software. Practically,
> when I actually check things out... g++ is one of the better C++
> compilers available, better than Sun CC or VC++, for example.

Maybe now that Sun CC and VC++ are free they'll improve. :)
I'm not sure about Sun CC, but guess that it is free with
Open Solaris. Still I'm not comfortable with g++'s foundation.
I would like to think that VC++, written mostly in C++, is at
least able to produce a draw when up against g++.

> > I think you'd find that if there was much less free stuff
> > available that we'd have a _different_ economic model, not
> > necessarily a _worse_ one.
>
> There used to be a lot less free stuff available, and it was
> worse. (It doesn't make sense to me, either, but those are the
> facts.)
>
>
> > I have no idea why you think that warranties and liabilities
> > are going to lead to the financial ruination of countless
> > developers. People in other sectors sell millions or tens of
> > millions of other imperfect things, with warranties, and they
> > seem to be making a living.
>
> I think that part of the problem is that a mistake in a program
> will affect every instance of the program. Most recalls for
> cars, on the other hand, only affect a small subset of the total
> production.
>

That may be a reason why an on line approach makes sense.
Since you haven't shipped out instances of the program,
just make sure the instances that exist on your servers
are corrected. The other way, a court in a distant country
might hold you liable if some customers didn't receive a
message that they should update their copy.

Brian Wood
http://webEbenezer.net
(651) 251-9384

== 4 of 8 ==
Date: Sat, Feb 13 2010 9:52 am
From: spinoza1111

On Feb 5, 7:19 pm, Stefan Kiryazov <stefan.kirya...@gmail.com> wrote:
> Hi all,
>
> I am doing a research about motivation in software development, the
> most efficient practices to motivate software engineers, their
> popularity, etc.
>
> As a part of the research, I am doing an online survey for software
> engineers and managers in software development. It takes just several
> minutes and filling it is a good opportunity to share your opinion
> about the motivation practices being used in the software industry
> today:http://ask.wizefish.com/en/MotivationSurvey.aspx
>
> Anyone who does the survey and leaves any contacts will be sent the
> results.
>
> Also, if someone is running a web site or blog dedicated to any aspect
> of software development we can do some link exchange.
>
> Regards,
> Stefan Kiryazov

(Sigh)

To understand software professionals you have to understand software.

Why do psychologists and MBAs not understand that to really do an
adequate job at "studying" a fully huamn endeavor both from the
standpoint of decency-towards-others and mere truth, they have to do
what (some) anthropologists call "thick description" and also
"participant observer"?

Anthropologist Diane Vaughan successfully studied a technical
phenomenon: the crash of the Challenger Space Shuttle. She did so as a
participant observer and using thick description, not questionnaires
with all sorts of hidden bias, including the basic bias of a
questionnaire: the people who respond to it are the sort of people who
actually like answering questionnaires.

== 5 of 8 ==
Date: Sat, Feb 13 2010 9:56 am
From: Arved Sandstrom

Seebs wrote:
> On 2010-02-13, Arved Sandstrom <dcest61@hotmail.com> wrote:
>> The whole point of the discussion was, I thought, to see if we can't do
>> better than this. I don't have all the answers, and I don't purport to
>> have all the answers. I am simply describing what I see to be a
>> desirable goal, that of an elevated level of professionalism in our
>> field. I don't think we'll get there by just hoping that individuals do
>> a better job.
>
> Perhaps, but I think it's important to understand that there are sound reasons
> for which free software is in many cases much more "professional" than
> commercial software, and there are sound reasons for which it would be
> completely crippling to our industry to make it harder, rather than easier,
> to make and distribute free software.
>
> -s

Let's take it as a given that free software has a decent model. I've
been, and still am, a participant in the process of creating free
software, and I wouldn't do that if it wasn't a good model. However, the
main problem with it is that it engages only a small fraction of all
software developers, and accounts for only a very small fraction of all
software that is written.

I can also think of many cases where free software, even when absorbing
the attention of many enthusiastic and competent developers, does not
compare favourably to commercial equivalents. Free software is not a
superior model except insofar as where a particular problem attracts
enough above-average developers with time on their hands, they have good
synergy, and they stay the course.

As you say, and what I agree with, the successful free software seems to
have settled into the areas of infrastructure and also common programs
(like office suites and image editing, as a few examples). That latter
category is also infrastructure in a way.

But the real problem, which is not addressed by free software, and which
comprises the huge majority of all software, is custom stuff. And it is
this category that suffers, and suffers badly, from the lack of
professionalism in our field. It is this category where clients would
benefit from having proven, guaranteed quantities when it comes to
employees/contractors and products.

AHS

== 6 of 8 ==
Date: Sat, Feb 13 2010 10:00 am
From: Seebs

On 2010-02-13, Arved Sandstrom <dcest61@hotmail.com> wrote:
> Let's take it as a given that free software has a decent model. I've
> been, and still am, a participant in the process of creating free
> software, and I wouldn't do that if it wasn't a good model. However, the
> main problem with it is that it engages only a small fraction of all
> software developers, and accounts for only a very small fraction of all
> software that is written.

Agreed.

But it's crucial infrastructure, and any policy discouraging it would deal
immense damage to fundamental infrastructure.

People *MUST* be free to give code away without any kind of liability.

> I can also think of many cases where free software, even when absorbing
> the attention of many enthusiastic and competent developers, does not
> compare favourably to commercial equivalents. Free software is not a
> superior model except insofar as where a particular problem attracts
> enough above-average developers with time on their hands, they have good
> synergy, and they stay the course.

Sure. But... The set of things that can be done well as free software has
consistently increased over time. It was not that long ago that people would
grant that emacs was a good editor, but insist that you couldn't do a decent
free compiler. Then it was possible to do a decent free compiler, but not a
decent free operating system. Then it was word processors.

> But the real problem, which is not addressed by free software, and which
> comprises the huge majority of all software, is custom stuff. And it is
> this category that suffers, and suffers badly, from the lack of
> professionalism in our field. It is this category where clients would
> benefit from having proven, guaranteed quantities when it comes to
> employees/contractors and products.

And if it were possible to measure the things we really care about, that
might be very useful. But it appears not to be.

That said, I agree that it would make sense to increase the scope of
prospective liability *for commercial software*. That is to say, if you
are paying for software, it may make sense to create a relationship in
which there could be liability.

But if you add liability to software which is given away for free, it
will destroy our infrastructure.

People who create contractual relationships can put liability clauses in
them, and often do. That works fine. It might be nice to set minimum
liability or warranty on software which is paid for, though. For instance,
I wouldn't see any big risk to our society if there were a minimum cap
of the full purchase price of software for damage done by faults in that
software. (As in, no matter what the contract says, if it does damage, you
can recoup that damage, up to the full purchase price.) We'd need to address
some of the craziness of licensing and so on...

But fundamentally, the problem is a lot more with Microsoft and the EULA model
than it is with free software, and any proposed "fix" which would cripple free
software while Microsoft could continue to run roughshod over it is clearly
not a good fix.

I think that if we had a working liability model for commercial software, the
market would probably be able to develop working models for how to determine
whether developers were competent. Right now, the primary problem isn't that
we can't determine whether developers are competent, it's that people don't
particularly care.

== 7 of 8 ==
Date: Sat, Feb 13 2010 10:07 am
From: LR

James Kanze wrote:
> On Feb 11, 9:33 pm, Andy Champ <no....@nospam.invalid> wrote:
>> Lew wrote:
>
>>> Andy Champ wrote:
>>>> In 1982 the manager may well have been right to stop them
>>>> wasting their time fixing a problem that wasn't going to be
>>>> a problem for another 18 years or so. The software was
>>>> probably out of use long before that.
>
>>> Sure, that's why so many programs had to be re-written in 1999.
>
>>> Where do you get your conclusions?
>
>> Pretty well everything I saw back in 1982 was out of use by
>> 1999. How much software do you know that made the transition?
>
>> Let's see.. Operating systems. The PC world was... umm.. CP/M
>> 80? Maybe MS-Dos 1.0? And by 1999 I was working on drivers
>> for Windows 2000. That's at least two, maybe three depending
>> how you count it, ground-up re-writes of the OS.
>
>> With that almost all the PC apps had gone from 8 bit versions
>> in 64kb of RAM to 16-bit DOS to Windows 3.1 16-bit with
>> non-preemptive multitasking and finally to a 32-bit app with
>> multi-threading and pre-emptive multitasking running in
>> hundreds of megs.
>
>> OK, so how about embedded stuff? That dot-matrix printer
>> became a laserjet. The terminal concentrator lost its RS232
>> ports, gained a proprietary LAN, then lost that and got
>> ethernet. And finally evaporated in a cloud of client-server
>> computing smoke.
>
> The "standard" life of a railway locomotive is thirty or fourty
> years. Some of the Paris suburbain trainsets go back to the
> early 1970's, or earlier, and they're still running.

Do you happen to know if they've undergone any engineering changes over
those 40 years for safety or performance enhancements?

With worn/damaged parts replacement how much of the original equipment
remains? Wheel sets, motors, controls, seats, doors, couplers,
windshields, etc. all get inspected and replaced on schedule.

Not all locomotives last 40 years.

Design flaws can contribute to a shorter life. For example the Erie Triplex.
http://www.dself.dsl.pipex.com/MUSEUM/LOCOLOCO/triplex/triplex.htm

Although design flaws played a part in the death of the Jawn Henry, I've
heard that N&W's business was undergoing changes and undercut the
companies desire to invest in coal fired power.
http://www.dself.dsl.pipex.com/MUSEUM/LOCOLOCO/nwturbine/nflkturb.htm

>> Where do you get your conclusions that there was much software
>> out there that was worth re-writing eighteen years ahead of
>> time?

To continue with our locomotives, the replacement of coal fired steam by
diesel and electric (No, no, not this one:
http://www.dself.dsl.pipex.com/MUSEUM/LOCOLOCO/swisselec/swisselc.htm ;)
) power was largely driven by maintenance cost, the sort that replaces
the lubricating oil, not the kind that replaces faulty brake systems,
although this played a role too. It's nice to be able to buy parts OTS
if you need them rather than have a huge work force ready to make parts.

I think ultimately the RRs asked themselves if they were in the
locomotive business or the transportation business.

== 8 of 8 ==
Date: Sat, Feb 13 2010 10:32 am
From: Leif Roar Moldskred

In comp.lang.java.programmer Seebs <usenet-nospam@seebs.net> wrote:
>
> Agreed.
>
> But it's crucial infrastructure, and any policy discouraging it would deal
> immense damage to fundamental infrastructure.
>
> People *MUST* be free to give code away without any kind of liability.

Why? We're not today, and the gears of the open source engine appears fairly
well greased regardless.

--
Leif Roar Moldskred

==============================================================================
TOPIC: Efficency and the standard library
http://groups.google.com/group/comp.lang.c/t/ad9fea19f2f7dd61?hl=en
==============================================================================

== 1 of 10 ==
Date: Sat, Feb 13 2010 9:22 am
From: spinoza1111

On Feb 14, 12:21 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-02-13, Tim Streater <timstrea...@waitrose.com> wrote:
>
> > On 13/02/2010 10:30,spinoza1111wrote:
> >> My code is hard to read, it is said (on dit). In a sense, it is. I
> >> find it hard to read at times myself.
> > Then it's shitty code, pure and simple.
>
> Pretty much. Why did multiple attempts at getting the Nilges string
> replacement code debugged fail after hours of effort? Because it was hard

You're lying: the console output from the current version is at the
end of this response. Also, the next time you start a thread using the
word "efficiency", use a dictionary.

You and Richard Heathfield need to LEAVE. This is because you both
have a track record of LYING in this and other newsgroups because you
are using them DISHONESTLY to advance yourself in a profession for
which you are not qualified.

> to read. Code which is hard to read is hard to maintain. Code which is
> hard to maintain will start buggy. It will remain buggy despite debugging
> efforts. It will become buggy whenever feature work needs to be done.
>
> This ties in some to the debate about "software engineering". What would
> people think of someone who claimed to be an "engineer", but who designed
> bridges so elaborately complicated that no one could figure out which parts
> were load-bearing?

I don't claim to be an engineer. Do you, oh finder and sender on of
bugs who could not find the bugs in my code? If I were your manager, I
would in fact be very concerned that you could not do so when to do so
would have scored the points you so pathetically try to score here.

Software engineering is "how to program if you cannot", as Dijkstra
has said. You might need it. I don't. But you are by no stretch of the
imagination, an "engineer". Real engineers don't lie, because in
genuine engineering jobs, as opposed to computing jobs which in many
cases constitute welfare for white males, you lie like you do, you GO
TO JAIL.

>
> This is why I don't take Nilges seriously when he rants about the design
> of C. He's demonstrated conclusively that he has no clue about competent
> design, and someone who can't build even simple programs correctly is not
> qualified to comment on any programming language.

You're lying. This thread in fact makes me very glad that I am no
longer a programmer, for commencing with the election of Reagan, I saw
the entry of people like you destroy workgroups and companies. I saw
the hiring of unqualified people (some with psychology in place of
compsci degrees, and, worse, zero interest in autodidactic computer
science) destroy the Mountain View site of Bell Northern Research.
Structured walkthroughs became savage and inane by turns, unqualified
people took trips and junkets, and around Christmas of 1985, while I
was working late on a 24 bit version of the SL.1 compiler, a holiday
party in another part of the building was ending in property damage
and drunken fistfights.

I saw people like you (including self-hating homosexuals) destroy
Catapult Software Training's Chicago office with your type of lies, as
well.

For let us not speak falsely now the hour is much too late.

You're lying. The code I posted and in which I have fixed all problems
reported to date has worked better than anything you've posted, and
YOU NEVER FIXED the %s bug that was in the code that started this
discussion! The other code samples you posted contained bugs, but your
rule seems to be "my mistakes must be forgiven, the 'heap' is a DOS
term, but if anyone I don't like, or need to ass-kiss, makes a
mistake, I'll be on his errors like a fly on shit".

Anyone here can go to the code a few posts above and download it,
compile and run it to get the following console output to verify that
you are lying, as you lied maliciously and libelously about Herb
Schildt, damaging his reputation in order to create a dishonest
impression that you are a qualified programmer, which YOU ARE NOT.

I have carefully documented how the Google Groups browser may make
minor modifications which a competent technician, WHICH YOU ARE NOT,
can fix them. Whereas you created a new thread, misspelling its title,
that started with a lie and here, continues with a lie. The code you
posted is crap and doesn't solve the problem which was to do the
replace() without using string.h.

You talk about "software quality" in the corporate register which must
of necessity take ownership of the term while not ever admitting that
the speaker-writer may not know his ass from a hole in the ground.
This is the register of people who do not know their trade and who are
complete frauds.

Whereas I am discussing a real programming problem, and working with
the real professionals here, like Ike Naar, Santosh, IO_x, and
Bacarisse, I have been able AS INTENDED to debug collaboratively
showing twerps like you (who isn't, apparently, trusted to actually
code real software at his job) how it's done. I've got the code into
the state it's in, no thanks to you, where it does, I believe, the
minimal amount of work without requiring the tables that more advanced
algorithms require.

This display of competence and professionalism, by someone returning
to C after almost 20 years, along with the competence and
professionalism of Naar, Santosh, et al., has exposed you and you are
lashing out with lies, Lash Larue.

The jig is up.

Replace

Replace "111123" by "ono" in
"1111123bbb1111123bbb11123bb11111231111112111111123"
Expect "1onobbb1onobbb11123bb1ono1111112111ono":
"1onobbb1onobbb11123bb1ono1111112111ono"
Replacements expected: 4: replacements: 4

Replace "111123" by "ono" in "bbb1111123bbbbb"
Expect "bbb1onobbbbb":
"bbb1onobbbbb"
Replacements expected: 1: replacements: 1

Replace "stupid error" by "miracle" in "a stupid error"
Expect "a miracle":
"a miracle"
Replacements expected: 1: replacements: 1

Replace "stupid" by "miracle" in "a stupid error"
Expect "a miracle error":
"a miracle error"
Replacements expected: 1: replacements: 1

Replace "the stupid error" by "a miracle" in "the stupid error"
Expect "a miracle":
"a miracle"
Replacements expected: 1: replacements: 1

Replace "the" by "a" in "the miracle"
Expect "a miracle":
"a miracle"
Replacements expected: 1: replacements: 1

Replace "snirpKamunkle" by "e" in "a miraclsnirpKamunkle"
Expect "a miracle":
"a miracle"
Replacements expected: 1: replacements: 1

Replace "a miracle" by "" in "a miraclesnirpKamunkle"
Expect "snirpKamunkle":
"snirpKamunkle"
Replacements expected: 1: replacements: 1

Replace "a miracle" by "" in " a miraclesnirpKamunkle"
Expect " snirpKamunkle":
" snirpKamunkle"
Replacements expected: 1: replacements: 1

Replace "a miracle" by "" in " a miraclesnirpKamunklea miraclea
miracle"
Expect " snirpKamunkle":
" snirpKamunkle"
Replacements expected: 3: replacements: 3

Replace "a miracle" by "" in "a miracle a miraclesnirpKamunkle a
Miraclea miraclea miracle"
Expect " snirpKamunkle a Miracle":
" snirpKamunkle a Miracle"
Replacements expected: 4: replacements: 4

Replace "stupid error" by "miracle" in "a stupid errord"
Expect "a miracled":
"a miracled"
Replacements expected: 1: replacements: 1

Replace "stupid error" by "miracle" in "a stupid errod"
Expect "a stupid errod":
"a stupid errod"
Replacements expected: 0: replacements: 0

Replace "stupid error" by "miracle" in "a sstupid error"
Expect "a smiracle":
"a smiracle"
Replacements expected: 1: replacements: 1

Replace "stupid error" by "miracle" in "a stupid errorstupid error"
Expect "a miraclemiracle":
"a miraclemiracle"
Replacements expected: 2: replacements: 2

Replace "stupid error" by "miracle" in "a stupid error stupiderror"
Expect "a miracle stupiderror":
"a miracle stupiderror"
Replacements expected: 1: replacements: 1

Replace "b" by "a" in "bbbbbbbbbb"
Expect "aaaaaaaaaa":
"aaaaaaaaaa"
Replacements expected: 10: replacements: 10

Replace "%s" by "Cthulu" in "In the halls of R'yleh great %s lies
dreaming"
Expect "In the halls of R'yleh great Cthulu lies dreaming":
"In the halls of R'yleh great Cthulu lies dreaming"
Replacements expected: 1: replacements: 1

Replace "%s" by "Cthulu" in "%s%s%s%s%s%s"
Expect "CthuluCthuluCthuluCthuluCthuluCthulu":
"CthuluCthuluCthuluCthuluCthuluCthulu"
Replacements expected: 6: replacements: 6

Replace "ana" by "oat" in "banana"
Expect "boatna":
"boatna"
Replacements expected: 1: replacements: 1

Replace "stupid error" by "+" in " a stupid errorstupid errorHeystupid
errors"
Expect " a ++Hey+s":
" a ++Hey+s"
Replacements expected: 3: replacements: 3

Replace "foo bar" by "bas" in "foo barfoo barf"
Expect "basbasf":
"basbasf"
Replacements expected: 2: replacements: 2

Replace "ba" by "ba" in "abab"
Expect "abab":
"abab"
Replacements expected: 1: replacements: 1

Replace "bab" by "boop" in "abab"
Expect "aboop":
"aboop"
Replacements expected: 1: replacements: 1

Replace "ana" by "ono" in "banana"
Expect "bonona":
"bonona"
Replacements expected: 1: replacements: 1

Replace "x" by "b" in "a"
Expect "a":
"a"
Replacements expected: 0: replacements: 0

Replace "x" by "b" in "x"
Expect "b":
"b"
Replacements expected: 1: replacements: 1

Replace "egregious" by "egregious" in "egregious"
Expect "egregious":
"egregious"
Replacements expected: 1: replacements: 1

Replace "egregious" by "x" in "egregious"
Expect "x":
"x"
Replacements expected: 1: replacements: 1

Testing complete: check output carefully: "Assertion failed" should
not occur!

== 2 of 10 ==
Date: Sat, Feb 13 2010 9:36 am
From: spinoza1111

On Feb 13, 10:21 pm, Tim Streater <timstrea...@waitrose.com> wrote:
> On 13/02/2010 11:53,spinoza1111wrote:
>
> > On Feb 13, 6:43 pm, Tim Streater<timstrea...@waitrose.com> wrote:
> >> On 13/02/2010 10:30,spinoza1111wrote:
>
> >>> My code is hard to read, it is said (on dit). In a sense, it is. I
> >>> find it hard to read at times myself.
>
> >> Then it's shitty code, pure and simple.
>
> > That is the common view. I regard it as self-indulgent. Who says you
> > can read code?
>
> The fact that I can write it. The fact that I am (purely for my own
> amusement) nearly done with writing an e-mail user-agent (not in C and
> not likely to be seen off my own Mac). The fact that at SLAC more than
> 20 years ago, I wrote a software package (30k lines of C) to control and
> gather statistics from a number of similar digital switches, running on
> a MicroVAX. Some parts of the code ran on other VAXes (VMS) and IBM
> mainframes under VM/CMS.
>
> To do this we:
>
> 1) Used the Xerox suite of network protocols (IP not then being in the
> ascendency).
>
> 2) Adapted a commercial threads microkernel (written in C) to run under
> VMS and VM/CMS (note: we had no portability issues with the C). We had
> to write a small amount of assembler for each host type (and fix a
> number of bugs we found inside VM/CMS, mostly to do with timer handling).
>
> Note also that all the C code written for this project was re-entrant (a
> feature heavily used in the project). And we had no problems with that
> either.
>
> I could also throw in the assets database and associated front end (not
> written in C) done at my last employer before retiring, but I can't be
> bothered.
>
> I might also point out that I was with each of my three employers for 15
> years and left each voluntarily.
>
> So, all in all, I think it can be said that I can read code.

Doesn't follow, at all. In fact, many programmers have attention-
hyperactivity disorder that makes them prefer to write new code rather
than make the longer, more focused, and more empathic effort to read,
tolerate, connect-with and finally understand The Code of the Other.

When I started in programming, in fact, I was struck by the sheer
number of nervous disorders and tics of my coworkers, although they
were a refreshing change of pace from my own. I was especially struck
by how many programmers seemed to have math anxiety. I taught a C
class in 1990: one commenter said "he uses too much math", which was
just nuts if you ask me.

Most famously Larry Ellison, the CEO of Oracle, had by his own account
AHD and by his own account succeeded at a famously difficult Fortran
class at the University of Illinois because as opposed to other
"boring" classes, he could focus for short but sharp amounts of time
on writing new code, which then as now is the focus in university
programming courses. I had the same experience at roughly the same
time, writing a bug free machine language program as my first program
ever on a freezing night at Northwestern's library.

But I found it harder to tolerate The Code of the Other, in my case
because the first Code of the Other I encountered was genuinely poor
code. I had to cultivate the skill at Bell Northern Research where I
inherited a mass of compilers and tools, that were written by
extremely bright people in Ottawa (celebrated in a book, now out of
print, called Knights of the New Technology).

This is why I have always been skeptical of the unprovable claim that
code (or English text) is "hard to read", which is phrased as an
innate property of the text, and not of the relation of the reader to
the text. It is based on a primitive, lower middle class, almost
magical "theory" of the text in which the text, like the Bible of the
fundamentalist, must give a singular answer, in the style and
shibboleths of the reader, and if it does not, then it's the author's
fault.

In fine, I really don't care that you've been a faithful employee of
three firms and written a lotta code. That may be admirable, and
thanks for sharing, but it doesn't make you an authority on software
readability.
>
> --
> Tim
>
> "That the freedom of speech and debates or proceedings in Parliament
> ought not to be impeached or questioned in any court or place out of
> Parliament"
>
> Bill of Rights 1689

== 3 of 10 ==
Date: Sat, Feb 13 2010 9:47 am
From: ram@zedat.fu-berlin.de (Stefan Ram)

Richard Heathfield <rjh@see.sig.invalid> writes:
>long strLength(const char *s)

ISO C 90 might contain a provision stating that:

»The implementation may further restrict the
significance of an external name (an identifier that has
external linkage) to six characters and may ignore
distinctions of alphabetical case for such names«.

(This text was copied from a draft, but I remember
having read this in the ANSI document, too.)

== 4 of 10 ==
Date: Sat, Feb 13 2010 9:59 am
From: Ben Bacarisse

Richard <rgrdev_@gmail.com> writes:

> Tim Streater <timstreater@waitrose.com> writes:
>
>> On 13/02/2010 10:30, spinoza1111 wrote:
>>
>>> My code is hard to read, it is said (on dit). In a sense, it is. I
>>> find it hard to read at times myself.
>>
>> Then it's shitty code, pure and simple.
>
> Some of the best code I have dealt with turned out to need a while to
> acclimatise to.
>
> One should NEVER program to the lowest common denominator such as Bill
> Cunningham for example.
>
> There appears to be some strange opinion here that ALL code is
> constantly being read by hundreds of people as the brilliance of your
> output is ported and modded to 1000s of platforms and new projects. It
> isn't. Far better to have a small routine complex but EFFICIENT that
> "easy to read" and a dog. Complex? Comment it.

All code has at least one important reader -- the author. What odds
do you give that version 11 of this code (if I've counted correctly) is
finally bug free?

--
Ben.

== 5 of 10 ==
Date: Sat, Feb 13 2010 10:15 am
From: Richard Heathfield

spinoza1111 wrote:
> On Feb 13, 7:22 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> spinoza1111wrote:
>>
>> <snip>
>>
>> I see you've ditched malloc.h, so here are my next two observations:
>
> "When everything is ended, you come." - Shakespeare, Henry IV part 2

Yeah. And at *this* point, when you think you've fixed it all up just
so, it's still easy to suggest improvements in your code.

>
> ....dishonestly, like Falstaff, seeking glory.

The glory involved in pointing out improvements in your code is about at
the same level as the glory involved in peeling a banana.

> I find it hard to
> believe that you've been keeping grave observations in reserve,

And indeed I haven't. When I saw a copy of the code that demonstrated
you'd learned from my first observation, I looked at the code
sufficiently closely to find a couple more observations. If you show any
sign of learning from those, I'll offer some more. But I don't save them
up. Experience teaches me that you are not a quick learner.

> since you found no bugs,

I haven't looked yet.

> and would have been as my arch-enemy

I'm not your arch-enemy. You are.

> happy to do so
> (stylistic observations about pseudo-portability don't count, and
> there were several juicy bugs, none of which you were able to find).

<shrug> I didn't look.

Now let's see if you were paying attention.

>>> // Calculate string length
>>> //
>>> //
>>> long strLength(char *strInstring)
>>> {
>>> char *ptrInstring;
>>> for (ptrInstring = strInstring; *ptrInstring; ptrInstring++);
>>> return ptrInstring - strInstring;
>>> }
>> Simpler, and slightly more informative to the caller:
>>
>> long strLength(const char *s)
>> {
>> long len = 0;
>> while(*s++) ++len;
>> return len;
>>
>> }
>
> I'm massively underwhelmed.

Yeah, I know.

> It's "simpler" only in having fewer
> characters in the source code,

I should have realised that its lack of verbosity would appear to you to
be a weakness rather than a strength.

> and this isn't what we mean by
> simplicity; mathematics isn't "simple and readable" in the way we
> want. Your code saves one assignment: I'll alert the media.

Good programming is made up of many good decisions.

> Integrating the increment of s with the test is what you would call
> "confusing code" if anyone other than you'd written it,

No, it's a standard C idiom. You'll find it in K&R, for example.

> because you're a narcissist.

Ah, you've been taught another new word. Here's yet another: projection.

> It defeats what purpose there is in the C for loop,
> which was to disambiguate the three parts of a loop. It did so poorly,
> but your use manages to make a bad situation worse.

But I didn't even use a for loop! It's not necessary here.

> If you can write "len", you can write "length". "len" could be
> anything.

It could, for example, be length.

> Initializing len in its declaration-definition will not even compile
> on some C compilers.

Rubbish. Any conforming implementation is required to support
initialisation syntax.

> I thought you wrote portable code. Oh well.

I do. You don't know what it means.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 6 of 10 ==
Date: Sat, Feb 13 2010 10:17 am
From: Richard Heathfield

spinoza1111 wrote:
> On Feb 13, 8:18 pm, Richard <rgrd...@gmail.com> wrote:
>> Richard Heathfield <r...@see.sig.invalid> writes:
>>> spinoza1111wrote:
>>> <snip>
>>> I see you've ditched malloc.h, so here are my next two observations:
>>>> // Calculate string length
>>>> //
>>>> //
>>>> long strLength(char *strInstring)
>>>> {
>>>> char *ptrInstring;
>>>> for (ptrInstring = strInstring; *ptrInstring; ptrInstring++);
>>>> return ptrInstring - strInstring;
>>>> }
>>> Simpler, and slightly more informative to the caller:
>>> long strLength(const char *s)
>>> {
>>> long len = 0;
>>> while(*s++) ++len;
>>> return len;
>>> }
>> An unnecessary increment on every loop. Potentially expensive for long
>> blocks. Nilges might be faster in many cases.
>
> Whoa, missed that.

You also missed my advice (upthread) to ditch the function completely
and use the standard library, which will wipe the floor with both versions.

> Thanks for pointing this out. The count is four.

Don't believe everything you read.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 7 of 10 ==
Date: Sat, Feb 13 2010 10:21 am
From: Richard Heathfield

Tim Streater wrote:
> On 13/02/2010 11:53, spinoza1111 wrote:
>> On Feb 13, 6:43 pm, Tim Streater<timstrea...@waitrose.com> wrote:
>>> On 13/02/2010 10:30,spinoza1111wrote:
>>>
>>>> My code is hard to read, it is said (on dit). In a sense, it is. I
>>>> find it hard to read at times myself.
>>>
>>> Then it's shitty code, pure and simple.
>>
>> That is the common view. I regard it as self-indulgent. Who says you
>> can read code?
>
> The fact that I can write it.

I doubt whether anyone would question it, other than spinoza1111 and the
trolls, and their opinion is of no moment.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

== 8 of 10 ==
Date: Sat, Feb 13 2010 10:17 am
From: Seebs

On 2010-02-13, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Richard <rgrdev_@gmail.com> writes:
>> There appears to be some strange opinion here that ALL code is
>> constantly being read by hundreds of people as the brilliance of your
>> output is ported and modded to 1000s of platforms and new projects. It
>> isn't. Far better to have a small routine complex but EFFICIENT that
>> "easy to read" and a dog. Complex? Comment it.

> All code has at least one important reader -- the author. What odds
> do you give that version 11 of this code (if I've counted correctly) is
> finally bug free?

The assumption that efficient code must be hard to read, or that efficiency
is likely to make code hard to read, is unsupported.

The problem with the Nilges string replace program is largely that the design
is gratuitously complicated. However, simply choosing remotely reasonable
names for the ptrIndex* variables would probably have addressed a great deal
of it. If you're constantly flipping back to see what something points to,
that suggests that you're doing it wrong.

Furthermore, the performance of his algorithm is likely to be unbelievably
bad, because on most systems, the overhead of malloc/free pairs is noticably
larger than the overhead of searching an entire string several times. So it's
not even actually efficient.

In general, you should write things for clarity first. Once you have
something which clearly works and is well-understood and tested, THEN it
is time to start thinking about such questions as "is it fast enough". If
not, then you profile to find out where the time goes. THEN you see whether
it's time to rewrite something.

But even if you're writing for efficiency, it's not usually necessary to
write unclear code. Contrary to popular belief, the execution time of code
is not harmed by indentation, decent variable naming conventions, or the
like. On modern compilers, intermediate variables are likely free too, so
writing for clarity by, say, giving a name to a particular intermediate
value, doesn't usually hurt performance.

As is usually the case, "Richard" (no last name) is apparently trolling,
stupid, or both.

== 9 of 10 ==
Date: Sat, Feb 13 2010 10:19 am
From: Seebs

On 2010-02-13, Richard Heathfield <rjh@see.sig.invalid> wrote:
> spinoza1111 wrote:
>> On Feb 13, 8:18 pm, Richard <rgrd...@gmail.com> wrote:
>>> Richard Heathfield <r...@see.sig.invalid> writes:
>>>> Simpler, and slightly more informative to the caller:
>>>> long strLength(const char *s)
>>>> {
>>>> long len = 0;
>>>> while(*s++) ++len;
>>>> return len;
>>>> }

>>> An unnecessary increment on every loop. Potentially expensive for long
>>> blocks. Nilges might be faster in many cases.

>> Whoa, missed that.

> You also missed my advice (upthread) to ditch the function completely
> and use the standard library, which will wipe the floor with both versions.

Typically, yes.

That said, I do like the idiom
size_t lenstr(char *string) {
char *end = string;
while (*end++)
;
return end - string;
}

Not that it's likely to make a noticeable difference. Or that it's likely
worth it when obviously the standard library one will be fine.

== 10 of 10 ==
Date: Sat, Feb 13 2010 10:25 am
From: Richard Heathfield

Stefan Ram wrote:
> Richard Heathfield <rjh@see.sig.invalid> writes:
>> long strLength(const char *s)
>
> ISO C 90 might contain a provision stating that:
>
> »The implementation may further restrict the
> significance of an external name (an identifier that has
> external linkage) to six characters and may ignore
> distinctions of alphabetical case for such names«.
>
> (This text was copied from a draft, but I remember
> having read this in the ANSI document, too.)

Yes, it's a lousy name. And it's a lousy function, too. He needs strlen.
He's just too stupid to realise it.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

==============================================================================
TOPIC: HOW this program is executing plz explain the program
http://groups.google.com/group/comp.lang.c/t/3fb552296fac02d8?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Feb 13 2010 10:02 am
From: Keith Thompson

manish sahu <manish.comp05@gmail.com> writes:
> #include<stdio.h>
> #include<conio.h>
>
> main()
> {
> int i,j;
>
> clrscr();
> scanf("%d%d"+scanf("%d%d",&i,&j));
> printf("%d %d",i,j);
> getch();
> return 0;
> }

This is better in the sense that it's more portable and doesn't do
rude things like clearing the screen, but it's still junk (I've
also improved the layout, corrected the declaration of main,
and added a new-line to the output).

#include <stdio.h>

int main(void)
{
int i, j;

scanf("%d%d" + scanf("%d%d", &i, &j));
printf("%d %d\n", i, j);
return 0;
}

The inner scanf call is evaluated first. It will attempt to read two
int values, as text, from stdin, and store them in i and j. Let's
assume this succeeds.

So far, we've consumed two strings representing int values from stdin,
stored them in i and j, and returned the value 2 from scanf.

Now the outer scanf call is equivalent to

scanf("%d%d" + 2);

which in turn is equivalent to

scanf("%d");

for reasons I can explain if anyone doesn't already understand it.

This reads another string representing an int value from stdin and
... wait, what?

The format string specifies that you're reading an int value,
but no corresponding argument is provided, so we haven't specified
where to store it. Undefined behavior. In practice, it's likely
to store the third int value from stdin in the location pointed to
by whatever address happens to be in the memory location where the
second argument *would* have been.

If the inner scanf call fails, it can return either 1 or 0, yielding
a format string for the outer scanf of either "d%d" or "%d%d".
"d%d" requires a literal 'd' on input, followed by an int value;
"%d%d" requires two int values. In either case, the behavior
is undefined because of the lack of following arguments; even
if those arguments were provided, the failure is quietly ignored
since the program doesn't check the result of the outer scanf call.
Or if an input failure occurs before any conversion, it yields
the value of EOF, which is negative (-1 on most implementations),
resulting in yet another cause of undefined behavior.

On my system, when I feed this program "100 200 300" as input, the
output is "300 200". There's probably some argument to be made
that this is the most likely result, based on where arguments are
probably stored on the stack, but I won't waste my time constructing
such an argument.

Obfuscated code has its place. Things like this can be useful
as puzzles to demonstrate how well you really know the language.
*Wrong* obfuscated code can even be useful for similar reasons;
knowing what's incorrect and why is as important as knowing
how correct code behaves. But if someone proposed to include
something like this in production code, physical violence would not
be my immediate response, but it would be somewhere on the list.
(That last part is a joke ... mostly.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

== 2 of 2 ==
Date: Sat, Feb 13 2010 10:32 am
From: Andrew Poelstra

On 2010-02-13, manish sahu <manish.comp05@gmail.com> wrote:
> #include<stdio.h>
> #include<conio.h>
>

This is unnecessary and non-portable, but fortunately(?) the
functions you call from it(?) are also unnecessary so we can
just imagine away that header, your call to clrscr() and the
call to getch().

> main()

main() returns int. Writing that explicitly is clearer and
more future-proof:
int main(void)

The void is also more specific; in theory just int main() could
accept an arbritary number of arguments, so in C it is better to
say int main(void).

> {
> int i,j;
>
> clrscr();
> scanf("%d%d"+scanf("%d%d",&i,&j));

The first argument to scanf is "%d%d" + n, where n is calculated
as the return value of scanf(). If scanf reads both characters,
the return value will be 2 and the argument will be "%d%d" + 2,
or "%d". Now scanf() expects an int to go with that, and gets
none, so you have invoked Undefined Behavior.

That's the best case.

Worst case, the second scanf() gets no valid input and returns 0,
so the first scanf() is expecting /two/ integers as additional
arguments, so again you have Undefined Behavior.

In either case your program logic is traipsing over memory it
doesn't own, and anything can happen, including but not limited
to sending SIGWAKE to the demon daemon, who will draw demons
from your nose.

> printf("%d %d",i,j);

By this point, who knows what's happening.

> getch();
> return 0;
> }

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Saturday, February 13, 2010

comp.lang.c - 26 new messages in 4 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts