I am going to make it reusable by using pointers. Just wanted to get some basic things out of the way first. If I shouldn't pass the length as pointer then how do you propose to update that in the functions? About platform-dependent code, which one? system('cls')? The extra ay? I am ignoring your advice about malloc for now and updating my question with updated code. Please comment.

I am ignoring the malloc part only because I'll be implementing that after I understand completely how to implement stack by arrays. I have been told that my basic concepts are bad so just trying to think everything again.

Oh, right. I'm too used to having a struct to operate on, which would carry the length with it. I mean system("cls"), yes. The extra ay after arr.

Are there any other suggestions? Also about not having return 0; at the end, I have a return at the logical end of the program in the switch statement.

I don't have anything further to add to the updated code, except to put #include <errno.h> at the top (to keep them sorted alphabetically). Also, I recommend having a default branch in your switch. In C89, there is no implicit return from main(), and therefore you need it right before the end of the scope, unless that is unreachable. But you should prefer C99 or C11 anyway.

Why use the default branch? There doesn't seem to be any use.

Exactly. Put assert(!"Should never be reached."); (or something like that) there, so you will know if you have made a mistake.

Any comments on update 3?

Nothing really substantial. see_top is often called peek. The condition in the do...while in get_user_action can be choice < PUSH && choice > QUIT). If you add dummy elements at the beginning and end of the enum and test against them instead, you won't need to update the code when you add more options. Finally, I'd put an empty line below each case block, and a space before < in the #includes.

@Lstor Thanks for all the suggestions. They have been really helpful. I wanted to give you a suggestion. You should add updates to your answers like William Morris. You usually place suggestions for improvement in comments but due to people not following through all of the comments many things are missed. If you update your answer your answers will have much more useful content that is usually in the comments.

@Lstor They already have enough content but just saying that it can be easily improved.

@AseemBansal You're right. I think I often do so, but in this case the extra bits came gradually and seemed so small at the time, so I figured a comment was sufficient. Over time it accumulated to deserve an edit, though.

@AseemBansal I updated the answer now

@Lstor I think you missed the part about alphabetical order of the headers

@Lstor I thought to reuse this chat room. No use creating 2 chat rooms for a single question

@Lstor Should I use an enum even if there are 2 states? That would be consistent but William Morris suggested otherwise

Or did I get him wrong?

Hi Anseem, William here. Hope I'm not intruding :-)

@WilliamMorris No. It

This chat room is for the question

It was named automatically

And BTW it's Aseem without a n

'n'

Opps, sorry!

push() still has the PUSH/START enum values as status

pop() and peek() now use 1 as a failure status (I'd use -1 but that is just my preference)

but they return -1

Messed up. But I fixed it to use another enum {SUCCESS, FAILURE}

About return -1. I didn't know any alternative.

I had to return something

Ah ok. That sounds better.

The -1 thing is difficult

It is why I suggested (I think) that I would go for returning status and copying the data through a parameter

rather than returning data and copying status through a parameter (which is what you have done)

If I copy the data through a parameter then how would that solve the problem? No way to show that there isn't data in the stack.

Unless

wait a moment

see the first code block in my comment on your update 2

my second code block in that update is what you did, but I missed out returning a value in the error case

so it probably didn't occur to me at the time that there was a problem of what to return

I think I saw -Infinity somewhere in standard library

cplusplus.com/reference/cmath/INFINITY

Maybe?

no

I am not sure if that is in C99

it is floating point

just return status, parameter for data

then you can just do:..

In case there is underflow in popping data then how does using data as parameter solve it?

if (pop(...) < 0) { printf(...);}

else {printf(..., data);}

so if the pop fails print an error, else print the data

That is a common pattern in C

Isn't that just a variation of what I am doing? It is shorter but same thing is being done here.

convention?

no, you are returning the data

I'm talking about returning status

If I use int pop(int *arr, int *length, int *data)

Then I'll have to change data

I can leave it alone

But that won't matter

As without checking the status you can't tell if the data is new

You want something like:

If we talk in terms of information given by the function then I am returning status and data and you are giving the same

if (pop(arr, &length, &data) < 0) {printf("error\n") } // etc

so this line returns the status and you must check the return value before looking in 'data'

'data' is only valid if status is 0 (or SUCCESS)

I am checking status before touching data

So in my case also 'data' is only valid if status is SUCCESS

Yes that is ok, but we were talking of what value to return when an error occurs

you can indeed return whatever value you want, including -1

it is just an odd way to do it.

I agree with @WilliamMorris, returning a status code and passing the data in an output parameter is more common and better

So it's more like a convention?

Or am I missing something?

You could call it a convention

It is not set in stone, you can do what you want. But in this case where there is a clear 'yuk' factor (returning an arbitrary valid data value on error), I'd say it is best

I actually don't know much about C conventions. I'll be happy to change.

Sorry, but I have to leave shortly. I hope I have made some sense (not always true :-)

A lot of sense. Thanks.

ok, nice to talk with you . Bye.