search

iamandi / nanopb

Automatically exported from code.google.com/p/nanopb
zlib License
0 stars 0 forks source link

Change pb_type_t to #define and typedef #57

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Compile nanopb using a Microsoft compiler

What is the expected output? What do you see instead?

I expect clean compilation.  I see this warning:

pb_decode.c(536) : warning C4244: '=' : conversion from 'const int ' to 
'unsigned char ', possible loss of data

Fix is trivial: change line 532 of pb_decode.c from

        uint8_t last_type;

to 

        pb_type_t last_type;

Original issue reported on code.google.com by david.ho...@googlemail.com on 7 Feb 2013 at 12:03

GoogleCodeExporter commented 9 years ago 
Thanks for noticing this before release!

Fix has been committed.

However I'll leave this bug open to remind me to change enum pb_type_t to 
uint8_t typedef in 0.2. This has been suggested a thousand times for various 
reasons, and the only reason to keep it this way has been compatibility and 
"enum looks prettier to me". But I guess the reasons are overwhelming:

1) Some compilers complain about bitwise operations on enums.
2) The enum may be 2 or 4 bytes on compilers other than GCC.
3) gdb (and maybe other debuggers too) decode the values a bit funnily. For 
example PB_LTYPE_VARINT == PB_HTYPE_REQUIRED.

Original comment by Petteri.Aimonen on 7 Feb 2013 at 3:27

GoogleCodeExporter commented 9 years ago 
The switch to #defines has been done by this commit on 0.2:
https://code.google.com/p/nanopb/source/detail?r=ec4a7a0ccef07266cdd3e309e1d3b72
33413142c&name=dev-0.2

Original comment by Petteri.Aimonen on 16 Feb 2013 at 10:15

GoogleCodeExporter commented 9 years ago 
Fix released in nanopb-0.2.0.

Original comment by Petteri.Aimonen on 2 Mar 2013 at 2:39