Code that assumes time_t is the same width as int is already broken, and won't work on typical 64-bit systems were int is 32 bits and time_t is 64 bits.
In any case, I'm not sure I've ever seen any such code.
2,297 karma · joined March 20, 2012
In any case, I'm not sure I've ever seen any such code.
If you write:
{
int n = 42;
printf("%d\n", n);
}
Memory for objects defined in nested blocks is logically allocated on entry to the block, but compilers commonly merge the allocation into the function entry code. Even so, objects in parallel blocks can certainly share memory:
int main(void) {
{
int a;
}
{
int b; // might share memory with a
}
}
The only reason that might be surprising is that the "return *p;" statement refers to the value of an object at a point (textually) before its definition. But the lifetime of the object named "v" begins on entry to the innermost compound statement enclosing its definition -- in this case the body of "main".
Space for "v" is allocated on entry to "main". It's initialized to 1 when its definition is reached. The "return *p;" statement appears before the definition of "v" in the program source, but is executed after its definition was reached at run time, and within its lifetime.
It's important to remember that scope and lifetime are two different things. The scope of an identifier is the region of program text in which the identifier is visible; for "v" it extends from the definition to the closing "}". The lifetime of an object is the time span during execution in which it exists; for "v" it extends from the time when execution reaches the opening "{" to the time when execution reaches the closing "}". Formally, storage for "n" is allocated at the beginning of its lifetime and deallocated at the end of its lifetime. Compilers can and do optimize allocation and deallocation, as long as the visible behavior is consistent.
Aside: If "v" were a VLA (variable length array, introduced in C99, made optional in C11) its lifetime would begin when execution reaches its definition.
#include <stdio.h>
int main(void) {
int count;
printf("%s%n\n", "hello, world", &count);
printf("count = %d\n", count);
}
hello, world
count = 12
%n can be exploited, but it's entirely possible to use it safely.
I ran into two problems.
1. Poor coverage of non-ASCII characters (it won't display simple accented letters, pound sign, euro sign, etc.).
2. []{} are cut off at the top.
You have to quote or escape the parentheses because they're shell metacharacters, which IMHO makes that syntax more trouble than it's worth.
Other commands that work are "man 3 printf", "man -s 3 printf", and "man printf.3". I think "man 3 printf" is the oldest version.
At least one other version of the man command (NetBSD) doesn't accept "man printf.3" or "man 'printf(3)'".
If you can extend your terminal window across your two monitors and run `tcvt` within it, that might suit your purposes.
xterm supports sixel graphics.
"sixel" is an image file format; the ImageMagic "convert" command can convert other formats to it. Just cat a sixel file to stdout in an xterm and it's displayed in the window.
The implementation is not 100% solid (for example, there's a size limit), but it does work. And tmux can be build with sixel support, so you can display sixel images in tmux under xterm.
convert foo.png sixel:-
convert -geometry 600x600 large.png sixel:-
No, there's no video support (unless I've missed something).
I'm fairly sure that all existing C compilers will quietly accept "int main()", but there's an argument that "int main()" causes the program to have undefined behavior. "int main(void)" is the form documented in the standard.
And the "return 0;" is unnecessary both in C++ and in all versions of C starting with C99. (Some will argue that it's better style to be explicit.)
These are admittedly minor points.
(I don't think everyone has moved to it. I had never heard of it myself.)
I'm very probably not the target audience for this, but the README should have enough information to tell me I'm not the target audience.
(From that site: "Vite (French word for "quick", pronounced /vit/, like "veet") is a build tool that aims to provide a faster and leaner development experience for modern web projects.")
< x Y | Z > w
Something that "cat file | ..." advocates might be overlooking is that a redirection ("<inputfile", ">outputfile", "2>errorfile") can appear anywhere within a simple command, so these:
command -option < file
< file command -option
command < file -option
cat file | command -option
Part of it is backward compatibility: code written to assume 32-bit int could break. (Arguably such code is badly written, but breaking it would still be inconvenient.)
Another part is that C has a limited number of predefined integer types; char, short, int, long, long long (plus unsigned variants and signed char). If char is 8 bits and int is 64 bits, then you can't have both a 16-bit and a 32-bit integer type. Extended integer types (introduced in C99) could address this, but I don't know of any compilers that provide them.
"What's the best way to write a multi-statement macro?"
$ gen-password -len 16 -lower -1upper -1digit -1punct
e$hmvcel9nyghAyw
The system stored timestamps as a string representing seconds since the epoch, but it assumed it would fit in 9 digits. At 1000000000, it started dropping the last digit, so it went back to Sat 1973-03-03 01:46:40 PST, advancing at 10% of real time. It was fixed fairly quickly.
Updated magnitude is 3.7.
If I'm being pedantic, I might add something like
#if CHAR_BIT != 8
#error "This code assumes 8-bit char"
#endif
A byte is CHAR_BIT bits, where CHAR_BIT >= 8. (It's exactly 8 on most implementations; DSPs are the most common exception).
short and int are both required to be at least 16 bits wide. It's possible for int to be 1 byte (sizeof (int) == 1), but only if CHAR_BIT >= 16.
China built a similar radio telescope that went into service in 2016. https://en.wikipedia.org/wiki/Five-hundred-meter_Aperture_Sp...
I think you meant stdout here, not stderr.
tool [args] 2>&1 | less