Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#1420 explicit typecast is ineffective for unsigned char parameter

closed-fixed
Borut Ražem
7
2013-05-25
2008-01-18
Laszlo BORTEL
No

The compiler seems to ignore the explicit (unsigned char) typecast when it is applied to the actual parameter of a function with variable arguments. (Explicit (unsigned char) typecast is necessary even for unsigned char type otherwise the compiler would automatically push a two byte integer onto the stack.) The bug for example blocks the use of printf() function with "%bu" format specifier.

C:\>sdcc -v
SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.7.4 #4972 (Nov 23 2007) (MINGW32)

C:\>ver

Microsoft Windows XP [Version 5.1.2600]

Discussion

<< < 1 2 3 > >> (Page 2 of 3)
  • Laszlo BORTEL
    Laszlo BORTEL
    2008-01-21

    Logged In: YES
    user_id=1063737
    Originator: YES

    File Added: BugReport18b.lst

     
  • Laszlo BORTEL
    Laszlo BORTEL
    2008-02-02

     
    Attachments
  • Laszlo BORTEL
    Laszlo BORTEL
    2008-02-02

    Logged In: YES
    user_id=1063737
    Originator: YES

    Hi Borut,

    let me add one more important bit of information to this bug report. In the extended file "BugReport18c.c" it can be seen that explicit (unsigned char) typecast is NOT effective for static variable 'unsigned char d', but effective for static structure member 'unsigned char s.d', which is shocking, because both d and s.d are of the same type, so there sould be no diffrence in their treatment.
    I would expect consistent behaviour in all the cases listed in the 'BugReport18c.c' file: the compiler should apply default argument promotion according to ISO/IEC 9899 UNLESS there is an explicit typecast in the actual parameter list of the function, in which case the explicit typecast should override/supress default argument promotion.
    What I expect is not against the mentioned standard, so I ask you to reconsider your opinion and correct the bug.

    Regards,
    Laszlo
    File Added: BugReport18c.c

     
  • Laszlo BORTEL
    Laszlo BORTEL
    2008-02-02

     
    Attachments
  • Laszlo BORTEL
    Laszlo BORTEL
    2008-02-02

    Logged In: YES
    user_id=1063737
    Originator: YES

    File Added: BugReport18c.lst

     
  • Borut Ražem
    Borut Ražem
    2008-02-03

    Logged In: YES
    user_id=568035
    Originator: NO

    Hi Laszlo,

    my interpretation of the standard is different of yours: I think that explicit casting to unsigned char shouldn't change anything: the argument has still to be promoted to an int, as required by the integer promotion rule, which says that *in the absence of a function prototype*, _Bool, char and short are promoted either to int or unsigned int when used as, or in, function arguments.

    But I agree that there is a bug in SDCC. I think that we need an additional opinions to decide what is right and what is wrong before fixing anything.

    SDCC developers and users: can you help us here?

    My interpretation is as follows:

    --8<---------------

    void printf(char* str, ...) {str;}

    struct {
    unsigned char d;
    } s={0x78};

    unsigned char d=0x89;

    void main (void) {
    unsigned char c=0x56;
    unsigned int u=0x1234;
    //correct: neither explicit typecast, nor automatic promotion
    printf ("%u", u);

    //buggy: explicit typecast shuld not override automatic promotion to integer
    printf ("%bu", (unsigned char)u);

    //correct: automatic promotion to integer is performed
    printf ("%u", c);

    //correct: explicit typecast doesn't override automatic promotion to integer
    printf ("%bu", (unsigned char)c);

    //buggy: explicit typecasts (doesn't matter how many they are) should not override automatic promotion to integer
    printf ("%bu", (unsigned char)(unsigned int)c);

    //correct: automatic promotion to integer is performed on static variable
    printf ("%u", d);

    //correct: explicit typecast doesn't override automatic promotion to integer
    printf ("%bu", (unsigned char)d);

    //correct: automatic promotion to integer is performed
    printf ("%u", s.d);

    //buggy: explicit typecast should not override automatic promotion to integer
    printf ("%bu", (unsigned char)s.d);
    }

    -->8---------------

    Borut

     
  • Borut Ražem
    Borut Ražem
    2008-02-03

    • milestone: 100455 -->
    • status: open-works-for-me --> open
     
  • Borut Ražem
    Borut Ražem
    2008-02-03

    Logged In: YES
    user_id=568035
    Originator: NO

    An other indication that I might be right is:

    "In function calls not in the scope of a function prototype, integer arguments have the integer
    promotions applied and float arguments are widened to double. *It is not possible in such a
    call to pass an unconverted char or float argument.*"

    as stated in Rationale for International Standard — Programming Languages — C, Revision 5.10, April-2003, chapter 6.7.5.3p15.

    The document can be found at:
    http://www.open-std.org/JTC1/SC22/WG14/www/docs/C99RationaleV5.10.pdf

    Borut

     
  • Maarten Brock
    Maarten Brock
    2008-02-03

    Logged In: YES
    user_id=888171
    Originator: NO

    I agree that ellipis parameters should be cast up to int. Mainly because I don't see how to solve this otherwise without losing other optimizations. The price to be paid is unnecessary upcasts when printing char values. This also means that the SDCC specific %b formatter becomes useless (see also regression test snprintf.c) and that the manual must be updated (1.4 Compatibility with previous versions).

     
  • Laszlo BORTEL
    Laszlo BORTEL
    2008-02-04

    Logged In: YES
    user_id=1063737
    Originator: YES

    Hi All,

    I am not familiar with different standards of the C language - so I will not bring you such counter argument. The problem I raised is very practical: I just wanted to use the %b formatter with char argument in the printf() function. Then I realised: sometimes it is possible with explicit typecast, sometimes it is not. My argument to support my interpretation is that it is better to leave control in the hand of the programmer and consistently let him override automatic promotion if he wishes so than deprive him of this possibility and drop this neat feature of byte-sized arguments in print formatting.
    I think it is not easy to decide between my practical and Borut's pragmatic interpretation. One idea: isn't it feasible to introduce a command-line switch for the compiler to select between the two possible consistent behaviours? (--explicit-typecast-overrides-automatic-promotion).

    Regards,
    Laszlo

     
<< < 1 2 3 > >> (Page 2 of 3)