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

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

comp.lang.c@googlegroups.com

Today's topics:

* Making FILE opaque - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/5b748373bfa3544c?hl=en
* portable floating-point read/write - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/7c848009bd0fc355?hl=en
* Warning to newbies - 3 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/9597fd702985dff4?hl=en
* Motivation of software professionals - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/21a3fdec4dd53e6a?hl=en

==============================================================================
TOPIC: Making FILE opaque
http://groups.google.com/group/comp.lang.c/t/5b748373bfa3544c?hl=en
==============================================================================

== 1 of 3 ==
Date: Fri, Feb 12 2010 10:31 pm
From: Kaz Kylheku

On 2010-02-13, Alan Curry <pacman@kosh.dhis.org> wrote:
> In article <slrnhnc41d.5jg.usenet-nospam@guild.seebs.net>,
> Seebs <usenet-nospam@seebs.net> wrote:
>|On 2010-02-13, Richard Tobin <richard@cogsci.ed.ac.uk> wrote:
>|> What are you trying to achieve? Obviously making FILE * opaque has
>|> a certain elegance to it, but do you have a practical goal? Do you
>|> plan to conceal your source code so that no-one can work out what's
>|> really in the structure? After all, you have to be fairly determined
>|> to do anything with it even if it's openly defined in <stdio.h>.
>|
>|Avoiding people messing around with internal data that may not have the
>|semantics they have in mind for it.
>
> You wanna start an arms race? Here's your future:
>
> /* SEEBS_LIBC and SEEBS_LIBC_VERSION defined by configure script, by
> strings'ing the library if you're being stubborn about that too */
> #if SEEBS_LIBC
> #if SEEBS_LIBC_VERSION <= 1003001
> #define STDIO_BUFSTARTP(f) (*(unsigned char **)((char *)(f)+16))
> #define STDIO_BUFENDP(f) (*(unsigned char **)((char *)(f)+20))
> #elif SEEBS_LIBC_VERSION <= 1004002
> #define STDIO_BUFSTARTP(f) (*(unsigned char **)((char *)(f)+28))
> #define STDIO_BUFENDP(f) (*(unsigned char **)((char *)(f)+32))

Your cold war (code war?) effort is screwed right off the bat here if
Seebs Libc is a shared library, where newer versions of the library
detect and support old clients.

You may need run-time hacks to detect the actual SEEBS_LIBC_VERSION you
are running on, rather than rely on the one you were compiled with.

== 2 of 3 ==
Date: Fri, Feb 12 2010 10:53 pm
From: jacob navia

Alan Curry a écrit :
> In article <lny6iyc4w7.fsf@nuthaus.mib.org>,
> Keith Thompson <kst-u@mib.org> wrote:
> |jacob navia <jacob@nospam.org> writes:
> |> Seebs a écrit :
> |>> It was recently pointed out that the theoretical construct:
> |>> struct __file;
> |>> typedef struct __file FILE;
> |>> is not a conforming implementation (assuming no definition of
> |>> struct __file),
> |>> because FILE is specified to be an object type.
> |>>
> |> lcc-win64 makes FILE opaque.
> |
> |Opaque in what sense? C99 7.19.1p2 specifically requires FILE to be
> |an object type.
>
> What's the point? File this requirement under "design by committee" and
> ignore it.
>
> If you're looking inside the FILE type because you actually want to do
> something with the information in there, beyond what the standard
> interfaces offer, that's different.
>

I need to make it opaque because the fields, size, and many other things
aren't fixed.

I want to make things like

FILE *fp = fopen("http://www.q-software-solutions.de","r");

That would open any file in the network. I think users will be
happier with those features than with a strictly conforming
stuff.

== 3 of 3 ==
Date: Fri, Feb 12 2010 10:58 pm
From: Seebs

On 2010-02-13, jacob navia <jacob@nospam.org> wrote:
> I need to make it opaque because the fields, size, and many other things
> aren't fixed.
>
> I want to make things like
>
> FILE *fp = fopen("http://www.q-software-solutions.de","r");
>
> That would open any file in the network. I think users will be
> happier with those features than with a strictly conforming
> stuff.

Well, if you want to make it totally conforming AND do that, I've now
revealed how! You are totally entitled to do things like convert the
pointer between different structure types when you get to it; the standard
is quite clear that a copy of a FILE isn't the same as the original, so
people can't rely on being able to copy those fields or otherwise mess
with them.

You could have:
typedef struct {
unsigned char u;
} FILE;

then have an array of FILE:
FILE file_table[64] = { 0 };

Then implement stdio functions with something to the effect of:

int
fprintf(FILE *ext_fp, blah blah) {
real_file_t *fp = real_file_table[ext_fp - file_table];
...
}

All that's required is that it is AN object type, not that it is THE
object type.

-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!

==============================================================================
TOPIC: portable floating-point read/write
http://groups.google.com/group/comp.lang.c/t/7c848009bd0fc355?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Feb 12 2010 10:42 pm
From: Nobody

On Fri, 12 Feb 2010 03:39:51 -0800, Michael Foukarakis wrote:

> For integer quantities I use hton[s|l]()/ntoh[s|l](). Generally
> speaking though, how about encoding into IEEE-754? Here's some code I
> copied a long time ago from...some fellow which I don't recall.

> while(fnorm >= 2.0) { fnorm /= 2.0; shift++; }
> while(fnorm < 1.0) { fnorm *= 2.0; shift--; }

This is rather inefficient if the exponent is far from zero (and
"long double" typically supports binary exponents from -16381 to 16384).

frexp() and ldexp() are in C89 (the float and long double variants are
C99), and should have constant time for any sane architecture. You do need
to watch out for denormals, though (frexp() will return an exponent which
is less than DBL_MIN_EXP).

== 2 of 2 ==
Date: Fri, Feb 12 2010 11:57 pm
From: Michael Foukarakis

On Feb 13, 8:42 am, Nobody <nob...@nowhere.com> wrote:
> On Fri, 12 Feb 2010 03:39:51 -0800, Michael Foukarakis wrote:
> > For integer quantities I use hton[s|l]()/ntoh[s|l](). Generally
> > speaking though, how about encoding into IEEE-754? Here's some code I
> > copied a long time ago from...some fellow which I don't recall.
> >     while(fnorm >= 2.0) { fnorm /= 2.0; shift++; }
> >     while(fnorm < 1.0) { fnorm *= 2.0; shift--; }
>
> This is rather inefficient if the exponent is far from zero (and
> "long double" typically supports binary exponents from -16381 to 16384).

I don't know, the logarithm is a powerful little bugger.

> frexp() and ldexp() are in C89 (the float and long double variants are
> C99), and should have constant time for any sane architecture.

What? Why? :O

==============================================================================
TOPIC: Warning to newbies
http://groups.google.com/group/comp.lang.c/t/9597fd702985dff4?hl=en
==============================================================================

== 1 of 3 ==
Date: Fri, Feb 12 2010 10:45 pm
From: spinoza1111

On Feb 13, 7:48 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-02-12, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> > I know you'll find this hard to believe, but
> > there's more to life than comp.lang.c.
>
> Eek!
>
> No wonder my boss never seems to accept "argued with Edward Nilges" as
> a week's work.  :P
>
> Actually, in a fit of irony, we ended up needing the revised string replace
> function I posted here the other day, because new data revealed that our
> original spec wasn't flexible enough.  Needless to say, it worked fine
> on the first try.  :P

...and when will you get around to fixing its bugs? "It works fine" is
incompetent programmerese for "it seems to work".

Your behavior from the start of this thread has been to post buggy
code and refuse to fix it, and lie about and backstab people as in the
case where in another thread you presented an old version of my code.

I really am glad that I do not work at your company, and have to clean
up your messes.

How do you know whether the specific string.h library functions you
use are correct? Someone here has mentioned implementations of
bsearch.h that don't work for large data structures. Does strstr work
for all possibilities?

And doesn't it encourage sloppy thinking? If a programmer mindlessly
uses strstr, in your spirit in other words, there's a strong
possibility he will get to the next string by ADDING THE LENGTH of a
found sequence to an index:

char * ptrIndex1;
ptrIndex1 = strMaster;
while (*ptrIndex1)
{ ptrIndex1 = strstr(strMaster, strTarget); if (*ptrIndex1) intCount+
+; ptrIndex1 += strlen(strTarget); }

In any application that needs to worry about overlapping strings, this
code is wrong. In real "shops", the reaction when such a bug is
exposed (when, for example, the user "wanted" overlapping strings, or,
far better, the facts and the law require it, many users themselves
being themselves ignorant of requirements), the reaction is without
dignity, intellect or heart: it is to finger-point at the user, and to
renarrate him or her in the feminine register as one who "can't make
up their mind".

A fundamental strategy is in fact renarration of human problem solving
as feminine, as in the case of the programmer who conscientiously on
the job documents and fixes bugs as they arise, only to be renarrated
as "writing code with many bugs" by the local office thugs, who
themselves (unable to declare that they are the perfect Father who
never in the dreamtime makes a mistake) admit their bugs but then
don't fix them, saying instead that only a (feminized) Fool would
worry about such marginal conditions (as a percent sign not followed
by an s).

When I started at Princeton, another employee with considerable macho
issues, a member of the Olympics rowing team, vandalized a change
record I'd made with lines like "Ed added a bug". I'd been hired to
control his behavior which included putting public messages on
Princeton's IBM mainframe such as "baby locked in microwave chews off
own foot". With a student employee (who later became a Microsoft
executive) I fixed this problem. But such employees often dominate
commercial "shops" and are celebrated as "hackers", while in fact they
worship technology and silly ideas...it's people they shit upon.

In short, the saw, that "good programmers never blame their tools and
always use libraries" is just wrong. Good, or great programmers are
not little tradesmen who love their tools. They are instead critical
intellectuals who prefer people to tools, humanity to ideas. They have
a critical relationship to their tools and they are in fact eager to
solve problems in a revolutionary and disruptive fashion, like Che
Guevara and unlike Barack Obama.

"Many will call me an adventurer — and that I am, only one of a
different sort: one of those who risks his skin to prove his
platitudes." - Che Guevara

And if this is alarming: note that in places like "Wind River
Systems", the leaders often have modeled their careers of capitalistic
and Schumpeterian "primitive accumulation" and "creative
destruction" (of lives and careers). But this expropriation results in
what I call the "monastic" or "madrassah" programming "shop".

This is one where the programmers must cultivate a different ethic,
one of absolute subservience to the authority of people, ideas and
tools, which has in my experience become almost mediaeval, lest the
top men (and they are usually men) be expropriated in turn of that
which they have expropriated.

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

== 2 of 3 ==
Date: Fri, Feb 12 2010 10:50 pm
From: spinoza1111

On Feb 11, 1:11 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-02-10, Richard Harter <c...@tiac.net> wrote:
>
> > On Wed, 10 Feb 2010 02:17:34 -0800 (PST),spinoza1111
> ><spinoza1...@yahoo.com> wrote:
> >>But...isn't the algorithm I've used (disregarding the banana bonona
> >>bonono banoono issue) the best we can get, given no "magically find
> >>the next matching character" instruction?
>
> 1.  Such an instruction may exist.  Some processors have hardware
> string processing.

These were popular when memory was inexpensive in the 1970s relative
to CPUs, and such unbounded operations could be implemented in
microcode. Today, the existence of such instructions is folklore, and
folklore isn't an argument.

> 2.  "Best" algorithm is always restricted by input set.  For the input
> set I was using, a fairly naive strstr wins handily.  For some input
> sets, yours will be horrible and the "super studly" algorithms will
> win by enough that the preprocessing and tables are worth it.  So
> no, yours wasn't "the best", it was just "a pretty good bet most of the
> time" -- and on at least one system I know, strstr() uses precisely
> that algorithm, only without the bugs.

How would you know whether any given implementation of strstr contains
bugs? You have no way in fact of knowing this.

>
> >>And don't the super studly
> >>algorithms like Boyer Moore and Knuth Morris Pratt always require
> >>preprocessing and tables, with some of them best implemented as
> >>members of hash tables indexed by targets so we can reuse them for the
> >>same target? And doesn't this imply that the C library function can't
> >>be re-entrant if it uses them?
>
> Not really.
>
> >>And does not THIS imply that the super-
> >>studly algorithms are best implemented in an OO language like C Sharp?
>
> No.

"No" is an argument only for a toddler.

>
> > Boyer Moore doesn't require preprocessing/tables.  Knuth Morris
> > Pratt does.  Both can be implemented as re-entrant routines.
> > There are faster algorithms that do require significant
> > reprocessing.  BM and KMP can be implemented re-entrantly as can
> > almost all algorithms.  Requiring re-entrancy is (almost)
> > orthogonal to OO.
>
> Exactly.

No, Walter descended into incoherence. What does "orthogonal to OO"
even mean?
>
> -s
> --
> Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 3 of 3 ==
Date: Fri, Feb 12 2010 10:59 pm
From: spinoza1111

On Feb 10, 10:59 pm, blm...@myrealbox.com <blm...@myrealbox.com>
wrote:
> In article <baa2d216-616c-481b-88aa-60f6ad4a5...@s36g2000prf.googlegroups.com>,
>
> spinoza1111 <spinoza1...@yahoo.com> wrote:
> > On Feb 9, 7:32 am, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
> > wrote:
> > > blm...@myrealbox.com <blm...@myrealbox.com> writes:
> > > > In article <0cd7a7f4-f9ce-47f7-8437-b4d6d1bbb...@s36g2000prf.googlegroups.com>,
> > > >spinoza1111<spinoza1...@yahoo.com> wrote:
> > > >> Moore's law won't help us much with NP complete solutions.
>
> > > > Or NP-complete problems.  (Terminology quibble?  Maybe.)
>
> The more I think about it, the more I think this is not a mere
> quibble about terminology, and that it does matter whether it's
> the problem or the solution that's "NP complete" -- I mean, the
> point is not that an NP-complete problem has *A* solution that's
> not polynomial-time, but that *ALL* solutions are thought to be
> in that category.
>
> That such problems may have approximate solutions that are
> polynomial-time is useful in practice but somewhat beside the
> point.
>
> > > Not at all. The bilgemaster encounters what he considers to be
> > > academic-sounding terms, and then repeats them hoping that he'll
> > > be treated as someone even vaguely erudite. Unfortunately, he
> > > uses the terms in completely hatstand contexts, and thus fails
> > > dramatically. Tragic, and best ignored.
>
> > You're mistaking the verbal flexibility of someone who's actually
> > studied NP complete issues (graduate level class in algorithms, grade
> > == A) with misuse of "terminology", where unqualified little clerks
> > have to watch their mouths and use of "terminology" lest their brutal
> > slave-masters kill them for using the wrong "ears of corn", of
> > shibboleths.
>
> You know, I'm inclined to think that quibbling about terminology
> is apt to be *more* prevalent in academia than elsewhere.
> Perhaps your experience differs from mine in that regard.

That is indeed a common perception and it's a reality insofar as some
universities (especially mega-state schools where most of the students
don't know what the hell they are even doing there, apart from
majoring in pre-wealth and having sex). It's created by a form of
"blowback" in which the "businesslike" ethos of mindlessly mastering
terminology enters the university, and to get tenure, English
professors learn to master fashionable buzzwords such as
"deconstruction".

They do so in the USA without typically being exposed to a classical
and European corpus. For example, they never have read Plato's
Republic in its entirety despite the fact that the late Derrida,
supposed an avatar of deconstruction, reread Plato's complete works
every year for *merde et rire* (shits and giggles).

They get their ticket punched, and in fact as English professors are
more like little office creeps than what I would consider a professor,
precorrupted by the Darwinian brutality of tenure in universities
dominated by used car salesmen and insect exterminators in state
legislatures.

Marked, wounded, as are people here by Adorno's "inner contour of
their weakness", they are then unleashed on survey and intermediate
classes, there to subject their students to the only form of
"discipline" they or their charges have ever known: basically rote and
grade school discipline which everyone tacitly regards as a sort of
meaningless ritual that is a prerequisite for entry into the American
Orgy of consumption.

So yeah, "terminology" is also used in academia. I am referring to my
Idea of academia, not the devolved reality.
>
> [ snip ]
>
> --
> B. L. Massingill
> ObDisclaimer:  I don't speak for my employers; they return the favor.

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

== 1 of 1 ==
Date: Fri, Feb 12 2010 11:41 pm
From: Michael Foukarakis

On Feb 12, 4:02 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On 12 Feb, 11:30, Michael Foukarakis <electricde...@gmail.com> wrote:
>
>
>
> > On Feb 12, 10:08 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
> > > On 11 Feb, 09:58, Michael Foukarakis <electricde...@gmail.com> wrote:
> > > > I am not an expert at law, so I cannot reason about justification or
> > > > necessity. However, I do recall quite a few "mishaps" and software
> > > > bugs that cost both money and lives.
> > > > Let's see: a) Mariner I, b) 1982, an F-117 crashed, can't recall if
> > > > the pilot made it, c) the NIST has estimated that software bugs cost
> > > > the US economy $59 billion annually, d) 1997, radar software
> > > > malfunction led to a Korean jet crash and 225 deaths, e) 1995, a
> > > > flight-management system presents conflicting information to the
> > > > pilots of an American Airlines jet, who got lost, crashed into a
> > > > mountain, leading to the deaths of 159 people, f) the crash of Mars
> > > > Polar Lander, etc. Common sense tells me that certain people bear
> > > > responsibility over those accidents.
>
> > >http://catless.ncl.ac.uk/risks
>
> > I'm terribly sorry, but I didn't get your point, if there was one.
> > Seriously, no irony at all. Care to elaborate?
>
> oh, sorry. You were listing "software bugs that cost both money and
> lives", I thought your list was a bit light (Ariane and Therac spring
> to mind immediatly). I thought you might not have come across the
> RISKs forum that discusses many computer related (and often software
> related) bugs.

Oh, well, that seems rather obvious now. Lack of sleep ftl. I'm sure
Seebs got the point, anyways.

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

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