To define or not to define

[Reynard 0]

In the header file <float.h> there is the following code.

// define types
#ifndef uint8
	typedef unsigned char uint8;
#endif

According to the manual an identifier can only be defined using the #define directive.  The #ifndef in this case is worthless and not doing the expected job.

When I do this,

// define types
#ifndef uint8
	typedef unsigned char uint8;
#endif

// define types
#ifndef uint8
	typedef unsigned char uint8;
#endif

the compiler complains as I am redefining uint8.  The second typedef is not being blocked.

So what is the #ifndef suppose to do here ?

Cheers

Reynard

 

[JorgeF 0]

Hi

21 hours ago, Reynard said:

In the header file <float.h> there is the following code.

// define types
#ifndef uint8
	typedef unsigned char uint8;
#endif

According to the manual an identifier can only be defined using the #define directive.  The #ifndef in this case is worthless and not doing the expected job.

When I do this,

// define types
#ifndef uint8
	typedef unsigned char uint8;
#endif

// define types
#ifndef uint8
	typedef unsigned char uint8;
#endif

the compiler complains as I am redefining uint8.  The second typedef is not being blocked.

So what is the #ifndef suppose to do here ?

 

Nothing, the "#ifnedf" can't do a thing there.

I guess that somewere along the way they moved the definition of "uint8" from the preprocessor to the compiler but didn't correctly adjust everything.

 

The "#ifndef" is a pre-processor directive that will only detect a symbol defined with "#define" or the equivalent command line parameter.

The "typedef" is a 'C' statement to be processed by the compiler. The preprocessor knows nothing about 'C' statements so it just ignores the "typedef".

 

AFAIK the correct way to defined a type is using "typedef", but to be able to protect it against redefinition a "#define" is needed.

So in my opinion it should be something like this.

#ifndef UINT8_T
	#define UINT8_T
	typedef unsigned char uint8
#endif

OTOH, the "stdint.h" header has all the standard integer types defined and is globally protected against multiple inclusion, so I see no point on adding this extra type definition anywhere in a project.

Some guys just like to re-invent the wheel over and over.... 

 

Probably this all thing is just an artifact/bug resulting of a chain of evoluctionary steps of the "float" lib.

 

Best regards

Jorge

Edited February 20, 2018 by JorgeF
typo correction

[Reynard 0]

So it's a bug then ?

The current version of SB 7.42 doesn't ship with a copy of stdint.h.

Not all novices know to steal a copy of stdint.h from gcc avr (or other similar compiler) and use that.

Cheers

Reynard

 

[JorgeF 0]

Hi

 

On 20/02/2018 at 1:26 PM, Reynard said:

So it's a bug then ?

The current version of SB 7.42 doesn't ship with a copy of stdint.h.

Not all novices know to steal a copy of stdint.h from gcc avr (or other similar compiler) and use that.

Cheers

Reynard

 

 

Ops!!

Stealing an header file from a different compiler might yield some surprises.

But if you really need to steal one for BoostC, better steal it from XC8 from Microchip.

The target devices are the same for XC8 and BoostC (PIC10/12/16/18) so you won't risk any nasty surprise when using multibyte formats (16/24/32 bits).

 

Anyhow, I would check it in detail, probably there are number of conditionals (#ifdef) based on the default symbols defined by the compiler itself.

If you find any, adjust it for the "BoostC" equivalent symbols.

 

 

Best regards

Jorge

 

Edited February 21, 2018 by JorgeF

[Reynard 0]

Hi Jorge,

Maybe borrow is better.

I did say or other similar compiler.

The MikroC PRO for PIC or ARV stdint.h files are very nice for SourceBoost use.

But if you want to do your own typdedef and use float.h you could try this:

#ifndef _FLOAT_H_
	typedef unsigned char uint8;
#endif

Cheers

Reynard