Code review comment for lp:~cern-kicad/kicad/bugfix_1275319

On Fri, Feb 07, 2014 at 08:00:46PM -0000, Dick Hollenbeck wrote:
> >>> It is not my intention to increase the number of bits in m_VisibleElements - I prefer
> >>> to leave it as it is now, particularly that it is saved as a 32-bit number in
> >>> .kicad_pcb files and I would like to preserve compatibility (so if older versions
> >>> expect 32-bit number there

My 2 eurocents:

1) I agree that it's granted that int is 32 or 64 bits on a PC. IIRC
the standard says that 'int is the most efficient integer for the
machine' (in fact for many RISC machines short or chars are hell on
earth... some DSPs even say that a char is 16 bits: have fun with
sizeof). So that predates even 1995, up to the first 32 bit C compilers with
dos extenders on the 386, circa 1990...

Another (more important IMHO) thing against long is that on the x86_64
ABI it's actually 128 bit which is overkill for most applications. And
needs 8 bytes and multiple precision arithmetic, AFAIK. So it's
not a noise issue for me since I am a typedef lover anyway :D

2) the 'correct' solution would be saving the visibility list as a list,
like the layers. Slightly more than a nuisance (I hope), we just need
someone implementing that.

> >> The lesson here is that "long" is
> >>
> >> a) not necessarily longer than int, and

ISO says so anyway, long is "at least" big as an int (and int is at
least 16 bits, but we can rely on it being at least 32). Unless you want
to port kicad to your favourite 16 bit micro, obviously.

> >> b) not known until you pick a machine and a compiler. So you don't get 64 bitness if
> >> thats what you need.

cmake/autoconf does that. stdint.h does it even better.

--
Lorenzo Marcantonio
Logos Srl