Please kindly verify this ...no return causing crash...Qt and gives no errors

Anonymous_Banned275

If I declare function to return "int" and give "return " no value - compiler will rightfully complain.

If I declare a function returning QString and have no "return" NOWHERE the body of the function body

Qt banana will give NO warning or post an error
and will crash giving no info why.

I like to verify if it is MY FAULT or just how Qt works.

Thanks

JonB

@AnneRanch said in Please kindly verify this ...no return causing crash...Qt and gives no errors:

If I declare a function returning QString and have no "return" NOWHERE the body of the function body

Qt is not language. C++ is, and does not allow this. Could you show your function please?

Chris Kawa

Qt has nothing to do with it. It's undefined behavior in the C++ standard. The only non-void function that can omit a return statement in all control flows is main in which compiler is required to generate a 0 return code. All other non-void functions must return a value in all control flows otherwise it's undefined behavior. Compiler can generate any valid or invalid code and is permitted but not required to issue a warning.

The difference between int and QString is probably because int fits in a CPU register while a class such as QString doesn't so it's a different memory layout and thus different undefined behavior.

I like to verify if it is MY FAULT or just how Qt works.

I can verify it's your fault ;)

Anonymous_Banned275

@Chris-Kawa I am glad it is my fault. Has little to do with "standard" especially when it is verified in "main" and in any other function UNLESS the function returns anything BUT int.
I also believe it is a problem with CPU , as you kindly pointed out.
(always blame on somebody else - as we do in big.... state of .... (Uvalde) )

However , I tend to also believe in

it is not my job man
according to manual "The inmates are running the asylum" the coders will take
the least painful way to code and management will ignore it...
It is C/C++ issue , but never mind it gives Qt black eye

Chris Kawa

always blame on somebody else

Well, I have to say, that's a pretty shitty rule to live by... but hey, to each their own. I'm not one to tell others what kind of morals they should uphold.

If you need a list of entities to blame other than yourself I'd say it looks something like this (in rough order):

~~1. You, for not knowing the rules of the language you use~~
2. Dennis Ritchie for creating this rule in C
3. Bjarne Stroustrup for inheriting it in C++
4. The ISO C++ committee for not strengthening the rule over the years to require a diagnostic
5. Every other C++ programmer on the planet for not putting pressure on the committee to do 4.
6. Your compiler vendor for not implementing this particular undefined behavior exactly as you would like
7. Idk...fate? god? universe? Whatever you prefer to fall back on.

I left Qt out of the list because, again, it's just a library and has completely nothing to do with it.

it gives Qt black eye

No, it doesn't. If you don't understand that cars can't fly, it doesn't give a black eye to the car manufacturer if you try and crash. That's actually entirely on you for misusing the thing.

I know some states in US have "don't wash cats" stickers on their washing machines because someone tried and sued the manufacturer when their cat died, but I see that as an intellectual insult and a failure of humanity rather than the way to do everything.

JonB

@AnneRanch
Would you care to share the code of the function & call which exhibits this behaviour? It would be interesting to see.

mrjj

Hi
Just as a note.
I used this in Qmake projects

QMAKE_CXXFLAGS += -Werror=return-type

to make not returning anything a compile-stopping error to avoid falling into it.