Assigning values to aggregate error

[__baltazar__]

Hi!
Soemone out there having an explanation about this: (this is a code fragment of the lcd.c )
////...........................
void lcd_send_byte( BYTE address, BYTE n ) {

lcd.rs = 0;
while ( bit_test(lcd_read_byte(),7) ) ;
lcd.rs = address;
delay_cycles(1);
lcd.rw = 0;
delay_cycles(1);
lcd.enable = 0;
lcd_send_nibble(n >> 4);
lcd_send_nibble(n & 0xf);
}
// where lcd is pre defined as
struct lcd_pin_map { // This structure is overlayed
BOOLEAN enable; // on to an I/O port to gain
BOOLEAN rs; // access to the LCD pins.
BOOLEAN rw; // The bits are allocated from
BOOLEAN unused; // low order up. ENABLE will
int data : 4; // be pin B0.
} lcd;
//............................
what is puzzling is that rs is pre defined as 1-bit variable but in the above example, it has been passed a BYTE with compiles with no error. I have been working with SDCC PIC14 Port lately and found out that the same would generate a generic error I have mentioned above.
Any explanation ? Thanks!

[Douglas Kennedy]

The purpose of a compiler is to generate working code for its target processor. Some see compilers as their English teacher who will underline every syntax error based on a purists view of the language. Others love finding fault with their teacher when they miss something.
Almost all versions of C lack perfection. CCS C has it emphasis on supporting a host of Microchip variations on the PIC theme and digresses from a purists view of C sometimes for efficiency, sometimes to accommodate PIC features and sometimes because it just does.
As to your issue, the compiler assumes that the byte has an implied type cast to a bit depending on its true or false value.

[__baltazar__]

Thanks Doug. This gives me the impression that CCS C is really customized to insulate the user from strict C language compliance - a sort of giving the ease of BASIC while keeping itself in the main programming language stream.

[Ttelmah]

Actually, the cast involved here, _is_ standard 'C'...
In part you have to look at the history of 'C', and it's newer derivatives. A lot of people talking about 'C' now, will be automatically thinking 'ANSI C', rather than 'K&R C'.
The classic 'example' of this, is CCS's use of an 8bit integer. In the original K&R books, it was explicitly said that an integer, should be the native type used by the processor (8 bits in the case of the PIC), with examples being given of 8bit, 12bit, and 16bit. Ansi C, instead forces the 'default' to 16bit. This is inefficient, in terms of writing fast code, but efficient, in terms of code portability. CCS, uses the original C form.
Now on the bit conversion, C, is a 'non typed' language. I does not provide any error checking if you allocate values to different types, but instead will attempt to make a 'best fit' at the conversion. K&R, recommended using names that showed the type, to make it easier for the programmer to avoid errors as a result.
More modern variants, in an attempt to avoid these errors, may complain about such conversions.
Now, the original K&R form, is more in keeping with the target of writing reasonably efficient 'control' software, using relatively small programs. Unfortunately, it starts to show 'strain', when used for larger applications. CCS, falls rather 'across the edge' in this, with the newer PICs in particular involving code that may be many thousands of lines long, where better syntax checking, and more intelligent warnings could be a real boon...
Separately, there is another issue with the processor architecture, where on the early chips in particular, the inability to directly access the program memory space, is 'inherent' in the processor, making things lke pointers to constants, basically impossible. Unfortunately, when the slightly latter processors appeared, CCS, has been very slow to adapt to this ability beng possible, and lagged behind the competing products in this regard, for a very long time...
The 'pity' with CCS, is that because of the way that their own functions are hidden inside the compiler, rather than supplied as libraries, you have a language, that at the same time, tries to 'hide' the processor from you, insulating the user from the hardware, and at the same time, forces you to deal with the hardware restrictions, and the bugs that exist in every release. The documentation is poor (in many cases still referring to restrictions that no longer exist)...

Best Wishes