https://en.wikipedia.org/wiki/Complexity_management#Complexity_Hiding
So, most of the point has already been gotten to, but why was it that you
wanted to call something what it was explicitly not?
On Wed, Oct 8, 2014 at 7:43 AM, Philipp Klaus Krause wrote:
> On 07.10.2014 19:47, Erlo Haugen wro
On 07.10.2014 19:47, Erlo Haugen wrote:
> After the change, the compiler will naturally catch assignment of
> negative values to char,
It should give a
warning 158: overflow in implicit constant conversion
but this seems to be partially broken for chars. Currently none of
char z = 255;
signed c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
After the change, the compiler will naturally catch assignment of
negative values to char, check for loop bounds and things like that, right?
Erlo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUNCc0AAoJEDhA0GICupPBcOgH/ReztUaXMU+N+wo
On 07.10.2014 18:09, Richard Gray wrote:
> If I can stick my oar in here... doesn't this make the "unsigned"
> directive a bit redundant? If one expected 'C' to be a signed char as
> in ANSI C, one would use the 'unsigned' directive in the code. There
> is no 'signed' directive as far as I know?
T
On 07.10.2014 11:20, Kustaa Nyholm wrote:
> 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 o
If I can stick my oar in here... doesn't this make the "unsigned"
directive a bit redundant? If one expected 'C' to be a signed char as
in ANSI C, one would use the 'unsigned' directive in the code. There
is no 'signed' directive as far as I know? This would also cause code
that works today to brea
> > 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?
>From a standards perspective the code was already broken. Bu
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 cod
> 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.
>>
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
10 matches
Mail list logo
