A thought: Over the years I've come across both defaults in various compilers, I wonder if we/you could easily find out what is the common default in the compilers that support the same set of processors as SDCC...maybe that would give a hint on what to do.
Personally I think it is a bug if a code depends on the signed/unsignedness of char as the C standard leaves that open ... then again in 8-bit processors you are always short of space and execution power so you use 'char' and it is easy to write: char i; for (i=99; i>=0; i--) .... and be caught in loop if char is unsigned. br Kusti On 07/10/2014 12:07, "Maarten Brock" <sourceforge.br...@dse.nl> wrote: >> On Mon, Oct 06, 2014 at 09:00:51PM +0200, Philipp Klaus Krause wrote: >>> Currently, in sdcc, char is signed char by default. >>> >>> I would like to change this to unsigned char. >>> >>> The current --funsigned-char would be replaced by a --fsigned char >>> switch to get the non-default behaviour. >>> >>> char being unsigned char by default has advantages: >>> >>> People compare chars. For many architectures, unsigned comparisons are >>> more efficient than unsigned comparisons. >>> >>> People cast chars to ints (many standard functions int arguments for >>> characters). Casts from unsigned char to int are muh more efficient >>>than >>> signed char to int (the latter needs sign extension, the former >>> doesn't). >>> >>> The C standard states that char should be either signed char or >>>unsigned >>> char. >> >> The only concern I have is backward-compability. I mean if someone's >> program relies the default sign char, will this change breaks his code? > >It might. And that is why we're asking here first. We already thought of >this concern and we want to hear from those people that rely on this >current default. There may even be often used libraries that depend on it. >But if we hear nothing of that kind we will continue and do what we think >best. There will always be the fall-back scenario of using the to be >introduced --fsigned-char option. > >Maarten > > >-------------------------------------------------------------------------- >---- >Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clkt >rk >_______________________________________________ >Sdcc-user mailing list >Sdcc-user@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/sdcc-user > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyh...@planmeca.com This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general. ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
