How to convert Infix notation to postfix notation

J

Julienne Walker

Let's give the guy a fresh start, shall we? But let's stop him the
first time he argues not on technical grounds but on personality
grounds.

In

spinoza1111 wrote:



Stop right there. Already he's deciding to argue not on technical
grounds but on gender grounds, simply because his interlocutor is
female. Let's see if he can avoid attacking personalities for longer
than 24 words next time.

While bringing gender into the mix is nonsensical, he does have a
point. I generally don't post to CLC (because better programmers than
I get to the questions first), and my most recent activity has indeed
been participating in the recent flames involving spinoza1111. So
technically I could be considered a troll due to the majority of my
recent posts being off-topic and provocative. :)

Of course, at this point I don't think there's much reason to push for
topicality since the "trolls" have already achieved critical mass. In
my view CLC is no longer a viable resource except via post archives
and I pursue serious discussion of C elsewhere.
 
R

Rod Pemberton

Seebs said:
A string is a series of bytes terminated by a null byte.

Sorry, not to pick on you Seebs, there probably is much incorrect and
uncorrected stuff in this thread. I've only read a few posts in it.

Your statement is not correct according to the C specifications. It's
correct in practice on machines that support 8-bit bytes as characters.
But, I'm really surprised none of the dominant pedants, er... regulars, here
corrected you... When I imply bytes are 8-bits or should be or one should
learn assembly prior to C, they regularly say to me, "You think: 'All the
world's a VAX/MS-DOS/PC.'" or some such BS.

A string is a contiquous sequence of characters - not bytes as you've
stated - terminated by a "null character" - which is a byte, not a
character.

This distinction between the characters and the terminating byte of a string
is important on architectures where a byte and char have different sizes in
bits. A "byte" has been redefined by the C specifications to mean a host
specific size in bits. A byte according to the C spec.'s is not necessarily
it's historical usage as 8-bits as created by Dr. Werner Buchholtz and Bob
Bemer for ASCII around 1960 and as standardized upon defacto-ly to support
ASCII in microprocessors circa 1974. I'll usually refer to it as a "C byte"
for this reason, since the rest of the non-C world and the C world prior to
1989 (ANSI C spec.) knows a byte to be 8-bits. The only place where people
feign ignorance of this is c.l.c. E.g., if a char is 9-bits and a byte is
14-bits on some system, all 14-bits in the terminating byte - not just the
9-bits of the terminating char - must be cleared. The reason for this was
that one of the early computer architectures that C to was ported to was
word addressable (16-bits). I.e., it was quicker and easier to find the
terminatorl when checking for a C byte (16-bit word in this case...) than
for a char. Of course, this affects the implementation of the '\0' escape
on such systems. Setting a char to value zero might not produce a
terminating "null character" either as expected...


Rod Pemberton
 
N

Nick Keighley

    testCase("((10+(113-(2+((((((2/(4+3)))))))+2+2))))*a", "10 113 2 2
4 3 + / + 2 + 2 + - + a *", intMallocMax);

is that one on spinoza's?
why this above not result to me?

what? Do you mean "why did my version not give the above result?"?
yesterday and today i had some free time for spend in this
because in the algo book i have it use push/pop for infixtopolish
(nor that i have understod well what this polish syntax is)

google it. Also look up Dijkstra's Shunting Yard algorithm.
i choose the assembly implementation

why? I mean seriously, what are you trying to do? It is rare to need
to convert infix to postfix. Are you writing an interpreter or
something? If you want to understand how the conversion is done then I
don't see how copying something out of a book is much help. And trying
to understand an algorithm by looking at the assembler just seems
plain nuts!
(don't know how many bug there are)

nor are you likely to find out. Even if I wanted the final version to
be in assembler I'd code it and test an HLL (eg. C) version first.

<snip giant wodge of assembler>

why did you post that to comp.lang.c?
 
B

bartc

Rod Pemberton said:
Sorry, not to pick on you Seebs, there probably is much incorrect and
uncorrected stuff in this thread. I've only read a few posts in it.

Your statement is not correct according to the C specifications. It's
1989 (ANSI C spec.) knows a byte to be 8-bits. The only place where
people
feign ignorance of this is c.l.c. E.g., if a char is 9-bits and a byte is
14-bits on some system, all 14-bits in the terminating byte - not just the
9-bits of the terminating char - must be cleared. The reason for this was
that one of the early computer architectures that C to was ported to was
word addressable (16-bits). I.e., it was quicker and easier to find the
terminatorl when checking for a C byte (16-bit word in this case...) than
for a char. Of course, this affects the implementation of the '\0' escape
on such systems. Setting a char to value zero might not produce a
terminating "null character" either as expected...

If what you say is true, a lot of C code (even the tiny amount I've seen),
would not work correctly.

Eg, it seems common practice to shorten a string by inserting a
zero-character in the middle. You're saying that might not be enough for a
terminator on some systems.
But, I'm really surprised none of the dominant pedants...

Sorry, who's being pedantic...?
 
B

Ben Bacarisse

Richard Heathfield said:
Yes, it is.

Well, to a first approximation, yes, but I'd want to consider

L"abc"

to be a string as well. This gives rise (via a rather complex
transformation) to a thing that I'd call a string (and the standard
does as well) but which is very likely to have null bytes within it.
And though it is indeed "a series of bytes", that misrepresents the
matter since the bytes are no longer the key components of it.
C89 1.6 Definitions of terms
* Character --- a single byte representing a member of the basic
character set of either the source or the execution environment.

C99 3.7.1 Terms, definitions and symbols
1 character
single-byte character
C bit representation that fits in a byte

Are you deliberately missing out the other definition? The standard
uses character to mean two things. Some characters don't fit into a
byte and the text is careful to disambiguate the terms when it
matters.

Rob Pemberton's objection is nonsense, but not because Seebs's
statement is unambiguously correct. A C char is always a byte, no
matter how wide it is, and a character in the basic execution
character set always fits into a char (as you go on to point out), but
C99 has more sophisticated notion of a character (and hence of a
string) which means that Seebs's remark is simply a reasonable
approximation to the truth.

<snip>
 
G

gwowen

I find that rather sad. Personally, I disagree - there remain enough
non-troll non-idiots posting here that in my view the group is still
viable. But it's certainly going downhill.

It would be nice if some of those (presumed) non-troll non-idiots[0]
would find more productive to do than troll-baiting-in-the-name-of-
entertainment, then. Trolls don't spoil newsgroups. Failure to
ignore trolls does.
 
S

spinoza1111

There are no victims, in my opinion. If you choose to participate in
the flames, you waive any claim to innocence. Everyone who posts in
such a way is an instigator, which happens to include myself.

This is simply not true. Being able to verbally defend oneself is a
basic human right: the alternative is the law of the jungle. Of
course, if "the law of the jungle" is relabeled "the law of the rain
forest", all of a sudden, whoop de doo, it's fashionable, isn't it?
But it's old and sour wine in new bottles in my view.
Actually, I'm rather surprised that you didn't point out my flagrant
hypocrisy. :) I emphasize problem solving over finger pointing as a
virtue and then immediately thereafter blamespinoza1111for helping
in the death spiral of CLC.

I think it's good that you are looking at your own behavior.
Then again, that can be explained away by admitting that I don't enjoy
the virtue of never placing blame. In all honesty, I've been sorely
tempted to buy C: The Complete Reference and write up a complete
objective review just for Ed's viewing pleasure. The only thing
stopping me is the cost of purchasing a book that I'll probably only
open one time.

That sounds like a waste of time. Why don't you code something new and
have people comment on it? You know, that's what I'm doing, and for
the most part what I have been doing here and on comp.programming
since day one. However, I have not been socialized and educated into
the sort of cowardice I see in the graduate student who is very good
at counter-examples and bullying undergraduates but dares not question
senior faculty, or defend himself against their exploitation.

You come in here, read a couple of posts out of sequence and out of
context, and you conclude I'm the problem. Like some sort of den
mother. Well, you have no standing whatsoever, hon.
 
S

spinoza1111

Let's give the guy a fresh start, shall we? But let's stop him the
first time he argues not on technical grounds but on personality
grounds.

In

spinoza1111wrote:



Stop right there.

Make me.
Already he's deciding to argue not on technical
grounds but on gender grounds, simply because his interlocutor is
female. Let's see if he can avoid attacking personalities for longer
than 24 words next time.

You're damned right I'll use gender. I am not the soft silent male
that's been created by a false feminism. If a woman is misusing her
gender to enable, I will call her on it.
 
S

spinoza1111

In

spinoza1111wrote:
[96 words followed by] It seems that most posters
here are learning disordered

105 words this time before the first personality attack.

How dare you? You trash the personality and reputation of anyone you
don't like, leaving comments about their competence instead of
addressing their points, comments which then can be examined by their
employers. You deal in nothing but personalities: your technical
comments are absurd (your comments about const being an example).
You're the pot and the instigator, and I think you're being paid to
foul this newsgroup up.
 
S

spinoza1111

to be fair he's never claimed to be a C expert. So he's implementing a

My expertise, as I have said already, is 20 years old. So I am not now
a C "expert". However, I regard such "expertise" as sub- or para-
professional, like being an expert on slide rules or lab equipment.
solution in a language he's unfamiliar with. On the other hand you'd
think he'd grateful for any help...

Not if it's fraudulent. Richard poses as a C expert but he has no
standing because he doesn't know about Microsoft platforms. He gets
his ideas by running compilers and looking at warnings and error
messages. He doesn't contribute technically except to question the
competence of people he doesn't like, and he doesn't like people who
question his administrative statements about this and other newsgroup
AS IF he is an unofficial moderator.

He's memorized phrases, saws and folklore and repeats these as
arguments with no capacity for seeing the difference, for example,
between a question of style and trade-offs (where one might decide in
a trivial loop to have the for recalculate the loop end, this being
clearer) and actual correctness.

In fact, he seems to have no concept of software correctness which
addresses, not conformance to a "standard" or "making the user happy",
but whether or not the software is legally or mathematically adequate
to solving a business problem, not only in the service of profits but
also in the public interest.

As to gratitude. I have in fact been quite careful to acknowledge
contributions by listing the contributor in the Change Record of
infix2Polish, taking care to make them anonymous when requested to do
so. As to gratitude, I think such emotions are too closely related to
subservience and the eternal regression to barbarism I see in
programming, where people learn to kow tow to Fat Bastards all too
readily.
spinoza keeps on going on about "Structured Walkthroughs" and
egolessness and yet displays an ego the size of a planet. In his

No, I defend myself against ego-driven aggression. Do the math and see
how the aggression causes the self-defense. But it is true, from Gaza
to here, that the victims of aggression will easily seem to be the
aggressors when they, for example, retaliate against Israeli
aggression. Likewise, you clowns mess with me you can expect a
response.

The alternative is what Minnesota poet Robert Bly calls today's "soft
male" who never defends himself because he's been raised too much by a
hippie-type mother who cannot deal with typically male aggression, and
who typically works in some technical job thought by him and his Mom
to be a safe haven from the storms of the world...even as in the
legend of Parzival, his Mom Herzeleide gave him a bow and arrows
instead of knightly weapons for fear that if she had "enarmit him with
sword and shield", he'd end up like Gamuret, fighting and dying in a
far off land.

The problem being that if Parzival never leaves Mom and begins his
quest, he becomes a softness oozing toxic harm to others because of
his self-hatred, and I claim that the ridiculous attack on Schildt is
an example of this.

If a book has wrong ideas, you need to define the ideas and refute
them. However, the Soft Male is above all afraid of activating
resentment of powerful males, therefore "C: The Complete Nonsense"
made the issue not the gap between Microsoft praxis and everybody
else, a gap which is the fault of people on both sides, but Schildt,
causing grievous harm to him and his family by dragging his name into
disrepute online.

Pople charge others with being what they hate in themselves. Of
course, I'd have to ask whether I do this. Not when I respond to
aggression (such as Heathfield's ridiculous charge, made in 2003, that
to recalculate the limit in a for was a bug and not a flaw or a matter
of trading-off style and efficiency). For if the general peace extends
to "no self-defense" then you have the situation in Gaza, where people
who defend themselves with low-tech rockets are condemned, and
attacked with high-tech weaponry.

In this and in other threads, I am using this newsgroup as intended.
Here, the OP asked about infix to Polish conversion, and I suggested
using a recursive descent approach because unlike more specialized
algorithms, recursive descent scales up. I posted a grammar, corrected
it when I and Bacarisse saw flaws, and transformed that grammar into
code that works.

Without being able to code new alternatives, people have been
challenging my competence based on silly issues such as whether const
should be used when it fails to prevent errors. They have been
continually wasting my time in having to answer their ridiculous
aspersions and while themselves yapping about being on topic, they
seem always to think their cowardly hatreds are on topic at all times.
universe all criticism of his program is the critic's problem not the
program's.

This is absurd. Examine the Change Record. It incorporates criticism
constructively as changes to the code.

// * *
// * 11 06 09 Nilges Version 4 *
// * Seebs 1. Fix upper case in #include *

Made based on criticisms by Seebach

// * 2. Comment corrections *

Made based on others' criticisms

// * 3. Bug: intMaxPolishLength not *
// * assigned when malloc specified*
// * on command line *

Made based on others' criticisms

// * 4. Renamed string2UnsignedInt to *
// * string2Int *

Made based on others' criticisms

// * 5. Use macros to better format *
// * about info *
// * 6. Command line malloc is now a *
// * maximum request allowable *
// * 7. Bug: invalid malloc request *
// * caused zero to be used without*
// * error indication. *


Made based on others' criticisms


// * 8. Changed str2Int to return err *
// * when nonnumeric characters *
// * appear *


The basic mechanism: people with little programming jobs have learned
to hide what Adorno called "the secret contour of their weakness"
which is also their capacity for love:

Here I stand head in hand
Turn my face to the wall
If she's gone I can't go on
Feelin' two-foot small

Everywhere people stare
Each and every day
I can see them laugh at me
And I hear them say

Hey you've got to hide your love away
Hey you've got to hide your love away

How can I even try
I can never win
Hearing them, seeing them
In the state I'm in

How could she say to me
Love will find a way
Gather round all you clowns
Let me hear you say

Hey you've got to hide your love away
Hey you've got to hide your love away.

The Beatles were talking about someone who loved and lost. But what
bothered managers in my direct experience about the successful
structured walkthrough was the enthusiasm of people unafraid of being
attacked in a zero-sum game for "incompetence" when they missed a bug,
by people so afraid of vulnerability that it was Job One for them to
show (illogically enough) that SOMEONE ELSE was the "fool on the
hill", illogically because just because someone else had a brain fart
DOES NOT IMPLY that you don't.

I am of course aware that Richard Heathfield trumpets his readiness to
admit error and from time to time, admits error at his personal
convenience. But he cannot refrain, ever, from either compulsively
posting (with a frequency that is very, very disturbing, because it
indicates either obsessive-compulsive disorder shading to psychosis,
or because he is being paid for posting by evil men), or trashing
people who call him on his bullshit.
 
B

Ben Bacarisse

Richard Heathfield said:
In


Then you might want to be at odds with the C99 Standard, since it says
quite plainly that "A character string literal need not be a string
(see 7.1.1), because a null character may be embedded in it by a \0
escape sequence."

It says it in non-normative text, but that aside, my example does not
do that. It may have null bytes in the middle, but has no null
characters in it except for the one at the end. To get a non-terminal
null *character*, I would have to write something like L"a\0bc" as the
footnote explains.
If L"abc" contains null characters (other than at
the end), then it is not a string.

You have confused matters by talking about null characters rather than
null bytes. I said L"abc" is likely to have null bytes in it. It is
certain to have a wide null character at the end, but it might very
well have null bytes in the middle.
In which case it isn't a string.

So you read C99 as saying that whether L"abc" is or is not a string
depends on the character set used?
Although I do actually see the point you're making, I disagree that
it's a misrepresentation. It's a perfectly valid interpretation. In
C89, it is the only realistic interpretation. It is only in C99 that
I see your point.

The bytes of L"abc" are hardly any more significant than the bytes of
an int. What most code will care about is that it is a sequence of
characters (wide characters) with a null character (a null wide
character to use the standard's wording) at the end.
Well, yes, I am deliberately missing out the other C99 definition, but
(and please read the whole paragraph before jumping on this reply!)
only for the same reason that you miss out the irrelevant dictionary
definitions W, Y, Z of a word when demonstrating that it /does/ mean
X. Yes, it means all the other things too, but if your point is that
it does mean X then the other definitions are irrelevant. Here is the
other C99 definition: "abstract member of a set of elements used for
the organization, control, or representation of data". I didn't
bother to quote this one because it did not seem to me to be relevant
to the claim that Peter Seebach's statement was false: "A string is a
series of bytes terminated by a null byte." The only thing he might
be called on is that he neglected to say "first".

C99 introduces the other meaning because it will go on to use it. Your
limited use of the terms (specifically omitting the most general
meaning) means you end up with a limited set of strings. All the
objects that match Peter's phrase are strings (with your addition of
"first") but I would say that there are others. These are terminated
by null characters that are often more than one byte wide.

BTW, I did not claim the Peter's statement was false. My point was
that it is not the whole truth.
C89 and C99 both
have: "A string is a contiguous sequence of characters terminated by
and including the first null character." Whilst the Standard says
"character" rather than "byte" in each case, the substitution is not
an unreasonable one, certainly in C89, where the definition of
"character" is much tighter. The "abstract member" thing is
ridiculous, in my view - it could just as well apply to one member of
an array of pointers!

It's not an unreasonable substitution in C89 for which wide strings
are little more than an after-thought, but it is in C99 where I think
the distinction is important: a null character is not always a null
byte. Yes, I think the text tries to by clear by always qualifying
"character" with "wide" where it matters, but that does not stop them
being characters.

<snip>
 
S

Seebs

to be fair he's never claimed to be a C expert.

Which is interesting.

Because if I wasn't, when I wrote my critique of T:TCR, qualified to write
such a critique, then Spinny *definitely* isn't, at this time, qualified to
write a meta-critique. So he should withdraw all of his allegations and
claims about flaws in that work, and apologize publically for them!
spinoza keeps on going on about "Structured Walkthroughs" and
egolessness and yet displays an ego the size of a planet. In his
universe all criticism of his program is the critic's problem not the
program's.

It is sort of odd. When people catch flaws in my work, I try to understand
how the flaw arose and deal with not only the flaw, but the mechanism which
allowed it to enter into the code. Even if they're purely stylistic, I
do not like to disregard criticism; it's not sane to do so, because it leads
to worse code.

-s
 
S

Seebs

My expertise, as I have said already, is 20 years old. So I am not now
a C "expert". However, I regard such "expertise" as sub- or para-
professional, like being an expert on slide rules or lab equipment.

It is extremely difficult to be good at something while holding it
in contempt.
Not if it's fraudulent. Richard poses as a C expert but he has no
standing because he doesn't know about Microsoft platforms.

I suspect he knows plenty about them. There's a big difference between
knowing about something and thinking the entire world is like that.
He gets
his ideas by running compilers and looking at warnings and error
messages.

He is making a point which you are missing. He has a lot more information
and experience than that to offer. By showing only the mechanically-generated
complaints, he's making a significant point -- it is stupid to waste human
engineer time reviewing something when there are problems sufficiently
obvious that a tool can catch them.
No, I defend myself against ego-driven aggression. Do the math and see
how the aggression causes the self-defense.

Even if this were true, it wouldn't be a compelling argument... But
it's not true.

You can be all macho if you want. However, "defending" yourself in
the way you do is absolutely rooted in ego -- as is any form of macho
behavior. Which is to say, fine, you can be all proud of not being
a "soft male". Me, I'm not going to let whether people think I'm soft
or not keep me from doing the best work I can at a technical level.

Which is to say, you can be macho, or you can be a software engineer,
but you can't be both. Pick one.

-s
 
S

Seebs

Of course, at this point I don't think there's much reason to push for
topicality since the "trolls" have already achieved critical mass. In
my view CLC is no longer a viable resource except via post archives
and I pursue serious discussion of C elsewhere.

I came back recently after a long vacation. It's actually better than
it was back when comp.lang.c.moderated was originally started. Sure, there's
a bunch of trolls, and if you don't find the trolls amusing, there's a lot
less to talk about, but there's plenty of room for serious discussions
if anyone has anything to talk about.

Which reminds me again, I gotta think about posting some Cool Stuff.

-s
 
S

Seebs

Your statement is not correct according to the C specifications.

I'm pretty sure it is.

But let's see. The above statement is there just so there won't be any
doubt about it if I turn out to be wrong. :)
A string is a contiquous sequence of characters - not bytes as you've
stated - terminated by a "null character" - which is a byte, not a
character.

Ahh!

3.6 byte
addressable unit of data storage large enough to hold any member
of the basic character set of the execution environment
NOTE 1 It is possible to express the address of each individual
byte of an object uniquely.
NOTE 2 A byte is composed of a contiguous sequence of bits, the
number of which is implementation- defined. The least significant
bit is called the low-order bit; the most significant bit is called
the high-order bit.

The gimmick, as you see here, is that the C specification defines "byte"
in a way which happens to turn out to mean "char".

3.7.1 character
single-byte character
<C> bit representation that fits in a byte

5.2.1, Character sets, says:

A byte with all bits set to 0, called the null character,
shall exist in the basic execution character set; it is
used to terminate a character string.
The only place where people
feign ignorance of this is c.l.c.

Oh, I'm not ignorant of the fact that 'byte' has another meaning.

However, *according to the C specifications*, I'm fine.
The reason for this was
that one of the early computer architectures that C to was ported to was
word addressable (16-bits). I.e., it was quicker and easier to find the
terminator when checking for a C byte (16-bit word in this case...) than
for a char. Of course, this affects the implementation of the '\0' escape
on such systems. Setting a char to value zero might not produce a
terminating "null character" either as expected...

That's not an allowed implementation. Setting a single char in a string
to the value 0 terminates the string at that point.

-s
 
S

Seebs

Well, to a first approximation, yes, but I'd want to consider

L"abc"

to be a string as well.

I would call that a "wide string", which is composed of "wide characters".
See, e.g., 7.24.2.1 (fwprintf):

The fwprintf function writes output to the stream pointed
to by stream, under control of the wide string pointed to
by format that specifies how subsequent arguments are
converted for output.
Are you deliberately missing out the other definition? The standard
uses character to mean two things. Some characters don't fit into a
byte and the text is careful to disambiguate the terms when it
matters.
Yes.

Rob Pemberton's objection is nonsense, but not because Seebs's
statement is unambiguously correct. A C char is always a byte, no
matter how wide it is, and a character in the basic execution
character set always fits into a char (as you go on to point out), but
C99 has more sophisticated notion of a character (and hence of a
string) which means that Seebs's remark is simply a reasonable
approximation to the truth.

Fair enough.

-s
 
S

Seebs

Then you might want to be at odds with the C99 Standard, since it says
quite plainly that "A character string literal need not be a string
(see 7.1.1), because a null character may be embedded in it by a \0
escape sequence." If L"abc" contains null characters (other than at
the end), then it is not a string.

It probably is, it's just a string which happens to have additional data
after it. :p If L"abc" produces the same sequence of bits as, say,
"a\0b\0c\0\0\0", then it's arguably a string -- it's the string "a".
Plus some garbage we don't care about. :p

-s
 
S

Seebs


He wasn't talking to you.
You're damned right I'll use gender. I am not the soft silent male
that's been created by a false feminism.

It really comforts me to know that your beliefs about gender and
"feminism" make almost as much sense as your beliefs about C programming
and standardization.

-s
 
S

Seebs

How dare you?

Quite accurately.
You trash the personality and reputation of anyone you
don't like, leaving comments about their competence instead of
addressing their points, comments which then can be examined by their
employers.

Sort of like you just spent a month accusing me of various improprieties,
calling me names, attacking my character, and spamming the group with
accusations that I'm an "autistic twerp", all while completely ignoring
or failing to comprehend my technical points?

Huh.
You deal in nothing but personalities:

Again, I got a shiny new irony meter tested against public advocates of
strict sexual morality rules who spend their free time getting laid in
airport bathrooms, and you are simply NOT going to be able to break it,
no matter how hard you try. Admittedly you did make it into the red
zone on this one, but you're still nowhere near breaking it.
You're the pot and the instigator, and I think you're being paid to
foul this newsgroup up.

This is hilarious, but still stupid.

-s
 
M

Morris Keesan

... the rest of the non-C world and the C world prior to 1989 (ANSI C
spec.) knows a byte to be 8-bits.

That's odd. In the 1970s and 1980s, I used at least 3 different
computer architectures which had bytes with sizes other than 8 bits.
In C, and in "non-C".
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,075
Messages
2,570,562
Members
47,197
Latest member
NDTShavonn

Latest Threads

Top