Quick and dirty malloc() support for realpath.

[Mike Frysinger]

On Tuesday 27 October 2009 13:46:19 Chris Gray wrote:
> On Tuesday 27 October 2009 08:54:50 Ricard Wanderlof wrote:
> > It can produce more readable, less error-prone C code though. We use
> > hardware register definitions such as
> >
> > typedef struct {
> >    unsigned int x : 8;
> >    unsigned int y : 8;
> >    unsigned int control_bit : 1;
> >    unsigned int dummy1  : 15;
> > } reg_foo;
> >
> > at great length for the C definitions for the registers in our chips, and
> > it really does avoid nasty errors that crop up when using shifting and
> > masking.
> 
> I gave up on bitfields the day I ran something like that through two
>  compilers and one decided that x was "obviously" the high-order byte of
>  the word and the other decided it was "obviously" the low-order one. Oh
>  yes and they made opposite decisions about signedness too, but at least
>  you can control that (as in your example). So now I just write little
>  inlined functions or macros to do the manipulations.

since i dont know the exact issue with the compilers in question (endianness 
maybe ?), i dont think those drawbacks are applicable to Ricard's usage.  
doing bit fields for a specific platform means your code is constrained to 
that platform, so portability isnt a real concern.  we do similar things for 
hardware registers for the same reasons Ricard's cites.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20091028/df73e7af/attachment-0001.pgp>