I've got a floating point exception in huge application after some changes. I tried to comment my changes and found that FPE happens when I enable one simple function call.
api::getMaxSize();
which simply returns value.
looks like this
int api::getMaxSize() { return 536870912; };
This is static member function. When I move this to header file everything works fine.
I'm confused, what can be the reson? Looks like API is in another module and linked as dynamic library, but how can this cause a problem?
added
There is function maxBox() which is template and implemented in api.h header file.
This function calls getMaxSize()
template <typename T>
static rectangle<T> maxBox()
{
return rectangle<T>(
getMinSize(), getMinSize(),
getMaxSize(), getMaxSize()
);
}
here is the calling code
if (!api::maxBox<double>().contains(box * scale)) { /* api::getMaxSize(); */ }
If I enable getMaxSize() call the program starts throwing FPE, but getMaxSize() is actually never called.
added
Found FPE in box * scale, can't understand why it was working without getMaxSize() call, but however the problem is solved. Thanks to everybody.
Thanks in advance.
Floating point exceptions (actually signals) are raised for different reasons. The main ones are:
you divide an integer by zero
an operation on signed integers overflows (unsigned integers must wrap around silently in C and C++).
As you can see, they have nothing to do with floating point numbers ! The name is historical and cannot be changed without breaking a lot of source code (there is a SIGFPE constant in <signal.h>).
It can be here that GetMaxSize returns a value which is not representable by a int.
Related
For context, the language I've been using to teach myself to code is Python. Now I'm trying to learn C++ to broaden my coding literacy, but I'm having trouble understanding how functions are returning values.
I've been reading the following documentation:
https://www.cplusplus.com/doc/tutorial/program_structure/
Perhaps I need a better understanding of returning a value vs outputting something, but what is confusing me about the first program structure exercise is that it starts off with the classic "Hello world" example, which is obviously a string. However, the "int main()" is expecting an integer, not a string, right? So wouldn't there be some sort of error that would prevent the program from compiling?
main returns int. Nothing else.
There are three portable return values from main: EXIT_FAILURE, EXIT_SUCCESS, and 0. Returning EXIT_SUCCESS or 0 returns an implementation-specific value that the OS will interpret as successful execution. Returning EXIT_FAILURE returns an implementation-specific value that the OS will interpret as failed execution. You get those macros from <cstdlib> or from <stdlib.h>.
Most of the time the value doesn't matter; it's simply ignored. But when you run a script through the OS, sometimes it matters whether a particular program succeeded, and then you write code in the script to check the value that the program returned. A simple example (well, simple for a shell script, but still somewhat cryptic):
./my_program
if [ $? -eq 0 ];
then
echo "Succeeded"
else
echo "Failed"
fi
Here, $? is the result of the previous command. Since the previous command was ./my_program, if the program ran successfully $? will be 0, and if not, it will be some other value.
It seems the confusion here is not about the main function primarily, so let's step away from main for a moment.
Printing a value and returning a value are fundamentally two different things that really don't have anything to do with one another. The confusing part is we often use the word "output" to mean one of several different things.
Let's start with understanding what a return value is by itself. So hopefully you know that functions can be called from inside other functions and serve as a way to organize the functionality within a program. Let's look at a very simple example:
int getDoubled(int x)
{
return 2 * x;
}
Here we've defined a simple function with the name getDoubled and it expects, as an argument, a single integer and returns a single integer. And we can see from the code that the integer returned is x, the input argument, multiplied by 2.
Now that we have a function we can call it from somewhere else:
int y = getDoubled(3);
Here we've called the function by writing its name followed by a parameter list. This means the code inside the function will be run and the expression in its return statement will be the value that it acts like. In this case that means y is assigned the value 6, because getDoubled(3) evaluates to its return value of 6.
Notice this has nothing to do with printing the value 6 to the screen, the return type and value of a function in C++ is only for determining the value the function call represents in an expression. Consider this now:
int y = getDoubled(getDoubled(3));
Now y will be assigned the value 12 because the inner getDoubled call returns 6, which is passed as the parameter to the outer getDoubled call which then returns 12.
Since function calls are just expressions they can be used anywhere an expression is expected, like in an if statement:
if (getDoubled(y) < z) { /* ... */ }
In fact, we can even use the bool return type to write functions we might call directly in an if statment:
bool isLess(int x, int y)
{
return x < y;
}
So now we could write something like:
if (isLess(z, 5)) { /* ... */ }
Admittedly doing this is pretty pointless since you could also just write z < 5 in there. This is just to illustrate how this works without getting bogged down in irrelevant details.
So the return type describes the type of value that a function call will evaluate to.
Now, with all that said, main is actually very special. It's not an ordinary function, because you're actually not permitted to call main yourself and you're even allowed to omit its return statement. The reason for this is that the operating system, which is going to run your program, needs some entry point to start running from.
Unlike Python, C++ doesn't allow "executable" code at the top level of a program, it only allows definitions and declarations (there's some wiggle-room here for initializing static variables and the like, but we'll ignore that for now). My point here is you can't just write this as a program in a cpp file:
std::cout << "Hello world!\n";
C++ requires that these sort of statements only appear inside functions. So when the operating system goes to execute your program, where does it start? This is what the purpose of main is. It marks the entry point for your program. It's as if the operating system calls that main function whenever your program is run by a user.
This is in contrast to Python where the entry point of your program is simply the script file that was invoked. There is still technically a main, but that's inside the python executable itself and you don't have to worry about it there.
As other answers point out, the return value of the main function is purely for the purposes of the operating system to understand whether your program completed successfully or failed for some reason. And for that purpose it uses an int.
Okay, so with that out of the way, what's the deal with printing and cout? Well, this is another part of the interface between your program and the operating system. Your program actually has what are called standard streams. Usually there's 3 of them: standard output, standard input, and standard error. These are all provided in C++ as cout, cin, and cerr, respectively.
When you write to cout you're putting data into the standard output stream of your program. Any part of your program can do that. That standard output stream usually prints to the console if you've created a console application. But operating systems usually let you send that output stream to other places, like a file, or even connecting it to the input of another program.
One way to think of it is like a special file that you can write to (and likewise for cin that's a different special file that you can read from). It's one way to get data out of your program and up to where the user can see it, but it's entirely different mechanism to returning from a function.
The main() function has an an int return code on the most operating system environments. The return code is the program exit code. A value of 0 means no error, other values are mostly interpreted as errors.
However, on an OS less embedded applications (bare metal) the main function never returns and therefore the function is declared as void main().
I was looking over some example functions and methods (I'm currently in a C++ class), and I noticed that there were a few functions that, rather than being void, they were something like
int myFunction() {
// ...;
return 0;
}
Where the ellipses is obviously some other statement. Why are they returning zero? What's the point of returning a specific value every time you run a function?
I understand that main() has to be int (at least according to the standards) because it is related (or is?) the exit code and thus works with the operating system. However, I can't think of a reason a non-main function would do this.
Is there any particular reason why someone might want to do this, as opposed to simply making a void function?
If that's really what they're doing, returning 0 regardless of what the function does, then it's entirely pointless and they shouldn't be doing it.
In the C world, an int return type is a convention so that you can return your own "error code", but not only is this not idiomatic C++ but if, again, your programmer is always returning 0, then it's entirely silly.
Specifically:
I understand that main() has to be int (at least according to the standards) because it is related (or is?) the exit code and thus works with the operating system. However, I can't think of a reason a non-main function would do this.
I agree.
There's a common convention of int functions returning 0 for success and some non-zero error code for failure.
An int function that always returns 0 might as well be a void function if viewed in isolation. But depending on the context, there might be good reasons to make it compatible with other functions that returning meaningful results. It could mean that the function's return type won't have to be changed if it's later modified so it detects errors -- or it might be necessary for its declaration to be compatible with other int-returning functions, if it's used as a callback or template argument.
I suggest examining other similar functions in the library or program.
It's a convention, particularly among C programmers, to return 0 if the function did not experience any errors and return a nonzero value if there was an error.
This has carried over into C++, and although it's less common and less of a convention due to exception handling and other more object-oriented-friendly ways of handling errors, it does come up often enough.
One more issue that was not touched by other answers. Within the ellipses may be another return statement:
int myFunction() {
// ...;
if (error)
return code;
// ...;
return 0;
}
in which case myFunction is not always returning 0, but rather only when no error has occurred. Such return statements are often preferred over more structured but more verbose if/else code blocks, and may often be disguised within long, sloppy code.
Most of the time function like this should be returning void.
Another possibility is that this function is one of a series of closed-related functions that have the same signature. The return int value may signal the status, say returning 0 for success, and a few of these functions always succeed. To change the signature may break the consistency, or would make the function unusable as function objects since the signature does not match.
Is there any particular reason why someone might want to do this, as opposed to simply making a void function?
Why does your mother cut the ends off the roast before putting it in the oven? Answer: Because that's what her grandmother did. However, her grandmother did that for a simple reason: Her roast pan wasn't big enough to hold a full-sized roast.
I work with a simulation tool that in its earliest incarnations required that all functions callable by the simulation engine must return a success status: 0=success, non-zero=failure. Functions that could never fail were coded to always returned zero. The simulation engine has been able to accommodate functions that return void for a long, long, time. That returning an integer success code was the required behavior from some previous millennium hasn't stopped cargo cult programmers from carrying this behavior of writing functions that always returning zero forward to the current day.
In certain programming languages you find procedures and functions. In C, C++ and similar languages you don't. Rather you only have functions.
In practice, a procedure is a part of a program that performs a certain task. A function on the other hand is like a procedure but the function can return an answer back.
Since C++ has only functions, how would you create a procedure? That's when you would either create a void function or return any value you like to show that the task is complete. It doesn't have to be 0. You can even return a character if you like to.
Take for example, the cout statement. It just outputs something but not return anything. This works like a procedure.
Now consider a math function like tan(x). It is meant to use x and return an answer back to the program that called it. In this case, you cannot return just anything. You must return the value of the TAN operation.
So if you need to write your own functions, you must return a value based on what you're doing. If there's nothing to return, you may just write a void function or return a dummy value like 0 or anything else.
In practice though, it's common to find functions returning 0 to indicate that 'all went off well' but this is not necessarily a rule.
here's an example of a function I would write, which returns a value:
float Area ( int radius)
{
float Answer = 3.14159 * radius * radius;
return Answer;
}
This takes the radius as a parameter and returns the calculated answer (area). In this case you cannot just say return 0.
I hope this is clear.
I'm trying to convert a double to float as well as various integer types inside a dll, which is used as a Game Maker extension. I don't need a sensible result if the double doesn't fit the range of the target types, so I simply used a static_cast.
Everything works as intended when I call this code from my own test C++ application, but when it's called from Game Maker, range errors raise SIGFPE for some reason, which leads Game Maker to terminate my program with an error message.
I don't need sensible results for out-of-range conversions, but crashing is a no-no. I tried using llround instead of a cast, but it also raises the signal.
I also tried catching the signal myself by using signal(SIGFPE, SIG_IGN); right before the conversion, but it didn't change the behaviour at all. Maybe the ominous comment in the mingw signal.h has something to do with that: "SIGFPE doesn't seem to work?"
I checked the source code of a different dll used in a Game Maker extension, and the binary provided by the author performs simple cast conversions without a problem. When I compile the source myself however, the SIGFPE problem is present again. I am guessing that the author used a different compiler, but I'd prefer to stay with mingw if possible.
So, how do I either perform these conversions safely, or prevent the signal from being generated when I perform them with a simple cast? I'm using mingw-g++ 4.5.0 to compile at the moment.
Here's the function where the problem happens:
template<typename ValueType>
static double writeIntValue(double handle, double value) {
boost::shared_ptr<Writable> writable = handles.find<Writable>(handle);
if(writable) {
// Execution reaches this point
ValueType converted = static_cast<ValueType>(value);
// Execution doesn't reach this point if e.g. ValueType
// is short and value is 40000
writable->write(reinterpret_cast<uint8_t *>(&converted), sizeof(converted));
}
return 0;
}
The good solution is to perform the conversion correctly by ensuring that the source value is within the range of the target type before casting. So my code from the question could be corrected like this:
ValueType converted;
if(value >= std::numeric_limits<ValueType>::max()) {
converted = std::numeric_limits<ValueType>::max();
} else if(value <= std::numeric_limits<ValueType>::min()) {
converted = std::numeric_limits<ValueType>::min();
} else {
converted = static_cast<ValueType>(value);
}
Another option is to use numeric_cast from the Boost libraries, which throws an exception if the source value is out of range, so it has defined behaviour for all conversions.
The documentation of the Boost Numeric Conversion library contains some helpful information about how the standard defined certain conversions.
Thanks to rve for providing the correct suggestion in his answer, but unfortunately his example code is flawed, and I wanted to add some additional pointers that helped me.
Since you are using a DLL, are you sure the DLL is compiled in the same way as the program expects it? Maybe some 32/64 bit mismatch?
Also, SIGFPE can also be raised when there is an under/overflow when converting.
You can enable/disable the signal raised by this overflow by setting the mask using _FPU_SETCW (it's in fpu_control.h) My guess is that Game Maker enables this and your test program not.
I never tried this and I'm not sure mingw also has this but I hope this helps a little.
edit:
Why not making sure an overflow does not happen?
Something like:
if (value > std::numeric_limits<ValueType>::max())
{
value = std::numeric_limits<ValueType>::max();
}
else if (value < std::numeric_limits<ValueType>::min())
{
value = std::numeric_limits<ValueType>::min();
}
ValueType converted = value;
probably it's not related with conversion itself but with trying to access invalid memory (maybe stack corruptions or something like that). can you provide some code snippet?
I have a piece of templated code that is never run, but is compiled. When I remove it, another part of my program breaks.
First off, I'm a bit at a loss as to how to ask this question. So I'm going to try throwing lots of information at the problem.
Ok, so, I went to completely redesign my test project for my experimental core library thingy. I use a lot of template shenanigans in the library. When I removed the "user" code, the tests gave me a memory allocation error. After quite a bit of experimenting, I narrowed it down to this bit of code (out of a couple hundred lines):
void VOODOO(components::switchBoard &board) {
board.addComponent<using_allegro::keyInputs<'w'> >();
}
Fundementally, what's weirding me out is that it appears that the act of compiling this function (and the template function it then uses, and the template functions those then use...), makes this bug not appear. This code is not being run. Similar code (the same, but for different key vals) occurs elsewhere, but is within Boost TDD code.
I realize I certainly haven't given enough information for you to solve it for me; I tried, but it more-or-less spirals into most of the code base. I think I'm most looking for "here's what the problem could be", "here's where to look", etc. There's something that's happening during compile because of this line, but I don't know enough about that step to begin looking.
Sooo, how can a (presumably) compilied, but never actually run, bit of templated code, when removed, cause another part of code to fail?
Error:
Unhandled exceptionat 0x6fe731ea (msvcr90d.dll) in Switchboard.exe:
0xC0000005: Access violation reading location 0xcdcdcdc1.
Callstack:
operator delete(void * pUser Data)
allocator< class name related to key inputs callbacks >::deallocate
vector< same class >::_Insert_n(...)
vector< " " >::insert(...)
vector<" ">::push_back(...)
It looks like maybe the vector isn't valid, because _MyFirst and similar data members are showing values of 0xcdcdcdcd in the debugger. But the vector is a member variable...
Update: The vector isn't valid because it's never made. I'm getting a channel ID value stomp, which is making me treat one type of channel as another.
Update:
Searching through with the debugger again, it appears that my method for giving each "channel" it's own, unique ID isn't giving me a unique ID:
inline static const char channel<template args>::idFunction() {
return reinterpret_cast<char>(&channel<CHANNEL_IDENTIFY>::idFunction);
};
Update2: These two are giving the same:
slaveChannel<switchboard, ALLEGRO_BITMAP*, entityInfo<ALLEGRO_BITMAP*>
slaveChannel<key<c>, char, push<char>
Sooo, having another compiled channel type changing things makes sense, because it shifts around the values of the idFunctions? But why are there two idFunctions with the same value?
you seem to be returning address of the function as a character? that looks weird. char has much smaller bit count than pointer, so it's highly possible you get same values. that could reason why changing code layout fixes/breaks your program
As a general answer (though aaa's comment alludes to this): When something like this affects whether a bug occurs, it's either because (a) you're wrong and it is being run, or (b) the way that the inclusion of that code happens to affect your code, data, and memory layout in the compiled program causes a heisenbug to change from visible to hidden.
The latter generally occurs when something involves undefined behavior. Sometimes a bogus pointer value will cause you to stomp on a bit of your code (which might or might not be important depending on the code layout), or sometimes a bogus write will stomp on a value in your data stack that might or might not be a pointer that's used later, or so forth.
As a simple example, supposing you have a stack that looks like:
float data[10];
int never_used;
int *important pointer;
And then you erroneously write
data[10] = 0;
Then, assuming that stack got allocated in linear order, you'll stomp on never_used, and the bug will be harmless. However, if you remove never_used (or change something so the compiler knows it can remove it for you -- maybe you remove a never-called function call that would use it), then it will stomp on important_pointer instead, and you'll now get a segfault when you dereference it.
What's the best way to use NaNs in C++?
I found std::numeric_limits<double>::quiet_NaN() and std::numeric_limits<double>::signaling_NaN(). I'd like to use signaling_NaN to represent an uninitialized variable as follows:
double diameter = std::numeric_limits<double>::signaling_NaN();
This, however, signals (raises an exception) on assignment. I want it to raise an exception on use, not on assignment.
Is there any way to use signaling_NaN without raising an exception on assignment? Is there a good, portable alternative to signaling_NaN that will raise a floating point exception when used?
After looking into this some more, it looks like signaling_NaN is useless as provided. If floating point exceptions are enabled, then calling it counts as processing a signaling NaN, so it immediately raises an exception. If floating point exceptions are disabled, then processing a signaling NaN automatically demotes it to a quiet NaN, so signaling_NaN doesn't work either way.
Menkboy's code works, but trying to use signaling NaNs runs into other problems: there's no portable way to enable or disable floating point exceptions (as alluded to here and here), and if you're relying on exceptions being enabled, third party code may disable them (as described here).
So it seems like Motti's solution is really the best choice.
What signaling NAN means is that when the CPU encounters it a signal is fired, (hence the name). If you want to detect uninitialized variables then raising the warning level on your compiler usually detects all paths that use uninitalized values. Failing that you can use a wrapper class that stores a boolean saying if the value is initialized:
template <class T>
class initialized {
T t;
bool is_initialized;
public:
initialized() : t(T()), is_initialized(false) { }
initialized(const T& tt) : t(tt), is_initialized(true) { }
T& operator=(const T& tt) { t = tt; is_initialized = true; return t; }
operator T&() {
if (!is_initialized)
throw std::exception("uninitialized");
return t;
}
};
You can write a signalling NaN into a variable without triggering an exception with something like this (nb: untested)
void set_snan( double &d )
{
long long *bits = (long long *)&d;
*bits = 0x7ff0000080000001LL;
}
It'll work most places, but no, it's not 100% portable.
Well, looking after the definition of both quiet and signaling NaN, I can't really make out any difference.
You could use the code that is used in those functions yourself, maybe it prevents an exception that way, but seeing no exception in those two functions, I think it might be related to something else.
If you want to directly assign the NaN:
double value = _Nan._Double;
Simple answer:
Do something like this in the header file and use it everywhere else:
#define NegativeNaN log(-1)
If you wish to do some kind of manipulations on them better write some extended wrapper function around exp() like extended_exp() and so on!
Your C++ implementation may have an API for accessing the floating point environment to test for and clear certain floating point exceptions. See my answer to a related question for more information.