twitter: comp.lang.c - 25 new messages in 8 topics

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

comp.lang.c@googlegroups.com

Today's topics:

==============================================================================
TOPIC: Implementing strstr
http://groups.google.com/group/comp.lang.c/t/a3fe05ab352d5774?hl=en
==============================================================================

== 1 of 8 ==
Date: Sat, Mar 20 2010 4:40 am
From: Nick <3-nospam@temporary-address.org.uk>

Dr Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On 20 Mar, 10:27, Nick <3-nos...@temporary-address.org.uk> wrote:
>> Dr Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>>
>> > On 19 Mar, 17:27, Seebs <usenet-nos...@seebs.net> wrote:
>>
>> >> You're arguing with someone who is not a first-year CS student and
>> >> claims to have needed TWO HOURS to implement strstr.
>>
>> >> Is there any genuine point in pointing out errors?
>>
>> > A quick and nasty strstr should only take a minute or so to write.
>>
>> I've seen it implemented using strchr and strcmp - something like this:
>>
>> /* written straight into newsreader - utterly untested */
>> a_strstr(const char *substrate, const char *pattern) {
>> while(substrate = strchr(substrate,*pattern) {
>> if(strcmp(substrate,pattern) == 0)
>> return substrate;
>> }
>> return NULL;
>>
>> }
>>
>> You can make it fractionally more efficient by advancing the pointers by
>> one before comparing but you need to be careful then with short
>> substrates.
>>
> This one won't work, strcmp("Fred is dead", "Fred") returns non-zero.
> You need strncmp, which entails a call to strlen() to get the length
> of the pattern.

Good point. I said I'd not tested it. That's exactly what the BSD code
you can find on the web (written by Chris Torek, no less) does -
although it walks the string explicitly char by char.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

== 2 of 8 ==
Date: Sat, Mar 20 2010 4:48 am
From: spinoza1111

On Mar 20, 5:25 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-03-20, Dr Malcolm McLean <malcolm.mcle...@btinternet.com> wrote:
>
> > A quick and nasty strstr should only take a minute or so to write.
>
> Right.
>
> > However it's a bit cryptic, particularly the for loop.
> > Whilst there's always the argument that as long as the interfaces are
> > nice, the code doesn't matter, I'd like to see a rather better job.
> > Then it will return a match to the first character if sub is the
> > empty string. I don't know offhand whether this is allowed. I'd have
> > to check the standard for a real implementation intended to be shipped
> > to someone else.
> > Two hours isn't unreasonable for a production-quality strstr.
>
> I'm not sure about that. It's a pretty simple function. And yes, yours
> is fine -- the first occurrence of an empty string is the zero bytes
> before the first character of the haystack.
>
> But, that said... It's not as though Nilges produced one of production
> quality. He spent two hours producing something that wouldn't get a
> passing grade in a first-semester programming course. That's why I

I'll ask you again, and I will keep asking you, if necessary in a
courtroom.

How would you know?

By your own admission, you have never taken a single class in
computer science. Because you're a pretentious autistic twit, you
interfered with homework assignments as a tutor, and we have no
information as to whether your "assistance", based as it was with
playing with the toys in your bedroom, was of any value.

If your academic family homeschooled you, this is merely a reason for
outlawing homeschooling altogether. I have long suspected that it will
create a generation of creeps who shit on people, because they haven't
learned how to work in groups.

You scorn the simplicity of strstr (having proven yourself incompetent
at the simplest of problems: strlen). Having taught computer science
and read Dijkstra, I am aware that simple problems are the best for
exposition and contain depths. Malcolm has made some interesting
comments in this regard. I'm not interested in hiding my incompetence
(as you seem to be) by pretending you're writing OS code ("pseudo" is
apposite in your case).

Peter, you took two months to write a pseudo root simulator of
questionable utility in which you test an index for validity after you
use it, and use the letter o as a variable name.

So fuck off. Businessmen like to reference academia because it's
something they think they can buy and sell. It's not. You're not even
a businessman, nor even anything resembling a man. You're a nasty
little clerk and an incompetent programmer who's here, apparently on
behalf of your employer, to get incompetent code debugged by slaves.

> have concluded that it's simply not worth trying to explain his bugs
> to him.

No, but I had to explain order-of-magnitude more egregious bugs (off
by one strlen) to you, and Kiki. You claim elsewhere that you get the
simple things wrong but are good at the complex things because Mommy's
little darling gots ADHD (an unprofessional revelation which damages
your employer), but what's interesting is the Popperian
unfalsifiability of this claim.

Sure, Einstein (cf Kaufmann 2007) was bad at math in fact. However,
Einstein NEVER attacked his colleauges as you attack Schildt (that was
Edward Teller, the genocide who invented the hydrogen bomb, and your
attacks suggest a deep insecurity based on a lack of real technical
accomplishment. I've searched for accomplishments comparable to what I
did when I was your age, and have found nothing. According to
Kaufmann, Einstein compensated for his mathematical deficiencies
(where in fact he was merely not a mathematician like Godel) by being
an excellent visual and physical reasoner. But your lack of talent in
the small doesn't scale. It don't turn into fine wine, Peter. And you
give me little reason to give you "the benefit of the doubt".
>
> -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 8 ==
Date: Sat, Mar 20 2010 4:51 am
From: spinoza1111

On Mar 20, 6:40 pm, Dr Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> On 20 Mar, 10:27, Nick <3-nos...@temporary-address.org.uk> wrote:
>
>
>
> > Dr Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>
> > > On 19 Mar, 17:27, Seebs <usenet-nos...@seebs.net> wrote:
>
> > >> You're arguing with someone who is not a first-year CS student and
> > >> claims to have needed TWO HOURS to implement strstr.
>
> > >> Is there any genuine point in pointing out errors?
>
> > > A quick and nasty strstr should only take a minute or so to write.
>
> > I've seen it implemented using strchr and strcmp - something like this:
>
> > /* written straight into newsreader - utterly untested */
> > a_strstr(const char *substrate, const char *pattern) {
> > while(substrate = strchr(substrate,*pattern) {
> > if(strcmp(substrate,pattern) == 0)
> > return substrate;
> > }
> > return NULL;
>
> > }
>
> > You can make it fractionally more efficient by advancing the pointers by
> > one before comparing but you need to be careful then with short
> > substrates.
>
> This one won't work, strcmp("Fred is dead", "Fred") returns non-zero.
> You need strncmp, which entails a call to strlen() to get the length
> of the pattern.

Good point. It's why I write complete and literate documentation
before coding. We need to think ahead. I missed that bug in Fred's
code.

The only reason I didn't use pre-existing str functions is I refuse to
use string.h.

== 4 of 8 ==
Date: Sat, Mar 20 2010 4:52 am
From: spinoza1111

On Mar 20, 7:40 pm, Nick <3-nos...@temporary-address.org.uk> wrote:
> Dr Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>
>
>
>
>
> > On 20 Mar, 10:27, Nick <3-nos...@temporary-address.org.uk> wrote:
> >> Dr Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>
> >> > On 19 Mar, 17:27, Seebs <usenet-nos...@seebs.net> wrote:
>
> >> >> You're arguing with someone who is not a first-year CS student and
> >> >> claims to have needed TWO HOURS to implement strstr.
>
> >> >> Is there any genuine point in pointing out errors?
>
> >> > A quick and nasty strstr should only take a minute or so to write.
>
> >> I've seen it implemented using strchr and strcmp - something like this:
>
> >> /* written straight into newsreader - utterly untested */
> >> a_strstr(const char *substrate, const char *pattern) {
> >> while(substrate = strchr(substrate,*pattern) {
> >> if(strcmp(substrate,pattern) == 0)
> >> return substrate;
> >> }
> >> return NULL;
>
> >> }
>
> >> You can make it fractionally more efficient by advancing the pointers by
> >> one before comparing but you need to be careful then with short
> >> substrates.
>
> > This one won't work, strcmp("Fred is dead", "Fred") returns non-zero.
> > You need strncmp, which entails a call to strlen() to get the length
> > of the pattern.
>
> Good point. I said I'd not tested it. That's exactly what the BSD code
> you can find on the web (written by Chris Torek, no less) does -
> although it walks the string explicitly char by char.
> --
> Online waterways route planner |http://canalplan.eu
> Plan trips, see photos, check facilities |http://canalplan.org.uk

Gee, no Heathfield Factor. Wonder where the big lug is.

== 5 of 8 ==
Date: Sat, Mar 20 2010 5:38 am
From: pete

Seebs wrote:
> On 2010-03-19, pete <pfiland@mindspring.com> wrote:
>> spinoza1111 wrote:
>>> In the replace() program of last month's flame festival, a little
>>> program was trying to get out. Here it is: an implementation of strstr
>>> including a call that returns the offset of the found substring. Two
>>> hours including all comments and dedicatory ode, written for this
>>> occasion.
>
> *snerk*
>
>>> printf("Expect 0: %d\n", strstr("", ""));
>>> printf("Expect 0: %d\n", strstr("0123456789", ""));
>
>> That's not what strstr is supposed to do.
>
> You're arguing with someone who is not a first-year CS student and
> claims to have needed TWO HOURS to implement strstr.
>
> Is there any genuine point in pointing out errors?

I like to discuss C.
Sometimes I make mistakes and then other people correct me.
Sometimes, when I don't make a mistake,
other people will attempt to correct me.

--
pete

== 6 of 8 ==
Date: Sat, Mar 20 2010 6:09 am
From: pete

spinoza1111 wrote:

> The only reason I didn't use pre-existing str functions is I refuse to
> use string.h.

You can write all of these portably in C,
using only <stddef.h> for size_t

void *memset(void *s, int c, size_t n);
void *memcpy(void *s1, const void *s2, size_t n);
void *memmove(void *s1, const void *s2, size_t n);
void *memchr(const void *s, int c, size_t n);
int memcmp(const void *s1, const void *s2, size_t n);
size_t strlen(const char *s);
char *strcpy(char *s1, const char *s2);
char *strncpy(char *s1, const char *s2, size_t n);
char *strcat(char *s1, const char *s2);
char *strncat(char *s1, const char *s2, size_t n);
char *strchr(const char *s, int c);
char *strrchr(const char *s, int c);
int strcmp(const char *s1, const char *s2);
int strncmp(const char *s1, const char *s2, size_t n);
size_t strspn(const char *s1, const char *s2);
size_t strcspn(const char *s1, const char *s2);
char *strpbrk(const char *s1, const char *s2);
char *strstr(const char *s1, const char *s2);
char *strtok(char *s1, const char *s2);

--
pete

== 7 of 8 ==
Date: Sat, Mar 20 2010 6:50 am
From: spinoza1111

On Mar 20, 9:09 pm, pete <pfil...@mindspring.com> wrote:
> spinoza1111wrote:
> > The only reason I didn't use pre-existing str functions is I refuse to
> > use string.h.
>
> You can write all of these portably in C,
> using only <stddef.h> for size_t
>
> void *memset(void *s, int c, size_t n);
> void *memcpy(void *s1, const void *s2, size_t n);
> void *memmove(void *s1, const void *s2, size_t n);
> void *memchr(const void *s, int c, size_t n);
> int memcmp(const void *s1, const void *s2, size_t n);
> size_t strlen(const char *s);
> char *strcpy(char *s1, const char *s2);
> char *strncpy(char *s1, const char *s2, size_t n);
> char *strcat(char *s1, const char *s2);
> char *strncat(char *s1, const char *s2, size_t n);
> char *strchr(const char *s, int c);
> char *strrchr(const char *s, int c);
> int strcmp(const char *s1, const char *s2);
> int strncmp(const char *s1, const char *s2, size_t n);
> size_t strspn(const char *s1, const char *s2);
> size_t strcspn(const char *s1, const char *s2);
> char *strpbrk(const char *s1, const char *s2);
> char *strstr(const char *s1, const char *s2);
> char *strtok(char *s1, const char *s2);
>
> --
> pete

Yes, you can. But even your rewrite will preserve Nul termination,
which I claim sucks.

== 8 of 8 ==
Date: Sat, Mar 20 2010 8:06 am
From: Ben Bacarisse

spinoza1111 <spinoza1111@yahoo.com> writes:
<snip>
> About ten minutes of work produces rel 1.12. This fixes the bug that
> Ben noted, where a = was used in place of ==.

I did not claim that = in place of == was a bug. In fact it is
obvious that putting == back introduces more bugs. My point was that
you did not know what your code was doing: you reported favourably on
a bug fix that could not possibly have any effect. You can't fix (or
do pretty much anything with) code you don't understand.

I don't expect you to change your style -- you've evolved it to
provoke a response here rather than make your code clear -- but if
there are any people learning C who are tempted to copy it: please
don't -- it confuses even the author of it.

<snip>
--
Ben.

==============================================================================
TOPIC: Idiotic programming style edicts
http://groups.google.com/group/comp.lang.c/t/99bc3aa427fc7518?hl=en
==============================================================================

== 1 of 6 ==
Date: Sat, Mar 20 2010 4:54 am
From: "bartc"

Ian Bush wrote:
> On 19 Mar, 23:40, "bartc" <ba...@freeuk.com> wrote:
>>
>> There must, surely, be a simpler, more elegant way of declaring an
>> int or float of a particular width.
>>
>> (Fortran used to allow:
>>
>> integer*4
>>
>
> Errrr, no. Very common extension but never standard.

Well I used that on at least 2 systems (both byte-addressed) about 30 years
ago.

But this was more an example of how widths can be specified in syntax,
without an explosion of new identifiers.

> Fortran now, i.e. for the last 20 years, has parameterized types which
> allows
> you to ask for a minimum range and, for floating point types,
> precision, but
> no way of asking for a particular width,

Sounds like it's made the types more abstract.

Which is fine for Fortran, but C is supposed to be a low-level language used
to implement the fiddly bits of operating systems, device drivers, the
runtimes of other languages, and to work on various small processors. All
that sort of thing.

You'd think then the language itself would allow you to choose or specify
the widths of these basic types, and have slightly more abstract ones
(short, int, long, etc) bolted on. Whereas it seems to be the other way
around.

So those header files must somehow define int32_t, say, in terms of the
fuzzy char, short, int, long and long long types of the language.

--
Bartc

== 2 of 6 ==
Date: Sat, Mar 20 2010 5:03 am
From: Peter Flass

Seebs wrote:
> On 2010-03-20, Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> wrote:
>>> len = strlen(foo);
>>> free(foo);
>>> memcpy(bar, foo, len);
>
>>> Now, just about anyone can tell you that this, while technically
>>> wrong, is virtually guaranteed to be harmless in practice — there's
>>> simply nothing there to reuse the space after the free.
>
>> I wouldn't be one of the people giving such a guarantee. In several of
>> the implementations that I'm familiar with, there exists the
>> possibility, if the string is longer than a page, that deallocating the
>> storage will cause one or more pages that formed part (or all) of the
>> string to be decommitted by the C library's heap management, resulting
>> in an access to decommitted page fault at the point of memcpy(). Even
>> for strings shorter than a page, there exists the possibility that free
>> block consolidation would result in the whole page containing the string
>> becoming free, and hence being decommitted.
>
> Yes. If it had segfaulted, I would not have been at all surprised.
>
> Getting a perfectly valid string, which happened to be a different
> but reasonably recently used and relevant, surprised me a lot.
>
> -s

Multi-threading can cause strange effects.

== 3 of 6 ==
Date: Sat, Mar 20 2010 5:41 am
From: jmfbahciv

Jonathan de Boyne Pollard wrote:
>>
>>>>
>>>> int strlen(char *strString) // Of strings I sing, and their Length
>>>> { // Oh muse, give me strength
>>>> int intIndex1 = 0; // To not fuck it up, like that Pup
>>>> for (; // Seebach, coder extraordinaire
>>>> *(strString+intIndex1);// Who doesn't care
>>>> intIndex1++); // That he makes us tear our hair.
>>>> return intIndex1; // And so my code is Done
>>>> } // And all had great fun
>>>>
>>> int daysinmonth (int month, year) [...]
>>>
>> Good, but my poem was original and I wrote it while coding the simple
>> strlen.
>>
>> I can walk and simultaneously chew Nicorette Gum
>> Can you, chum?
>>
> This is an interesting question that we might all care to ponder. I
> don't know, myself. The last time that I chummed was over a decade
> ago. I might have lost the knack.

<grin> You wouldn't believe the picture in mind when I read that
line of diatribe against Charlie. Spinzie's walk was not
straight-forward, let alone the chew part.

/BAH

== 4 of 6 ==
Date: Sat, Mar 20 2010 5:47 am
From: jmfbahciv

Seebs wrote:
> On 2010-03-19, jmfbahciv <jmfbahciv@aol> wrote:
>>> does the name Edward Nilges ring a bell?
>
>> Nope.
>
> Ahh, you're missing... well.

'ey, Seebs. How are ya doing.
>
> Edward Nilges is this guy. He's spent the last couple of years railing
> against the Cruele And Unjust Turns Of Fate by which Herbert Schildt has
> acquired a negative reputation. For instance, because every competent
> programmer who's ever commented on his books says they're pants.

Ah...my brain mists are clearing a tad. I keep forgetting the kooks.
>
> He recently responded to my posting of a quick one-off solution to a problem
> (figure 10-15 lines of code) with a >100 line version which took him a couple
> of hours to write, and several hours to debug. To demonstrate by complete
> incompetence at choosing variable names, he had variables named ptrIndex0,
> ptrIndex1, ptrIndex2, and ptrIndex3.
>
> The amazing thing is that, so far as anyone can tell, he actually believes
> himself to be serious.

yea, I could tell that just from his self-evaluation.

> Never mind that he has repeatedly sworn to sue various
> people for defamation and never yet gotten to it.
>
> Here's a fairly representative example:
>> In particular, Stroustrup had learned about
>> object oriented programming using Simula in Denmark before coming to
>> the US, because in Denmark labor unions had real power and demanded
>> that factory automation be documented for union oversight.
>
> That was on one of his comparatively lucid days.

Oh, dear.

>
> (Posting in detail just because afc people might find this amusing.)
>
Thanks...I think ;-) I'll now be blamed for opening the
Spinzzie I/O channel.

/BAH

== 5 of 6 ==
Date: Sat, Mar 20 2010 5:54 am
From: jmfbahciv

spinoza1111 wrote:
> On Mar 20, 1:24 am, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2010-03-19, jmfbahciv <jmfbahciv@aol> wrote:
>>
>>>> does the name Edward Nilges ring a bell?
>>> Nope.
>> Ahh, you're missing... well.

>> (Posting in detail just because afc people might find this amusing.)
>
> We don't find your behavior amusing, Peter. It shall have serious
> consequences unless you change.

uh-oh.
>
> Note to afc: although I left programming in disgust after thirty years
> because of dweebs like Peter, my programming career spans the IBM
> 1401, supercomputing, and .Net object oriented coding. I am the author
> of "Build Your Own .Net Language and Compiler", published by Apress in
> 2004. Although I taught C at Princeton and was asked to assist John "A
> Beautiful Mind" Nash with C in 1991, I abandoned it as my code
> addressed GUI platforms as inadequate. I've debugged Fortran compilers
> with no source,

How did you cause the compiler to compile if you had no FORTRAN code
to feed it?

> and created a very successful hydrostatic stability
> monitor with a graphics library that may have saved lives. I have most
> of the work completed in the MSCS with a straight A average.
>
> Peter Seebach, although another Apress author who's written some sort
> of scripting book, the quality of which is unknown to me, has no
> academic preparation in computer science

Oh, that's why he's so good.

>and claims he has a learning
> disorder. His "day job" by his own admission, is a typically factored
> and rationalized clerical paraprogramming job in which he finds and
> reports compiler bugs, perhaps writing a lot of scripts.

Only a few people are able to do this kind of work well.

<snip>

> He's also, as we see above, a very ignorant and incurious person.

Seebs?!!! You must have a reading challengement.
>
<snip>

/BAH

== 6 of 6 ==
Date: Sat, Mar 20 2010 9:22 am
From: Walter Bushell

In article <hnvqrv31o0k@news4.newsguy.com>, jmfbahciv <jmfbahciv@aol>
wrote:

> Walter Bushell wrote:
> > In article <601.764T2654T5385823@kltpzyxm.invalid>,
> > "Charlie Gibbs" <cgibbs@kltpzyxm.invalid> wrote:
> >
> >> In article <hnt5bs22t2v@news4.newsguy.com>, jmfbahciv@aol (jmfbahciv)
> >> writes:
> >>
> >>> <grin> My language is MACRO-10. JMF was always tickled whenever
> >>> he assembled some code because MACRO would report a "successful"
> >>> assembly with the comment "No errors detected". Think about it. ;-)
> >> "As far as we know, the system has never had an undetected error."
> >
> >
> > That is true of *all* the code I have wrote.
> >
> Not mine. I always write an off by one bug.
>
> /BAH

But if the error is ever detected then it is no longer an undetected
error.

This method brought to you be the department of redundancy department
and Information Management Systems Systems (IMS Systems).

--
A computer without Microsoft is like a chocolate cake without mustard.

==============================================================================
TOPIC: Cryptic Syntax
http://groups.google.com/group/comp.lang.c/t/3c0bd77fdf5ec98c?hl=en
==============================================================================

== 1 of 4 ==
Date: Sat, Mar 20 2010 5:01 am
From: "bartc"

WD wrote:
> On Mar 19, 7:18 pm, Gene <gene.ress...@gmail.com> wrote:
>> On Mar 19, 8:09 pm, WD <liamym...@yahoo.com> wrote:

>>> Can anybody explain what's going on in the extremely cryptic syntax
>>> found in the return statement below? Based on observed program

>>> main(x,y)
>>> {
>>> /*create a program in memory before returning*/
>>
>>> return(*(int(*)())*(int*)(z))(x,y);
>>
>>> }

I had to do something similar once, in my case the function took no
parameters and returned no result.

I used a typedef to simplify things (not that it shows):

typedef void (*(*F))(void);
(**(F)(p))();

Here F is the name of the typedefed part, and p is an int containing, not a
function address, but a location where the function address resides (iirc).

I had to enlist the help of c.l.c to set this up, and now I keep it under
lock and key in case I need to use it again.

--
Bartc

== 2 of 4 ==
Date: Sat, Mar 20 2010 5:10 am
From: Paul N

On 20 Mar, 03:01, WD <liamym...@yahoo.com> wrote:
> On Mar 19, 7:18 pm, Gene <gene.ress...@gmail.com> wrote:
>
> > On Mar 19, 8:09 pm, WD <liamym...@yahoo.com> wrote:
>
> > > Can anybody explain what's going on in the extremely cryptic syntax
> > > found in the return statement below? Based on observed program
> > > functionality, it appears this statement directly launches a program
> > > (that was created in memory during the /*create a program in memory
> > > before returning*/ section) after main exits, but how?
>
> > > main(x,y)
> > > {
> > > /*create a program in memory before returning*/
>
> > > return(*(int(*)())*(int*)(z))(x,y);
>
> > > }
>
> > > Thanks,
> > > William
>
> > Hard to say what it does because it's nonsense. There is no
> > declaration for z. The comment is meaningless.
>
> > If z were declared to be a pointer of any kind, then the (int*) would
> > cast it to a pointer to int. The * dereferences this pointer.
> > Consequently
> > *(int*)(z)
> > has type int. The
> > (int (*)())
> > casts this to a pointer to function returning int. The leftmost *
> > dereferences this to a function type. The function (if z actually
> > pointed to one) would be applied to x and y. The value of x is the
> > program argument count. The value of y is undefined, but in many
> > implementations, will be an integer version of the pointer argv.
>
> > Of course we know z doesn't point to anything because it's undefined.
> > The code would only make a rough, ugly kind of non-compliaent sense if
> > z contained a pointer to a pointer to a function accepting an int and
> > a pointer to pointer to char. Here:
>
> > #include <stdio.h>
>
> > f(x, y)
> > char **y;
> > {
> > printf("Hello! x=%d and y[0]=\"%s\"\n", x, y[0]);
> > return 0;
>
> > }
>
> > main(x,y)
> > {
> > int w = &f;
> > int *z = &w;
> > return(*(int(*)())*(int*)(z))(x,y);
>
> > }
>
> > C:\>gcc foo.c -o foo.exe
> > foo.c: In function 'main':
> > foo.c:12: warning: initialization makes integer from pointer without a
> > cast
>
> > C:\>foo
> > Hello! x=1 and y[0]="foo"
>
> > C:\>
>
> z is declared as an int, not a pointer, and it really works as I
> described. After creating a program in memory (like a compiler, only
> no executable is written to disk) it appears that the return statement
> somehow invokes the compiled (in memory) program. The full program
> compiles with gcc and runs in the Linux environment, if that somehow
> makes a difference.

I think you're wrong in saying that the "compiled" program runs
*after* main exits; rather, it is the last thing to run before main
exits. For instance, if main ends:

return runstuff(x, y);

this is the same as

temp = runstuff(x, y);
return temp;

except that the first form doesn't need an extra variable to store the
result in. Either way, runstuff runs first, then main exits, passing
on the result from runstuff.

Other than that, you seem to realise exactly what is going on, even if
you don't realise that you realise it... By the looks of it, it is
indeed "compiling" a program into memory and running it. This
necessarily requires system-specific features, as different system
have different machine codes, and it also requires some nasty
conversions in order to persuade the computer that the data you've
just built up is actually a function it can run. Hence the cryptic
syntax to convert an int into a function pointer.

Hope that helps.
Paul.

== 3 of 4 ==
Date: Sat, Mar 20 2010 8:25 am
From: Ben Bacarisse

"bartc" <bartc@freeuk.com> writes:
<snip>
> I had to do something similar once, in my case the function took no
> parameters and returned no result.
>
> I used a typedef to simplify things (not that it shows):
>
> typedef void (*(*F))(void);
> (**(F)(p))();

You can simplify this a little if you want to:

typedef void (**F)(void);
(*(F)p)()

Functions are called through a pointer and functions get converted to
pointers so any extra *s are harmless but redundant so (*****(F)p)()
also works.

<snip>
--
Ben.

== 4 of 4 ==
Date: Sat, Mar 20 2010 9:41 am
From: "BGB / cr88192"

"Gene" <gene.ressler@gmail.com> wrote in message
news:7956db29-f344-4997-971f-75c0851cdf1a@y17g2000yqd.googlegroups.com...
On Mar 19, 8:09 pm, WD <liamym...@yahoo.com> wrote:
> Can anybody explain what's going on in the extremely cryptic syntax
> found in the return statement below? Based on observed program
> functionality, it appears this statement directly launches a program
> (that was created in memory during the /*create a program in memory
> before returning*/ section) after main exits, but how?
>
> main(x,y)
> {
> /*create a program in memory before returning*/
>
> return(*(int(*)())*(int*)(z))(x,y);
>
> }
>
> Thanks,
> William

<--
Hard to say what it does because it's nonsense. There is no
declaration for z. The comment is meaningless.
-->

I will partly disagree some on this point.

since the only thing done directly on z here is to cast it, the initial
declaration and type of z is not particular important (it could be an
integer, a pointer, a long long, ...). (it is sufficient to assume that z
exists and is not a struct or union or similar, as this would be a compiler
error...).

after the cast, types are known, and so the behavior can be understood.
(granted, in this form, it still could not be run).

so, we can infer:
z is treated as some sort of pointer to a pointer to an area of memory which
is then called as if it were a function, with the return value returning to
the caller.

it can also be noted that the code will work on some architectures but not
others (it will work on x86, but not on x86-64, ...).

but, anyways, this sort of thing is "par for the course" if doing really any
kind of self-modifying code in a C program...

==============================================================================
TOPIC: Is it good to use char instead of int to save memory?
http://groups.google.com/group/comp.lang.c/t/40bfc7048b74630b?hl=en
==============================================================================

== 1 of 3 ==
Date: Sat, Mar 20 2010 5:30 am
From: pete

bartc wrote:
>
> "Eric Sosman" <esosman@ieee-dot-org.invalid> wrote in message
> news:hnthdh$qnd$1@news.eternal-september.org...
>> On 3/18/2010 11:29 AM, bartc wrote:
>>>
>>> The context is that something wants to store a value via a char*
>>> (perhaps a function call). You can't use int*.
>>
>> "The context" is
>>
>> //int i = 1;
>> char i = 1; //is this better than previous line?
>>
>> There is no char* anywhere in sight. There is not even a store
>> operation anywhere in sight, certainly not a store through a char*
>> via the intermediary of a function call. You're imagining things.
>
> I was replying to:
>
> "pete" <pfiland@mindspring.com> wrote in message
> news:4BA221DE.CC4@mindspring.com...
>
>> I wouldn't use types lower ranking than int,
>> unless they were in an array.
>
> I gave an example where a char variable would be handy. That example
> stored something via a char* type. That was the context, expressed as:
>
> *p=65;
>
> for illustration, but a function call might be an example where a char*
> might be imposed:
>
> char c;
>
> while (readnextvalue(f,&c)) printf("%d",c);
>

That's not an example of
"Is it good to use char instead of int to save memory?"

That's an example of using char because you have to.

--
pete

== 2 of 3 ==
Date: Sat, Mar 20 2010 6:08 am
From: markhobley@hotpop.donottypethisbit.com (Mark Hobley)

Seebs <usenet-nospam@seebs.net> wrote:
> Never use char unless you mean it. If you just want a value, and don't
> really care too much about its range, always use int.

I would create a macro USMALL in a header file, and then define your small
numbers using:

USMALL c;

On an computer types where using a char datatype is more efficient (such as
on IBM compatible computers) the header file would define USMALL as follows:

#define USMALL unsigned char

(ie an unsigned char would be used)

On a platform where this produces overheads, the header file would define
USMALL as follows:

#define USMALL unsigned int

This would enable your code to be used portably on both platform types.

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

== 3 of 3 ==
Date: Sat, Mar 20 2010 7:07 am
From: Dr Malcolm McLean

On 20 Mar, 13:08, markhob...@hotpop.donottypethisbit.com (Mark Hobley)
wrote:
> Seebs <usenet-nos...@seebs.net> wrote:
> > Never use char unless you mean it. If you just want a value, and don't
> > really care too much about its range, always use int.
>
> I would create a macro USMALL in a header file, and then define your small
> numbers using:
>
> USMALL c;
>
>
> #define USMALL unsigned int
>
The problem with that is that the code rapidly becomes almost
unreadable.

eg
void zeroduplicates(UBIG *x, USMALL N)
{
USMALL i;
for(i=0;i<N-1;i++)
if(x[i] == x[i+1])
x[i] = 0;
}

it's hard to spot the bug.

==============================================================================
TOPIC: Killfile troll "Phil Carmody".
http://groups.google.com/group/comp.lang.c/t/bf4e0288d8537985?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 6:25 am
From: gazelle@shell.xmission.com (Kenny McCormack)

In article <80j5neFo1rU1@mid.individual.net>,
Default User <defaultuserbr@yahoo.com> wrote:
>Branimir Maksimovic wrote:
>
>> On Fri, 19 Mar 2010 23:13:51 +0100
>> jacob navia <jacob@nospam.org> wrote:
>
>> > I just don't read what carmody writes, and that is much easier. Why
>> > bother?
>>
>> Exactly! you don;t have to read.
>
>If you never plan to read the posts of a certain person, why not
>killfile them?

Whether you killfile or not is irrelevant. That is between you and your
maker/conscience. What matters is whether or not you talk about it in public.

As I've noted earlier, talking about your killfile in public is that
which marks one clearly as a dweeb.

--
(This discussion group is about C, ...)

Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch revelations of the childhood
traumas of the participants...

==============================================================================
TOPIC: ARE U A COMPUTER PRIGAMMER-------?
http://groups.google.com/group/comp.lang.c/t/c641bf3e1f816dda?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 6:36 am
From: LLL <6ennel.0569@gmail.com>

http://123maza.com/75/expressions

==============================================================================
TOPIC: Discount CHLOE True leather AAA Wholesale (www.supertradeonline06.com )
http://groups.google.com/group/comp.lang.c/t/957771b31618936d?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 6:52 am
From: huang xiang

Discount VERSACE True leather AAA Wholesale (http://
www.supertradeonline06.com/ )
Discount VERSACE bags Wholesale (http://www.supertradeonline06.com/ )
Discount Chanel Purse Wholesale (http://www.supertradeonline06.com/ )
Discount CHANEL bags Wholesale (http://www.supertradeonline06.com/ )
Discount CHANEL True leather AAA Wholesale (http://
www.supertradeonline06.com/ )
Discount PRADA Purse Wholesale (http://www.supertradeonline06.com/ )
Discount PRADA bags Wholesale (http://www.supertradeonline06.com/ )
Discount PRADA True leather AAA Wholesale (http://
www.supertradeonline06.com/ )
Discount GUCCI Purse Wholesale (http://www.supertradeonline06.com/ )
Discount GUCCI True leather AAA Wholesale (http://
www.supertradeonline06.com/ )
Discount Gucci bags Wholesale (http://www.supertradeonline06.com/ )
Discount Gucci Purse True leather AAA Wholesale
(http://www.supertradeonline06.com/ )
Discount Gucci bag Wholesale (http://www.supertradeonline06.com/ )
Discount BURBERRY Purse Wholesale (http://
www.supertradeonline06.com/ )
Discount BURBERRY bags Wholesale (http://www.supertradeonline06.com/ )
Discount pauesmitl bags Wholesale (http://
www.supertradeonline06.com/ )
Discount HERMES True leather AAA Wholesale (http://
www.supertradeonline06.com/ )
Discount HERMES Purse True leather AAA Wholesale
(http://www.supertradeonline06.com/ )
Discount HERMES bags Wholesale (http://www.supertradeonline06.com/ )
Discount LV bags Wholesale (http://www.supertradeonline06.com/ )
Discount LV Purse True leather AAA Wholesale (http://
www.supertradeonline06.com/ )
Discount LV Purse Wholesale (http://www.supertradeonline06.com/ )
Discount LV True leather AAA Wholesale (http://
www.supertradeonline06.com/ )
Discount D&G bag Wholesale (http://www.supertradeonline06.com/ )
Discount D&G Purse Wholesale (http://www.supertradeonline06.com/ )
Discount D&G bags Wholesale (http://www.supertradeonline06.com/ )
Discount D&G Purse True leather AAA Wholesale
(http://www.supertradeonline06.com/ )
Discount ED Purse Wholesale (http://www.supertradeonline06.com/ )
Discount EDHardy bags Wholesale (http://www.supertradeonline06.com/ )
Discount UGG bag Wholesale (http://www.supertradeonline06.com/ )
Discount CHLOE True leather AAA Wholesale (http://
www.supertradeonline06.com/ )
Discount CHLOE bags Wholesale (http://www.supertradeonline06.com/ )
Discount Chloe Purse True leather AAA Wholesale
(http://www.supertradeonline06.com/ )
Discount JIMMY CHOO Purse True leather AAA Wholesale
(http://www.supertradeonline06.com/ )
Discount JIMMYTOO bags Wholesale (http://www.supertradeonline06.com/ )
Discount JIMMY THOO True leather AAA Wholesale
(http://www.supertradeonline06.com/ )
Discount paul smith bags Wholesale (http://
www.supertradeonline06.com/ )

More detail land, address:http://www.supertradeonline06.com/

==============================================================================
TOPIC: c99 multidimensional arrays contiguous?
http://groups.google.com/group/comp.lang.c/t/3a16b9b33cb0cdd0?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Mar 20 2010 9:50 am
From: Luca Forlizzi

On 17 Mar, 23:01, Seebs <usenet-nos...@seebs.net> wrote:

> a is an array of 10 arrays of ints. The integers in each array are
> necessarily contiguous, and the arrays are necessarily contiguous, so
> it's going to point to a region containing 100 integers. If you derive
> a pointer from a, it is a pointer into that whole object.
>

This conclusion is clear and logical, but is it really deducible from
the standard?
The only sentence in the standard I was able to find to support the
fact that a pointer to an object can be considered to point into the
largest possible array containing the pointed object, is 7.20.3, but
this explicitely refers to objects returned from a memory alloc
function.
On the other hand, the int object p points to is an element of the
array a[0], not of a, which is not an arrat of ints.

Some days ago in a thread about exiting from "double loops" Ben
Bacarisse and Tim Rentsch have the same opinion as you, so I am pretty
sure that there is something in the standard that I do not fully
understand. Could you please enlighten me?

-- Luca Forlizzi

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

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, March 20, 2010

comp.lang.c - 25 new messages in 8 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts