What is the difference between struct reg and struct user_regs_struc on Linux 64 bit machine?
struct user_regs_struct
{
unsigned long r15;
unsigned long r14;
unsigned long r13;
unsigned long r12;
unsigned long rbp;
unsigned long rbx;
unsigned long r11;
unsigned long r10;
unsigned long r9;
unsigned long r8;
unsigned long rax;
unsigned long rcx;
unsigned long rdx;
unsigned long rsi;
unsigned long rdi;
unsigned long orig_rax;
unsigned long rip;
unsigned long cs;
unsigned long eflags;
unsigned long rsp;
unsigned long ss;
unsigned long fs_base;
unsigned long gs_base;
unsigned long ds;
unsigned long es;
unsigned long fs;
unsigned long gs;
};
This struct can be found in /usr/include/x86_64-linux-gnu/sys
According to this link struct reg is
struct reg {
register_t fixreg[32];
register_t lr;
register_t cr;
register_t xer;
register_t ctr;
register_t pc;
};
in freeBsd file: sys/powerpc/include/reg.h
And yes I did not found this struct in my debian 64bit system.
Related
This is the prologue of the header CGO generated:
#ifndef GO_CGO_PROLOGUE_H
#define GO_CGO_PROLOGUE_H
typedef signed char GoInt8;
typedef unsigned char GoUint8;
typedef short GoInt16;
typedef unsigned short GoUint16;
typedef int GoInt32;
typedef unsigned int GoUint32;
typedef long long GoInt64;
typedef unsigned long long GoUint64;
typedef GoInt64 GoInt;
typedef GoUint64 GoUint;
typedef __SIZE_TYPE__ GoUintptr;
typedef float GoFloat32;
typedef double GoFloat64;
typedef float _Complex GoComplex64;
typedef double _Complex GoComplex128;
Now, trying to compile with MSVC, which has no clue as to what __SIZE_TYPE__ is or _Complex is not going to fly. I could probably come up with an extra header that covers these discrepancies, but I don't know what else does CGO header generator has up its sleeve.
#include<stdio.h>
int main()
{
int ret = -1071;
if(ret == 0xfffffbd1)
{
printf("HAHAHA");
}
return 0;
}
why does the GCC compiler recognize the const variable 0xfffffbd1 as unsigned int as the condition ret == 0xfffffbd1
The C standard says that [t]he type of an integer constant is the first of the corresponding list in which its value can be represented (paragraph 6.4.4.1/5 in C99), and for hexadecimal types without a suffix, this list is:
int
unsigned int
long int
unsigned long int
long long int
unsigned long long int
Assuming a 32-bit int type, 0xfffffbd1 is larger than INT_MAX but less than UINT_MAX, so the type of the constant is unsigned int.
Assuming 32 bit int type
At first time:
I defined a signed int ret = -1071 and executed the expression ret == 0xfffffbd1, the default type of const variable 0xfffffbd1 is signed integer(the sign bit is 1, which is a negative number), so result of the expression is TRUE
The second time
I updated the ret type to long long int, let ret = -1071 and executed the expression ret == 0xfffffbd1, the expression result is FALSE, the default type of 0xfffffbd1 is signed long long int(sign bit is 0, which is a positive number), if i updated the right value to 0xfffffffffffffbd1, the result of expression will return TRUE
The following code produces a huge list of compiler errors:
/// Uses template recursion to bind all args
template<std::size_t N, typename... Args> class Binder
{
public:
Binder(Sqlite3StatementBase &s, std::tuple<Args...> &tup)
{
Binder<N - 1, Args...> b(s, tup);
s.bind(N + 1, std::get<N, Args...>(tup)); // Line 182
}
};
/// Specialization of Binder to end recursion at 0
template<typename... Args> class Binder<0, Args...>
{
public:
Binder(Sqlite3StatementBase &s, std::tuple<Args...> &tup)
{
s.bind(1, std::get<0, Args...>(tup));
}
};
The first batch of errors consists of:
In file included from /usr/include/c++/6/bits/unique_ptr.h:37:0,
from /usr/include/c++/6/condition_variable:43,
from /home/tony/htpc/Dev/logi/src/db/logi-db.h:22,
from /home/tony/htpc/Dev/logi/src/db/logi-sqlite.h:26,
from /home/tony/htpc/Dev/logi/src/db/logi-sqlite.cpp:24:
/usr/include/c++/6/tuple: In instantiation of ‘class std::tuple_element<1ul, std::tuple<unsigned int> >’:
/usr/include/c++/6/tuple:1228:12: recursively required from ‘class std::tuple_element<2ul, std::tuple<unsigned int, unsigned int> >’
/usr/include/c++/6/tuple:1228:12: required from ‘class std::tuple_element<3ul, std::tuple<unsigned int, unsigned int, unsigned int> >’
/usr/include/c++/6/utility:106:69: required by substitution of ‘template<long unsigned int __i, class _Tp> using __tuple_element_t = typename std::tuple_element::type [with long unsigned int __i = 3ul; _Tp = std::tuple<unsigned int, unsigned int, unsigned int>]’
/usr/include/c++/6/tuple:1270:5: required by substitution of ‘template<long unsigned int __i, class ... _Elements> constexpr std::__tuple_element_t<__i, std::tuple<_Elements ...> >&& std::get(std::tuple<_Elements ...>&&) [with long unsigned int __i = 3ul; _Elements = {unsigned int, unsigned int, unsigned int}]’
/home/tony/htpc/Dev/logi/src/db/logi-sqlite.h:182:47: required from ‘logi::Sqlite3Database::Binder<N, Args>::Binder(logi::Sqlite3Database::Sqlite3StatementBase&, std::tuple<_Elements ...>&) [with long unsigned int N = 3ul; Args = {unsigned int, unsigned int, unsigned int}]’
/home/tony/htpc/Dev/logi/src/db/logi-sqlite.h:238:71: required from ‘void logi::Sqlite3Database::Sqlite3Statement<Args>::prepare_row(logi::Sqlite3Database::Sqlite3Statement<Args>::Tup&) [with Args = {unsigned int, unsigned int, unsigned int}; logi::Sqlite3Database::Sqlite3Statement<Args>::Tup = std::tuple<unsigned int, unsigned int, unsigned int>]’
/home/tony/htpc/Dev/logi/src/db/logi-sqlite.h:231:28: required from ‘void logi::Sqlite3Database::Sqlite3Statement<Args>::execute(typename logi::Sqlite3Database::Sqlite3Statement<Args>::Parent::ArgsVector&) [with Args = {unsigned int, unsigned int, unsigned int}; typename logi::Sqlite3Database::Sqlite3Statement<Args>::Parent::ArgsVector = std::vector<std::tuple<unsigned int, unsigned int, unsigned int>, std::allocator<std::tuple<unsigned int, unsigned int, unsigned int> > >]’
/home/tony/htpc/Dev/logi/src/db/logi-sqlite.cpp:354:1: required from here
/usr/include/c++/6/tuple:1228:12: error: invalid use of incomplete type ‘class std::tuple_element<0ul, std::tuple<> >’
So it seems as if the std::get call is causing other parts of the system libraries (not directly related to std::get or std::tuple) to recursively reduce Args... to nothing, and this is happening independently of my recursion of the numerical template parameter N. Is there something I can fix in my code without fundamentally changing my approach, or is it just not possible to use std::get in a context where the tuple's template parameters are variadic?
Given an implementation of the C++14 make_index_sequence function (and its associated types), you can do what you want easily enough:
template<size_t ...indices, typename ...Args>
void binder_helper(Sqlite3StatementBase &s, std::integer_sequence<size_t, indices...>, std::tuple<Args...> &tup)
{
auto dump = {(s.bind(indices, std::get<indices>(tup)), 0)...};
}
template<typename ...Args>
void binder(Sqlite3StatementBase &s, std::tuple<Args...> &tup)
{
binder_helper(s, std::make_index_sequence<sizeof...(Args)>(), tup);
}
With C++17's fold expressions, the oddball stuff in binder_helper can be reduced to something much more reasonable:
template<size_t ...indices, typename ...Args>
void binder_helper(Sqlite3StatementBase &s, std::integer_sequence<size_t, indices...>, std::tuple<Args...> &tup)
{
(s.bind(indices, std::get<indices>(tup)), ...);
}
Note that in the latter case, the standard does not guarantee thatt the calls to s.bind will be executed in order. In the former case, because the expressions are wrapped in a braced-init-list, you're guaranteed in-order evaluation.
I am getting the following error even though it seems there are no syntax errors.
usb_libusb10.h(72): error C2146: syntax error : missing ';' before identifier 'cb'
The line where the error is generating is given below-
fnusb_iso_cb cb;
I also tried to highlighted this line by using "**" in the code.
Following is the code I am using.
#pragma once
#include <Windows.h>
#include <afxwin.h>
#include "libfreenect.h"
#include <libusb.h>
// There are a few rules: PKTS_PER_XFER * NUM_XFERS <= 1000, PKTS_PER_XFER % 8 == 0.
#if defined(__APPLE__)
#define DEPTH_PKTBUF 2048
#define VIDEO_PKTBUF 2048
#define PKTS_PER_XFER 128
#define NUM_XFERS 4
#else
#define DEPTH_PKTBUF 1920
#define VIDEO_PKTBUF 1920
#if defined(_WIN32)
#define PKTS_PER_XFER 32
#define NUM_XFERS 8
#else
#define PKTS_PER_XFER 16
#define NUM_XFERS 16
#endif
#endif
typedef struct {
libusb_context *ctx;
int should_free_ctx;
} fnusb_ctx;
typedef struct {
freenect_device *parent; //so we can go up from the libusb userdata
libusb_device_handle *dev;
int device_dead; // set to 1 when the underlying libusb_device_handle vanishes (ie, Kinect was unplugged)
int VID;
int PID;
} fnusb_dev;
typedef struct {
fnusb_dev *parent; //so we can go up from the libusb userdata
struct libusb_transfer **xfers;
uint8_t *buffer;
**fnusb_iso_cb cb;**
int num_xfers;
int pkts;
int len;
int dead;
int dead_xfers;
} fnusb_isoc_stream;
int fnusb_num_devices(fnusb_ctx *ctx);
int fnusb_list_device_attributes(fnusb_ctx *ctx, struct freenect_device_attributes** attribute_list);
int fnusb_init(fnusb_ctx *ctx, freenect_usb_context *usb_ctx);
int fnusb_shutdown(fnusb_ctx *ctx);
int fnusb_process_events(fnusb_ctx *ctx);
int fnusb_process_events_timeout(fnusb_ctx *ctx, struct timeval* timeout);
int fnusb_open_subdevices(freenect_device *dev, int index);
int fnusb_close_subdevices(freenect_device *dev);
int fnusb_start_iso(fnusb_dev *dev, fnusb_isoc_stream *strm, fnusb_iso_cb cb, unsigned char endpoint, int xfers, int pkts, int len);
int fnusb_stop_iso(fnusb_dev *dev, fnusb_isoc_stream *strm);
int fnusb_get_max_iso_packet_size(fnusb_dev *dev, unsigned char endpoint, int default_size);
int fnusb_control(fnusb_dev *dev, uint8_t bmRequestType, uint8_t bRequest, uint16_t wValue, uint16_t wIndex, uint8_t *data, uint16_t wLength);
int fnusb_bulk(fnusb_dev *dev, uint8_t endpoint, uint8_t *data, int len, int *transferred);
int fnusb_num_interfaces(fnusb_dev *dev);
I have an unsigned int variable and it can only have the values of 0 -> 30. What should I use: unsigned int or NSUInteger? (for both 32 and 64 bit)
I’d go with either NSUInteger (as the idiomatic general unsigned integer type in Cocoa) or uint8_t (if size matters). If I expected to be using 0–30 values in several places for the same type of data, I’d typedef it to describe what it represents.
Running this:
int sizeLong = sizeof(unsigned long);
int sizeInt = sizeof(unsigned int);
NSLog(#"%d, %d", sizeLong, sizeInt);
on 64bits gives:
8, 4
on 32 bits gives:
4, 4
So that yes, on 64 bits unsigned long (NSUInteger) takes twice as much memory as NSUInteger on 32 bits.
It makes very little difference in your case, there is no right or wrong. I might use an NSUInteger, just to match with Cocoa API stuff.
NSUInteger is defined like this:
#if __LP64__ || TARGET_OS_EMBEDDED || TARGET_OS_IPHONE || TARGET_OS_WIN32 || NS_BUILD_32_LIKE_64
typedef long NSInteger;
typedef unsigned long NSUInteger;
#else
typedef int NSInteger;
typedef unsigned int NSUInteger;
#endif
When u really want to use some of the unsigned type, choosing between unsigned int and NSUInteger does not matter because those types are equal(comparing the range and size in 32 & 64 bit). The same applies to int and NSInteger:
#if __LP64__ || (TARGET_OS_EMBEDDED && !TARGET_OS_IPHONE) || TARGET_OS_WIN32 || NS_BUILD_32_LIKE_64
typedef long NSInteger;
typedef unsigned long NSUInteger;
#else
typedef int NSInteger;
typedef unsigned int NSUInteger;
#endif
Personally, I have just been bitten by this choice. I went down the NSUInteger route and have just spent HOURS looking into an obscure bug.
I had code that picked a random number and returned an NSUInteger. The code for the relied on the overflow of the number. However I did not anticipate that the size of the number varied between 32bit and 64bit systems. The rest of my code assumed (incorrectly) that the number would be up to 32 bit in size. The result is the code worked perfectly under 32 bit devices, but on iPhone 5S, it all fell apart.
There is nothing wrong with using NSUInteger, however its worth remembering that the number range is significantly higher so factor this dynamicism into any maths you do with that number.