|
Almost forgot one entire category: Reverse Engineering.
|
|
|
|
|
@Member 14088880,
Thanks for the your response!
|
|
|
|
|
Never entirely but for sections yes.
It is extremely common on hardware interface code, context switching and sensitive task and API areas because there are very exacting requirements that can not be described by a language even as low as C, much less by a high level language.
In vino veritas
|
|
|
|
|
I use assembly with Microchip's PIC microcontrollers: most of the code is written in C or C++, but some routines are coded using assembly.
|
|
|
|
|
The last time I uses anything that low level was to optimize some functions for SSE. Several years before that it was to modify the boot loader in an embedded system.
In the late 1980s and early 1990s, I spent the first three years of my career writing the main product code in assembly (6502 and then 8086) with C for the utilities. The benefits in size and speed were enormous. By the late 1990s, that benefit had shrunk. Even in the embedded space, costs of assembly (mostly time) usually outweigh the benefits.
|
|
|
|
|
|
I hope I can explain this problem.
I can make an instance of a class in my main()
CLASS_I2CIO i2c_ads1115(DEVICE_I2C,ADDRESS_ADS);
no problema.
But if I add same code as class variable - I need an access to the class form main() - I get the following error.
class C_VNA {
public:
C_VNA();
virtual ~C_VNA();
C_Utility utility;
CLASS_LCM1602 i2c; CIOCTLGPIO gpio; C_IOCTL_SPI spi; C_DDS_60 dds; C_AD8302_Detector det;
C_ADS1115 ads;
CLASS_I2CIO i2c_ioctl;
error here
CLASS_I2CIO i2c_ads1115_test(DEVICE_I2C,ADDRESS_ADS);
error here
};
Partial compiler output
Compiler executable checksum: 606522cdd68a1ba2fd9e2930e9d38d0d
In file included from ../src/MODULES/M_VNA/CVNA.cpp:8:0:
../src/MODULES/M_VNA/CVNA.h:28:20: error: expected identifier before string constant
#define DEVICE_I2C "dev/i2c-1"
^
../src/MODULES/M_VNA/CVNA.h:60:36: note: in expansion of macro ‘DEVICE_I2C’
src/MODULES/M_VNA/subdir.mk:18: recipe for target 'src/MODULES/M_VNA/CVNA.o' failed
CLASS_I2CIO i2c_ads1115_test(DEVICE_I2C,ADDRESS_ADS);
^
../src/MODULES/M_VNA/CVNA.h:28:20: error: expected ‘,’ or ‘...’ before string constant
#define DEVICE_I2C "dev/i2c-1"
^
../src/MODULES/M_VNA/CVNA.h:60:36: note: in expansion of macro ‘DEVICE_I2C’
CLASS_I2CIO i2c_ads1115_test(DEVICE_I2C,ADDRESS_ADS);
^
make: *** [src/MODULES/M_VNA/CVNA.o] Error 1
There is nothing special about #defines
#define DEVICE_SPI "dev/spidev0.0"
#define DEVICE_I2C "dev/i2c-1"
#define ADDRESS_HITACHI 0x27
#define ADDRESS_ADS 0x48
The error "points " to #define which is redefined in this class - temporary for test purposes.
I did look thru similar problems and they all indicate the #define is NOT the issue, however I am unable to figure this out and correct it.
Any help would be appreciated.
Cheers
|
|
|
|
|
Where is the definition of CLASS_I2CIO and its constructors?
|
|
|
|
|
Here is the part in question
class CLASS_I2CIO {
public:
CLASS_I2CIO();
CLASS_I2CIO(char Device, int Address);
CLASS_I2CIO(int width, int length, int height)
: m_width(width), m_length(length), m_height(height)
{}
CLASS_I2CIO(char *x1, int y1);
this is the one which fails
CLASS_I2CIO(char *x1, int y1, int Width, int Height);
private:
char *device;
int address;
int width, height;
public:
virtual ~CLASS_I2CIO();
int FileDescriptor = 0;
__u8 reg;
__s32 res;
char buffer[10]= { };
|
|
|
|
|
That is incomplete, and will not even compile, so it is impossible to guess what else may be wrong.
[edit]
See Graham's answer below.
[/edit]
modified 14-Jan-19 5:52am.
|
|
|
|
|
CLASS_I2CIO(char Device, int Address);
Surely you mean char* Device, not char Device?
If the erroneous line is supposed to be an initialization of a variable calling this constructor, then that is not going to work: you can not initialize a member variable right inside the class declaration, unless it is static. Instead you have to do the initialization inside the constructor, like this:
class C_VNA {
C_VNA();
...
CLASS_I2CIO i2c_ads1115_test; };
...
C_VNA::C_VNA()
: i2c_ads1115_test(DEVICE_I2C,ADDRESS_ADS)
{
}
[edit2]reintroduced tags [/edit]
modified 17-Jan-19 7:28am.
|
|
|
|
|
Stefan_Lang wrote: had to remove tags - for some reason they are not working!?
Look at the checkboxes below the edit window. Do you have "Treat my content as plain text, not as HTML" set?
|
|
|
|
|
Thanks, that was indeed the problem. No idea why it was checked - I almost always use tags. 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Vaclav_ wrote: The error "points " to #define which is redefined in this class - temporary for test purposes.
Are you doing something like this?
#include "spi.h" // #defines DEVICE_SPI, etc
#define DEVICE_SPI_"dev/spidev0.0" // Temporary define
class C_VNA {
};
That would mean that you're re-defining DEVICE_SPI, but normally your compiler should warn about redifines. Maybe you need #undef where you set up your temp defines. e.g.
#ifdef DEVICE_SPI
#define ORIG_DEVICE_SPI DEVICE_SPI
#undef DEVICE_SPI
#endif
#define DEVICE_SPI "dev/spidev0.0"
#ifdef ORIG_DEVICE_SPI
#undef DEVICE_SPI
#define DEVICE_SPI ORIG_DEVICE_SPI
#undef ORIG_DEVICE_SPI
#endif
|
|
|
|
|
Inside a function, this declares a variable called i2c_ads1115 with type CLASS_I2CIO and calls the constructor with the two values DEVICE_I2C and ADDRESS_ADS:
CLASS_I2CIO i2c_ads1115(DEVICE_I2C,ADDRESS_ADS);
Inside a class definition it declares a member function called i2c_ads1115 that returns a CLASS_I2CIO type and takes two arguments, which is where the compiler is having problems. Instead of DEVICE_I2C being a type, you have a #defined string.
To get i2c_ads1115 as a member variable, declare it the same way as the i2c_ioctl member variable, then construct it with arguments in the initialization list of the C_VNA class.
|
|
|
|
|
Thanks, I'll give it a go.
One more question.
Why I have no issue with using same syntax making an instance of the class in main ()?
Stupid question - could I just change the #define to "include" type ?
|
|
|
|
|
I can't say why that syntax defines a variable using a constructor in one place and declares a member function in another - you would have to ask the people who designed C++ that.
Making the #define include the type would probably give you a different error message, but it would still be attempting to declare a member function.
|
|
|
|
|
The compiler expects a function signature, but the function arguments you specified are missing a type.
Try somthing like this
CLASS_I2CIO i2c_ads1115_test(const char* DEVICE_I2C, int ADDRESS_ADS);
(not sure what type the second argument is supposed to be)
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Second argument function is an I2C device address = in this case A/D converter ADS1115.
|
|
|
|
|
Suppose I have a function that takes an array pointer and an index declared as type unsigned int and the function will access the array at that index.
AFAIK "Index < 0" should never evaluate to be true regardless of what the caller passed because the unsigned type will control how the bits at the address of Index are interpreted and there will be no interpretation of a bit as an indication of sign.
So implicitly an unsigned int is not capable of an access violation Below / before an array's first element given the pointer arithmetic. All that being said it does not seem at all necessary to test it.
There are other reasons to use the test however.
#1 it may improve readability as someone who reads the code sees that a full boundary check is being done
#2 it may make the code symmetric with other code that tests upper and lower boundaries of any other type of variable
#3 if the function is later modified and the type is accidentally changed to int (for example the types are changed when porting to a different machine architecture) or the code is copy and pasted to a different context where Index is not unsigned, omitting the bounds check introduces the possibility of an access violation
#4 I think it's possible, perhaps likely, that an intelligent compiler will optimize it out completely, even if it didn't we're not talking about a grave loss of efficiency.
So although I feel stupid writing what seems to be redundant and unnecessary code and concern myself with conciseness, for a robust application it seems worthwhile.
|
|
|
|
|
I would keep it simple: an unsigned cannot be less than zero, full stop.
|
|
|
|
|
CPallini wrote: I would keep it simple: an unsigned cannot be less than zero, full stop.
This simple fact seems to be no longer on the curriculum! Wrote a bit about it to the caller!
I feel that an awfull lot of skills are no longer taught, the same skills I had to learn myself, e.g. How does a computer actually work! Registers,Stackpointers, The Stack and the Heap, the function of the OS, Machine Code, what does an assembler do, what does a compiler do, etc. I will encourage anyone willing to study 'C' or 'CPP'. These people on this queery seem to be basically stuck on the underlying hardware concepts.
Kind Regards,
Bram van Kampen
|
|
|
|
|
Member 14088880 wrote:
So implicitly an unsigned int is not capable of an access violation Below / before an array's first element given the pointer arithmetic. All that being said it does not seem at all necessary to test it.
If your function looked something like:
void myfunction(int array[], unsigned int count)
{
for (unsigned x = 0; x < count; x++)
...
}Then it is possible to call it like:
myfunction(array, -1); which would result in the for() loop running for a very long time.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
I'm genuinely surprised and my paranoia has been rewarded. I think I've misunderstood something fundamental. Here is a code sample:
#include <stdio.h>
void print_iterator(int integer_array[], unsigned int index)
{
unsigned int i;
if(index < 0)
{
printf("Index violation!\n");
return;
}
else
printf("Passed index validation: %d, as %u\n", index, index);
for(i = 0; i < index; i++)
{
if(i == 20)
{
printf("Loop overrun, undefined behavior\n");
return;
}
}
}
main()
{
int ints[] = { 1, 2, 3, 4, 5, 6, 7, 8 };
print_iterator(ints, -1);
}
If the index argument is declared as an unsigned int, it seems it will ALWAYS pass the bounds check when -1 is passed as the parameter, and produce this output:
Quote: Passed index validation: -1, as 4294967295
Loop overrun, undefined behavior
Press any key to continue . . .
If it is declared as an int (uncomment the first function line, comment out the second one) it will work properly:
Quote: Index violation!
Press any key to continue . . .
Anyone know why?
|
|
|
|
|
Member 14088880 wrote:
If the index argument is declared as an unsigned int, it seems it will ALWAYS pass the bounds check when -1 is passed as the parameter...
Of course, hence why I said the for() loop would run for a long time.
Member 14088880 wrote:
If it is declared as an int (uncomment the first function line, comment out the second one) it will work properly:
And that would be expecxted behavior.
Why do you have an aversion in using a range check on index?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
