According to [this:](https://people.csail.mit.edu/albert/bluez-intro/c404.html#:~:text=The inquiry lasts for at most 1.28 \* len seconds) the timeout is at most len * 1.28 seconds. Since you've got a value of 16 for ii, then you can expect hci_inquiry() to take no more than 20.48 seconds. Since ~7 < 20.48, it looks to me that hci_inquiry is working as advertised.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
Long before CTRL+C/CTRL+V were used for cut/paste, Unix terminals were using CTRL+C to send SIGINT and CTRL+V was being used as "quote next char" (e.g. CTRL+C CTRL+C would add a char(0x03) to the input stream. Both gnome-terminal and QT Konsole support CTRL+SHIFT+C/CTRL+SHIFT+V to cut/paste, though.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
If you go to the "tree" link as suggested by Indivara, there's a "snapshot" button that will download the latest version for you.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
I left out unions, since technically writing to one union member and reading from another in C/C++ invokes undefined behavior. [Undefined Behavior in C++](https://adriann.github.io/undefined\_behavior.html) Note that while the standard says that it is undefined behavior, I have not run into any compilers that this doesn't work, at least with POD. Use of constructed/destructed objects in a union is not something I've tried, but you can probably see that there may be issues if you want to have a union of std::string and std::vector, for example. Trying to write as a std::string and then read as a std::vector is almost certainly going to result in Bad Things™ occuring.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
All memory is just bits and bytes. How one interprets the bytes is up to the user. If you open a file and write an integer to it, you'll store 4 bytes, which could be read in as 4 characters by some other program. There's no meta-information about what the data object (file, memory, etc) associated with a datum anywhere in the OS. At least that's true for Windows, DOS, Unix, Linux, VMS, etc. There may be some OS out there that does use meta-data to determine what type a particular datum has, but I'm not aware of it.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
It seems like you're still trying to connect /dev/rfcomm0 and /dev/ttyUSB0 together, so that a write to one will write to the other. As explained previously, that's not how a link works. Creating a link could be thought of as providing a different name for the same object. So for example, suppose you live at 42 Main Street. Creating a link is like adding the number 24 to your house. If you tell someone you live at 24 Main Street, or 42 Main Street, they find the same house, either way. As far as I know, there's no way to multiplex 2 files together. At least not in the Unix/Linux world. Maybe Windows does this? You do know that /dev in all but very old Linux systems is a virtual file system, and gets recreated every time you reboot? It's actually quite dynamic. For example as you plug-in and unplug USB devices, new /dev entries get added and removed as needed. My other suspicion is that you're trying to create /dev/rfcomm0 incorrectly. when you ls a device file, you get something like crw------- 1 root root 4, 1 Sep 23 08:17 /dev/tty1. The "c" at the start of the permissions string indicates its a character device, and 4, 1 indicate the MAJOR and MINOR device numbers. The major device number is, more or less, an index into the kernel's device driver table, and the minor is, once again more or less, the specific device to do I/O with. So in the case above, the MAJOR is 4, a console TTY device, and 1 is the tty number. Similarly /dev/tty2 has MAJOR,MINOR 4,2 etc. I'm guessing that /dev/rfcomm0 should be some sort of radio frequency communication device. As such it will have it's own MAJOR/MINOR assignments, almost certainly different from what a USB Serial device would have. Additionally, an rfcomm device will probably have its own set of ioctl calls that only make sense for that device. So think about that, what happens if you could link devices together what should happen when you try to send an ioctl to one of them that the other does not recognize, via the multiplex? Should it silently fail on one, but succeed on the other? What's the return value? How would you distinguish which device had rejected the IOCTL call. Worse, an ioctl looks like ioctl(int fd, unsigned long request, ...). So a request id (say 2) to one device might turn it on and to the other might put it in diagnostic mode. I repeat, it's not quite clear what you are trying to do. If you need a /dev/rfcomm0 device file to communicate to
Way back, the UNIX filesystem only supported a physical link. So a directory entry might have been
struct dirent {
unsigned long d_ino;
char d_name[30];
};
So if your directory contained
8539501 foo
8539502 bar
8539503 baz
8539502 paw
Then it should be clear that the files bar, inode=8539502 and paw inode=8539502 are the same file, i.e a Physical (or hard) link. If you list the directory you'll see something like
[k5054@azure foo]$ ls -li
total 0
8539502 -rw-r--r-- 2 k5054 k5064 0 Oct 13 06:31 bar
8539503 -rw-r--r-- 1 k5054 k5064 0 Oct 13 06:31 baz
8539501-rw-r--r-- 1 k5054 k5064 0 Oct 13 06:31 foo
8530502 -rw-r--r-- 2 k5054 k5064 0 Oct 13 06:31 paw
The -i flag to ls add the inode, and so we can see bar and paw have the same inode (8359502). Also, column 3 shows the number of physical links to the inode, which for bar and paw are 2, but foo and baz are only one. Note that a hard link doesn't need to reside in the same directory, you can for example do something like
ln foo/bar/baz ping/pong/paw
, which will create the physical link. There are 2 restrictions to hard links: 1) you can't create a hard link between directories, and 2) you can't create hard links across file systems. Symbolic (soft) links solve both these problems. In the case of a soft link, the link can be thought of as a reference. If we take the above directory and create a soft link between foo and bang via ln -s foo bang we now get: k5054@azure foo]$ ls -li total 4 8539536 lrwxrwxrwx 1 k5054 k5064 3 Oct 13 06:48 bang -> foo 8539502 -rw-r--r-- 2 k5054 k5064 0 Oct 13 06:31 bar 8539503 -rw-r--r-- 1 k5054 k5064 0 Oct 13 06:31 baz 8539501 -rw-r--r-- 1 k5054 k5064 0 Oct 13 06:31 foo 8539502 -rw-r--r-- 2 k5054 k5064 0 Oct 13 06:31 paw This shows that the file `bang` is a symbolic link (file type "l") which points to "foo". Now "bang" acts as a pointer or an indirection. In order to get to the contents of , the OS has to open bang, read its contents and then open the file pointed to by the contents. Also, note that the size of bang is 3, ie "foo". Since we now have this indirection, we can link to files in other filesystems, and we can also create links to other directories. You're also not limited to only one indirection. A soft link can point to another soft link, to another soft link, etc. "A little song, a little dance, a little seltzer down your pants" Chuckles t
But don't do that while looking into a mirror!
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
Is this not useful? [SQLite Encryption Extension: Documentation](https://www.sqlite.org/see/doc/trunk/www/readme.wiki)
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
[Conan The Barbarian: What is best in life...? - YouTube](https://www.youtube.com/watch?v=\_XUu3\_pLPUE)
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
I find myself ambivalent about this. On the one hand, water is a basic need, so finding ways to provide it seems like it should be a no-brainer. On the other hand, if you're taking water out of the system here, then it's not available there, when it always was before, possibly creating an unintended consequence. I'm guessing if its only used for small populations, then the net effect will not be substantial. But at some point, surely someone will be wondering "Where's my water gone?".
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
As best as I can remember, C only requires that type char be large enough to hold any character in the current (system) encoding. That is, if the CPU has 7, 8, or 9 bit "bytes", then a C char would also be 7, 8 or 9 bits.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
charlieg wrote:
Would I eat my neighbor's pet? Not willing? Would I eat a rabbit, cat or dog if I was starving or my family? Absolutely.
Not only that, if you're hungry enough, all taboos are off: [Uruguayan Air Force Flight 571 - Wikipedia](https://en.wikipedia.org/wiki/Uruguayan\_Air\_Force\_Flight\_571#:~:text=During the 72 days following,died in order to survive.) [Custom of the sea - Wikipedia](https://en.wikipedia.org/wiki/Custom\_of\_the\_sea)
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
If you're not concerned about speed, then the decimal::decimal[32/64/128] numerical types might be of interest. You'd need to do some research on them, though. It's not clear how you go about printing them, for example. Latest Fedora rawhide still chokes on
#include
#include
int main()
{
std::decimal::decimal32 x = 1;
std::cout << x << '\n';
}
where the compiler produces a shed load of errors at std::cout << x , so the usefulness is doubtful. An alternative might be an arbitrary precision library like gmp A quick test of a loop adding 1,000,000 random numbers showed very little difference between unsigned long and __uint128_t For unsigned long the loop took 0.0022 seconds, and for __int128_t it took 0.0026 seconds. Slower, but not enough to not consider them as a viable data type. But as with the decimal::decimal types, you would probably have to convert to long long for anything other than basic math.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
valgrind should be an installable package.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
Yeah, it probably does. But as a starting point, you could run under valgrind, with lots of stack, to see if it detects anything it thinks is not kosher (which might be everything you're doing from it's point of view :( ) GNU libc allows you to hook various system calls : [Hooks for Malloc (The GNU C Library)](https://www.gnu.org/software/libc/manual/html\_node/Hooks-for-Malloc.html) Maybe that can help? or the Previous link on that page re heap consistency checking?
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
Also check out valgrind. It might give you some clues as to where to look.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
Can you compile on Linux? There at least you have ulimit so you could restrict your stack size. A quick google leads to Windows Resource Manager, which may or may not be available.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
This reminds me of something I read on usenet, long ago. The thread was about how to effectively decommision hard drives. One poster related how he had attended some event, and casual conversation of professionals turned to this subject. There were various solutions, including shotguns, large magnets and power saws. One of the participants said something like "I'm with the NSA, and we put our old drives in the N-Test holes, before detonation." They all laughed. Then they realized the NSA guy was serious.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
You don't need to go as far as a namespace, just a struct will do.
struct Color {
enum value { Red, Yello, Blue };
};
int main()
{
Color::value box = Color::value::Red;
}
If you want to be able to print Color::Red as a string, it's a bit more involved
#include
struct Color {
enum hue { Red, Yellow, Blue } value;
std::string as_string() {
std::string color;
switch(value) {
case Red : color = "Red"; break;
case Yellow : color = "Yellow"; break;
case Blue : color = "Blue"; break;
};
return color;
}
Color(Color::hue val) : value(val) {};
bool operator==(const Color&other) {
return value == other.value;
}
friend std::ostream& operator<<(std::ostream& os, const Color& color);
};
std::ostream& operator<<(std::ostream& os, const Color& color)
{
os << color.value;
return os;
}
int main()
{
Color x = Color::Red;
Color y = Color::Blue;
std::cout << x << '\n';
std::cout << x.as_string() << '\n';
if(x == y)
return 1;
else
return 0;
}
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown