int64_t is signed. Although it does not make a difference by itself, because
INT64_MAX is still a valid number for uint64_t (UL), the later INT64_MIN
declaration depends on INT64_MAX, and therefore got implicitly casted to
unsigned type.
This fixes the following program on a x86_64 system:
#include <stdint.h>
int main() {
int64_t test = 5;
if (test < INT64_MIN)
return 1;
return 0;
}
This is a regression since commit 1d13a609 ("stdint.h: define [U]INT64[MAX|MIN]
with [U]L on x86_64").
Signed-off-by: Jerome Duval <jerome.duval@gmail.com>
The menu item to set the "Window title..." makes more sense in the
"Settings" menu. There you find other settings that only apply to
the running session, like window size or text encoding.
The "Edit" menu OTOH has only commands to deal with the contents
in the Terminal, like copy, paste, find etc.
Could lead to wrongly setting the TYPE_MINUTE flag for an invalid (>59)
number of minutes. Harmless, as that flag is never used.
For completeness, also set the flag for seconds (also never used).
Fixes#11552.
If the text in the button is longer than what the minimal size of
BButton allows, the button exapnd. But we want the two buttons to have
the same width and stay aligned.
Fixes part of #11471.
Note: I don't understand why I need to set the explicit max size of the
button to make it bigger (I would have expected setting the minimal size
to do that), but it works.
get_vnode could be called with a NULL privateNode in the kernel, but not
in userlandfs. This would crash in cdda mount code (and from a grep
search, also with several other filesystems).
Now cdda can be mounted with userlandfs, and CDs read that way, but for
some reason there is no CDDB renaming of the tracks in that case.
The menu would try to relayout itself, but fail to get the supermenu
bounds as the looper for it was not locked in that case.
This fixes the crash with two downsides:
* The menu width isn't adjusted to match the parent menu (mostly visible
in BMenuFields)
* There is some flickering as the menu is updated
Fixes#9863 (Network prefs part).
- Expression evaluation results are now highlighted as changed when
they're first added, since they're immediately of interest, unlike
uninitialized variables that're first coming into scope.
Get rid of ExpressionEvaluationWindow.
- When asking to evaluate an expression via the Tools menu, we now
bring up a prompt window the same as the one used to add a watch
expression. This in turn works exactly the same as the latter,
except an additional flag is sent indicating that the expression
in question should not be persisted. As such, the results are
shown in the variables view, with all the capabilities that allows,
but also without the expression following the function as a watch
expression would.
