Re: condition true or false? -> (-1 < sizeof("test"))

Re: condition true or false? -> (-1 < sizeof("test"))

[Nomen Nescio]

Forwarding this to guys who write code in real languages to see what they
think of this. AFAIK you cannot get something like that past the compiler in
Ada...and you would have to define a type or a subtype to even have an
unsigned int unless you use a modular type IIRC. In FORTRAN I don't remember
an unsigned integer but I haven't used it much since FORTRAN IV.

Basically C gives the coder no help in the example you wrote. It doesn't
make sense to do what you did. It's almost surely an error and it should at
least be flagged as a warning. The fact people calling themselves C
programmers can defend any compiler just letting this go by without at least
a warning amd flaming you and calling you an idiot and a noob really says a
lot about their total lack of discipline and explains the pathetic state of
buffer overflows and race conditions, ad naseum, found in C code..

Nomen Nescio <nobody@dizum.com> wrote:

> "BartC" <bc@freeuk.com> wrote:
> 
> > "Eric Sosman" <esosman@ieee-dot-org.invalid> wrote in message
> > news:jp45cv$l0q$1@dont-email.me...
> > > On 5/17/2012 8:05 AM, BartC wrote:
> > 
> > 
> > >> (If not, then it remains the negation of unsigned 1, performed at
> > >> runtime. For this purpose, negating an unsigned value would need to be
> > >> allowed, and I can't see a problem with that, except the usual overflow
> > >> issues).
> > 
> > >     Negation of unsigned 1 (which can be written `-1u') is already
> > > defined in C, although there are implementation-defined aspects.
> > > In particular, there are no "overflow issues," usual or otherwise.
> > 
> > That's true; the value of -3000000000u on my 32-bit C is well-defined;
> > completely wrong, but well-defined according to the Standard.
> > 
> > Actually only lcc-win32, out of my handful of C compilers, bothers to tell
> > me that that expression has an overflow.
> > 
> > >     BartC, your whinings about C and your ideas of how to improve
> > > it would be far more credible if there were evidence that you knew
> > > some C in the first place.  Go, and correct that deficiency, and
> > > you will receive more respectful attention than you now merit.
> > 
> > The 'whinings' were to do with being dependent on compiler options for
> > figuring why programs like this:
> 
> I asked about that before elsewhere, why can't/don't C compilers do a better
> job of pointing out obvious problems, given various lints have been written
> to do just that. It seems so obvious to me that logic should be included in
> a compiler worthy of the name. I was told to go fuck myself. I didn't, but I
> understood I was treading on another UNIX golden calf so..
> 
> > 
> > unsigned int a=4;
> > signed int   b=-2;
> > 
> > printf("%u<%d = %d\n", a, b, a<b);
> > printf("%d<%d = %d\n", 4, b, 4<b);
> > printf("%u<%d = %d\n", a, -2, a<-2);
> > printf("%d<%d = %d\n", 4, -2, 4<-2);
> > 
> > (notice the integer literals, or constants, or whatever you like to call
> > them today, have been correctly displayed as signed values) produce output
> > like this:
> > 
> > 4<-2 = 1
> > 4<-2 = 0
> > 4<-2 = 1
> > 4<-2 = 0
> > 
> > You don't need to know any C, or any language, for it to raise eyebrows. And
> > as it happened, I had trouble getting any of my four compilers to give any
> > warning, until someone told me to try -Wextra on gcc.
> 
> I don't know any C but it did raise my eyebrows. Looking into this a little:
> 
> #include <stdio.h>
> 
> int main() {
>   unsigned int a = 4;
>   signed int b = -2;
> 
>   printf("%u<%d = %d\n", a, b, a<b);
>   printf("%d<%d = %d\n", 4, b, 4<b);
>   printf("%u<%d = %d\n", a, -2, a<-2);
>   printf("%d<%d = %d\n", 4, -2, 4<-2);
> }
> 
> Works like yours:
> 
> /bartc
> 4<-2 = 1
> 4<-2 = 0
> 4<-2 = 1
> 4<-2 = 0
> 
> Agreed, not very helpful. Now let's try:
> 
> Solaris lint, comes with the system:
> 
> lint bartc.c 
> (9) warning: suspicious comparison of unsigned with negative constant: op "<"
> 
> function returns value which is always ignored
>     printf          
> 
> Got one and missed one.
> 
> Even better, this:
> 
> Splint 3.1.2 --- 23 Nov 2011
> 
> bartc.c: (in function main)
> bartc.c:7:32: Operands of < have incompatible types (unsigned int, int): a < b
>   To ignore signs in type comparisons use +ignoresigns
> bartc.c:7:32: Format argument 3 to printf (%d) expects int gets boolean: a < b
>   To make bool and int types equivalent, use +boolint.
>    bartc.c:7:20: Corresponding format code
> bartc.c:8:32: Format argument 3 to printf (%d) expects int gets boolean: 4 < b
>    bartc.c:8:20: Corresponding format code
> bartc.c:9:33: Operands of < have incompatible types (unsigned int, int): a < -2
> bartc.c:9:33: Format argument 3 to printf (%d) expects int gets boolean: a < -2
>    bartc.c:9:20: Corresponding format code
> bartc.c:10:33: Format argument 3 to printf (%d) expects int gets boolean:
>                   4 < -2
>    bartc.c:10:20: Corresponding format code
> bartc.c:11:2: Path with no return in function declared to return int
>   There is a path through a function declared to return a value on which there
>   is no return statement. This means the execution may fall through without
>   returning a meaningful result to the caller. (Use -noret to inhibit warning)
> 
> Finished checking --- 7 code warnings
> 
> Conclusions: C (again) fails the least-surprise test, which is least surprising
> since it is a language that just happened in an environment where there was
> no premium on doing things right but there was a premium on doing them cheap
> and without giving any help to the programmer. Resources were tight and
> small and ok was better than big and good. What's the excuse now, in the
> 21st century? Two thumbs up to splint, btw. Damn fine piece of code.
> 
> Any serious C coder probably should use some form of lint or even better, splint.
> 
> > How much C does someone need to know, to complain about -1 being silently
> > converted to something like 4294967295?
> 
> I saw the problem and it is somewhat obvious (I write assembly code for
> work) but that doesn't mean everybody gets it right all the time in a big
> piece of code. The compiler should be more helpful. And lint should be built
> in to every C compiler. 
> 
> > A lot of my 'whinings' are backed up by people who know the language
> > inside-out. And although nothing  can be done because the Standard is always
> > right, and the language is apparently set in stone, at least discussion
> > about various pitfalls can increase awareness.
> 
> Yes, C sucks, so why use it? I saw pretty quickly discussing any
> shortcomings of UNIX or Linux or C just creates a flamefest, no matter how
> shitty or broken all that stuff is. When you start messing with peoples'
> religion you're going to get your ass kicked. Although it's hard to say
> which is preferable, a trip to the dentist or coding on x86, I guess x86
> assembly is preferably to C. At least there aren't any surprises. Lots of
> disappointment and gasps of horror, but not real surprises.
> 

Re: condition true or false? -> (-1 < sizeof("test"))

[Richard Maine]

Nomen Nescio <nobody@dizum.com> wrote:

> Forwarding this to guys who write code in real languages to see what they
> think of this. AFAIK you cannot get something like that past the compiler in
> Ada...and you would have to define a type or a subtype to even have an
> unsigned int unless you use a modular type IIRC. In FORTRAN I don't remember
> an unsigned integer but I haven't used it much since FORTRAN IV.

Correct on the factual question. Standard Fortran has no unsigned kinds.
Some compilers do such a thing as an extension, but as is the nature of
extensions, one cannot guarantee that all compilers would make the same
choices on the fine points.

I won't comment on the rest. The parts you cited already sounded like a
flame fest, and using a term "real languages" doesn't help much. I won't
participate in any discussion that has already degraded to that point.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

Re: condition true or false? -> (-1 < sizeof("test"))

[Adam Beneschan]

On Monday, May 21, 2012 8:28:44 AM UTC-7, Nomen Nescio wrote:
> Forwarding this to guys who write code in real languages to see what they
> think of this. AFAIK you cannot get something like that past the compiler in
> Ada...and you would have to define a type or a subtype to even have an
> unsigned int unless you use a modular type IIRC.

The last part is pretty much correct.  If you do something like this in Ada:
 
   B := -1 < Some_Type'Size;

where B is a Boolean, it works like this: Some_Type'Size is a universal integer, and it can be converted to any integer type.  However, in a case like this where there's no variable or anything else that tells the language which type to use, the language has a preference for "root_integer", which is a signed integer type.  So the above would do what you expect (i.e. set B to True since 'Size can never be negative).  (The rule about preferring root_integer was added in Ada 95.  I don't know for sure whether the above is legal in Ada 83; I think this might have been an error.)

You could create a situation where -1 is treated as a modular type expression, so that the above would set B to False.  However, you really have to try.  For instance:

    type Word is mod 2**32;

    B := -1 < Word' (Some_Type'Size);

would cause Some_Type'Size to be interpreted as a Word, and then the - and < operators are treated as the ones that operate on Word.  Or:

    One : constant Word := 1;

    B := -One < Some_Type'Size;

But you do have to have some modular type involved to get False for B, and you have to either use the type name in the expression, use the name of an object of that type, or do something like

    B := Thing_Defining_Modular_Type."<" (-1, Some_Type'Size);

It won't happen implicitly.

                           -- Adam

Re: condition true or false? -> (-1 < sizeof("test"))

[Robert A Duff]

Adam Beneschan <adam@irvine.com> writes:

>    B := -1 < Some_Type'Size;
>
> where B is a Boolean, it works like this: Some_Type'Size is a
> universal integer, and it can be converted to any integer type.
> However, in a case like this where there's no variable or anything
> else that tells the language which type to use, the language has a
> preference for "root_integer", which is a signed integer type.  So the
> above would do what you expect (i.e. set B to True since 'Size can
> never be negative).  (The rule about preferring root_integer was added
> in Ada 95.  I don't know for sure whether the above is legal in Ada
> 83; I think this might have been an error.)

There was always a preference rule that made the above legal,
even in Ada 83.  It was changed slightly for Ada 95 to avoid
some obscure Beaujolais effects.  It was also reworded in terms
of root_integer, which didn't exist in Ada 83.

- Bob

Re: condition true or false? -> (-1 < sizeof("test"))

[Terence]

Unsigned integers can be simple signed integers with enough bits to never
exceed the maximum positive number desired. Phylosophically there is no
difference. It's only the precision overflow than can cause a mathemetical
error in simple arithmetic.

Postings like this (not the integer bit, but the surrounding miasma of
complex code) cause me to ask 'WHY'?

Fortran has become more and more complex as the committees approve new
extensions or features and then vendors comply, and then users are 'forced'
to buy a new version or pay for an update if they want continued support.
And finally coding slows down.

It really doesn't have to be this way.

You've all read my discourses on continuing to use F77. I have my reasons,
even if I do also own a Fortran 90/95 compiler

The only negative that I have met (others might not) to my 1983 F77 compiler
is the limitation on contiguous memory space. I don't need any of the
'advances' beyond that version.
All the file formats I could possibly use are there. I can re-express any
modern Fortran code in an equivalent F77 code except for the contigous
memory requirements. (If I have to, I use work files).
I develop (very quickly indeed) in F77. If the client wants a native Windows
version I just recompile with the F95 one.

I don't have problems with a new setup on a newer computer (I'm now on my
gifted Mac Professional using MS Version 7; three earlier machine still work
fine). How many postings are about actually getting a compiler to work?

I have no problems with compiling, linking or even running on pretty much
any of my programs on any machine. How many postings are about how to do
this, or interpret the errors and warnings that a problematic
compiler-linker setup brings?

If I were to teach (again) any students in Fortran, I would still start with
F77. Only later, would I point out what you get with more recent compilers;
the use of modules and intent definitions; the distinction between public
and private data that is useful for OOPs work (strange abbreviation!), the
shortening of code (and reliability) with matrix-formulated operations and
so on, but...

There are some English dialects where every third or forth word is an
automatic obcenity (e.g. Geordie). I prefer the language versions without
the unnecesary stuff. There's more clarity.

Re: condition true or false? -> (-1 < sizeof("test"))

[glen herrmannsfeldt]

In comp.lang.fortran Nomen Nescio <nobody@dizum.com> wrote:
(snip) 
>> > >     Negation of unsigned 1 (which can be written `-1u') is already
>> > > defined in C, although there are implementation-defined aspects.
>> > > In particular, there are no "overflow issues," usual or otherwise.

Note that in C this is applying the unary - operator to the
constant 1u. 

In Fortran, except in rare cases (the DATA statement being one)
constants are not signed. (The implentation may apply the unary
minus operator before generating the in-memory constant.)

I would usually write ~0u instead of -1u, but the result is
the same in both cases. 

In Fortran, one could write NOT(0), with the usual restriction
on the bitwise operators on values with the sign bit set.
(In addition to the fact that Fortran doesn't require a binary
representation for data.)

I don't know how ADA treats signed values, or how its bitwise
operators work. This is still posted to the ADA group, though.

-- glen

Re: condition true or false? -> (-1 < sizeof("test"))

[Nomen Nescio]

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> In comp.lang.fortran Nomen Nescio <nobody@dizum.com> wrote:
> (snip) 
> >> > >     Negation of unsigned 1 (which can be written `-1u') is already
> >> > > defined in C, although there are implementation-defined aspects.
> >> > > In particular, there are no "overflow issues," usual or otherwise.
> 
> Note that in C this is applying the unary - operator to the
> constant 1u. 
> 
> In Fortran, except in rare cases (the DATA statement being one)
> constants are not signed. (The implentation may apply the unary
> minus operator before generating the in-memory constant.)
> 
> I would usually write ~0u instead of -1u, but the result is
> the same in both cases. 
> 
> In Fortran, one could write NOT(0), with the usual restriction
> on the bitwise operators on values with the sign bit set.
> (In addition to the fact that Fortran doesn't require a binary
> representation for data.)
> 
> I don't know how ADA treats signed values, or how its bitwise
> operators work. This is still posted to the ADA group, though.

I'm not an expert on this but Ada is very strongly (statically) typed. There
are only two integer types in Ada to start with, signed integer and modular
integer. The compiler will flag an error if you try to compare variables of
those two types or indeed variables of any differing types. You can define
subtypes of existing types and completely new types and Ada insures you
can't make mistakes by mixing apples and oranges. While this is a bit
confining at times (when you know it's ok to do so) it does preclude the
possibility of something like what Bartc wrote from ever happening. If you
know the conversion is ok there are ways (usually by providing an unchecked
conversion function) to assign or compare across types.

Re: condition true or false? -> (-1 < sizeof("test"))

[Les Neilson]

"Terence" <tbwright@bigpond.net.au> wrote in message 
news:KFBur.7119$v14.5779@viwinnwfe02.internal.bigpond.com...
>
>
> There are some English dialects where every third or forth word is an
> automatic obcenity (e.g. Geordie).
>
On behalf of all the Geordies I know - including myself - I object.
I never heard my parents or grandparents use obscenities. The school friends 
I hung around with did not use obscenities (though admittedly there were 
some others that did!)
I once used the word Hell, and not in a religious context, and got a rather 
disapproving look from my mother.

You and I obviously moved in different circles.
:-)

Les 

Re: condition true or false? -> (-1 < sizeof("test"))

[Martin]

On Tuesday, May 22, 2012 7:11:54 AM UTC+1, Nomen Nescio wrote:
> glen herrmannsfeldt <gah@xxxx.yyyyyyy.zzz> wrote:
> 
[snip]
> 
> I'm not an expert on this but Ada is very strongly (statically) typed.

> There
> are only two integer types in Ada to start with, signed integer and modular
> integer.

This bit isn't right.


> The compiler will flag an error if you try to compare variables of
> those two types or indeed variables of any differing types. You can define
> subtypes of existing types and completely new types and Ada insures you
> can't make mistakes by mixing apples and oranges. While this is a bit
> confining at times (when you know it's ok to do so) it does preclude the
> possibility of something like what Bartc wrote from ever happening.

> If you
> know the conversion is ok there are ways (usually by providing an unchecked
> conversion function) to assign or compare across types.

And this bit isn't quiet right - unchecked conversions are really a technique of last resort!

But apart from that the gist of what you say is - Ada does help prevent silly (and not so silly) mistakes.

Ada typing is easily the richest I know of (see http://en.wikibooks.org/wiki/Ada_Programming/Type_System#The_Type_Hierarchy).

-- Martin

Re: condition true or false? -> (-1 < sizeof("test"))

[BartC]

"Nomen Nescio" <nobody@dizum.com> wrote in message
news:eb42d1e8b4d1e87bc804d05ec6964bc3@dizum.com...
> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

>> I don't know how ADA treats signed values, or how its bitwise
>> operators work. This is still posted to the ADA group, though.
>
> I'm not an expert on this but Ada is very strongly (statically) typed.
> There
> are only two integer types in Ada to start with, signed integer and
> modular
> integer. The compiler will flag an error if you try to compare variables
> of
> those two types or indeed variables of any differing types.

Signed and modular is a better way of explaining how C treats these types,
with a clear distinction between them.

Signed types clearly should be the primary way to represent actual integer
quantities as most of us think of them. A signed integer range can represent
any positive value (given enough bits); an unsigned range can't represent
any positive or  negative value (not with a finite number of bits anyway).

That's why it's odd that when there is any hint of a unsigned operand, C
should switch to modular arithmetic for both.

But, given that C works at a lower level, and the choice of bit-widths is
limited, then perhaps there ought to be 3 integer types:

- Signed
- New-unsigned
- Modular

With the new-unsigned type behaving as I have suggested a few times [in the
original thread in comp.lang.c], just a subrange of a signed type (for
example, a hypothetical signed integer type that is one bit wider).

With the new-unsigned type, a negation operation must have signed result
(because, other than -0, it will be negative). While subtraction would need
to be signed too, as results can be negative. And of course there is the 
likelihood of overflow or underflow, for which I will leave to other 
language proposals to deal with..

-- 
Bartc 

Re: condition true or false? -> (-1 < sizeof("test"))

[Georg Bauhaus]

On 22.05.12 03:45, glen herrmannsfeldt wrote:

> I don't know how ADA treats signed values, or how its bitwise
> operators work. This is still posted to the ADA group, though.

A feature of Ada (a lady's first name; some older book's
have capitals in titles) is that you would not normally have
to worry; you still can if you like, or must.

First, one cannot store signed (unsigned) values in places whose
type is unsigned (signed) unless using force such as explicit
type conversion, or Unchecked_Conversion. Different types,
no implicit conversions, as mentioned in the thread.

As needed, one selects from the three kinds of types that
have logical operations, Boolean, modular, and packed array
of Boolean.

Some redundant assertions in the following.

with Interfaces;   -- for unsigned modular "hardware" types
with Ada.Unchecked_Conversion;
procedure Bops is

    -- modular types with modular arithmetic and Boolean ops:

    type U8 is mod 2**8;

    pragma Assert (U8'Pred (0) = -1);
    pragma Assert (U8'Succ (U8'Last) = 0);

    X8 : U8 := 2#1111_1111#;
    --X9 : U8 := 2#1111_1111_1#;  -- compiler rejects, value not in range
    X1 : U8 := -1;                       --  modular arithmetic
    X0 : U8 := not 0;                    --  has Boolean ops

    pragma Assert (X0 = X1);
    pragma Assert (X1 = 2#1111_1111#);

    -- convert from signed:

    type S8 is range -128 .. 127;
    for S8'Size use 8;

    function To_U8 is new Ada.Unchecked_Conversion (S8, U8);
    I8 : S8 := -1;          -- a negative signed value
    --XI : U8 := U8 (I8);   -- type conv will raise! value out of range
    XU : U8 := To_U8 (I8);   -- o.K., not checked

    pragma Assert (XU = 8#377#);

    -- unsinged_N "hardware types" when supported by the compiler;
    -- includes shifting operations and such, is modular

    use type Interfaces.Unsigned_64;     -- import "+" for literals
    U64 : Interfaces.Unsigned_64 := 16#FFFF_FFFF_FFFF_0000# + 2#101#;


    -- types for convenient access to individual bits

    type Bitvec is array (Natural range <>) of Boolean;
    pragma Pack (Bitvec);                --  guaranteed
    subtype Bitvec_8 is Bitvec (0 .. 7);

    Y : Bitvec (0 .. 11) := (5 => True, others => False);

    pragma Assert (Y(5) and not Y(11));

    Z : Bitvec_8;
    Toggle : constant Bitvec_8 := (others => True);
begin
    Y (11) := True;
    Z := Y(8 - 6 + 1 .. 8) & Y(10 .. 11) xor Toggle;
    pragma Assert (Z = (True, True, False, True,
                        True, True, True, False));
end Bops;


-- Georg

Re: condition true or false? -> (-1 < sizeof("test"))

[Dmitry A. Kazakov]

On Tue, 22 May 2012 10:55:01 +0100, BartC wrote:

> With the new-unsigned type behaving as I have suggested a few times [in the
> original thread in comp.lang.c], just a subrange of a signed type (for
> example, a hypothetical signed integer type that is one bit wider).
> 
> With the new-unsigned type, a negation operation must have signed result
> (because, other than -0, it will be negative). While subtraction would need
> to be signed too, as results can be negative. And of course there is the 
> likelihood of overflow or underflow, for which I will leave to other 
> language proposals to deal with..

Integer arithmetic is more than just + and -. Did you ask yourself what is
the motivation to have it one bit wider? The answer is to have + and -
closed. What about *? That would make it x2 bits wider. What about
exponentiation? Much more bits. Factorial?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: condition true or false? -> (-1 < sizeof("test"))

[Fritz Wuehler]

Thanks Terence. What you say goes against the neverending drive by most
technology people to constantly change things that are mostly fine, and to
think new is and old is. I agree with your sentiments. 

> I prefer the language versions without the unnecesary stuff. There's more
> clarity. 

Sadly, I find most of modern Fortran unreadable whereas I found FORTRAN (at
the time) perfectly readable.

Re: condition true or false? -> (-1 < sizeof("test"))

[BartC]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:15puwddz4h6cl$.34i9lxveafeb.dlg@40tude.net...
> On Tue, 22 May 2012 10:55:01 +0100, BartC wrote:
>
>> With the new-unsigned type behaving as I have suggested a few times [in 
>> the
>> original thread in comp.lang.c], just a subrange of a signed type (for
>> example, a hypothetical signed integer type that is one bit wider).
>>
>> With the new-unsigned type, a negation operation must have signed result
>> (because, other than -0, it will be negative). While subtraction would 
>> need
>> to be signed too, as results can be negative. And of course there is the
>> likelihood of overflow or underflow, for which I will leave to other
>> language proposals to deal with..
>
> Integer arithmetic is more than just + and -. Did you ask yourself what is
> the motivation to have it one bit wider?

Yes. So that given 32 bits for example, we can count to approximately 4 
billion instead of 2 billion.

> The answer is to have + and -
> closed. What about *? That would make it x2 bits wider. What about
> exponentiation? Much more bits. Factorial?

We're talking about C where operations and their results usually have the 
same predefined width. If it was necessary to worry about worst-cases on 
every operation, that would make programming at this level pretty much 
impossible.

Instead, that sort of auto-ranging, multi-precision utility is left to 
higher-level languages, and languages such as C are used to implement  them.

For that purpose, full-width unsigned arithmetic, preferably with carry 
status, as available in most processors, is extremely useful.

-- 
Bartc

 

Re: condition true or false? -> (-1 < sizeof("test"))

[Dmitry A. Kazakov]

On Tue, 22 May 2012 17:25:17 +0100, BartC wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:15puwddz4h6cl$.34i9lxveafeb.dlg@40tude.net...
>> On Tue, 22 May 2012 10:55:01 +0100, BartC wrote:
>>
>>> With the new-unsigned type behaving as I have suggested a few times [in the
>>> original thread in comp.lang.c], just a subrange of a signed type (for
>>> example, a hypothetical signed integer type that is one bit wider).
>>>
>>> With the new-unsigned type, a negation operation must have signed result
>>> (because, other than -0, it will be negative). While subtraction would need
>>> to be signed too, as results can be negative. And of course there is the
>>> likelihood of overflow or underflow, for which I will leave to other
>>> language proposals to deal with..
>>
>> Integer arithmetic is more than just + and -. Did you ask yourself what is
>> the motivation to have it one bit wider?
> 
> Yes. So that given 32 bits for example, we can count to approximately 4 
> billion instead of 2 billion.
> 
>> The answer is to have + and -
>> closed. What about *? That would make it x2 bits wider. What about
>> exponentiation? Much more bits. Factorial?
> 
> We're talking about C where operations and their results usually have the 
> same predefined width.

Irrelevant. The concept either works or does not. In this case it does not.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: condition true or false? -> (-1 < sizeof("test"))

[BartC]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:3b5cewxtwayd.x41gqd4lwwm9.dlg@40tude.net...
> On Tue, 22 May 2012 17:25:17 +0100, BartC wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message

>>> The answer is to have + and -
>>> closed. What about *? That would make it x2 bits wider. What about
>>> exponentiation? Much more bits. Factorial?
>>
>> We're talking about C where operations and their results usually have the
>> same predefined width.
>
> Irrelevant. The concept either works or does not. In this case it does 
> not.

That's fine. But in that case, every calculator or computer ever made is 
useless, because you can always think up some calculation just beyond it's 
capacity.

-- 
Bartc 

Re: condition true or false? -> (-1 < sizeof("test"))

[Fritz Wuehler]

"BartC" <bc@freeuk.com> wrote:

> "Nomen Nescio" <nobody@dizum.com> wrote in message
> news:eb42d1e8b4d1e87bc804d05ec6964bc3@dizum.com...
> > glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> 
> >> I don't know how ADA treats signed values, or how its bitwise
> >> operators work. This is still posted to the ADA group, though.
> >
> > I'm not an expert on this but Ada is very strongly (statically) typed.
> > There
> > are only two integer types in Ada to start with, signed integer and
> > modular
> > integer. The compiler will flag an error if you try to compare variables
> > of
> > those two types or indeed variables of any differing types.
> 
> Signed and modular is a better way of explaining how C treats these types,
> with a clear distinction between them.

That's only partially true from an Ada perspective. For one thing, Ada
allows you to specify a range for modular types (and for integer types as
well) so you (and the compiler) actually know what modulo you are using. In
C, if you assign a negative or invalid value to an unsigned int I believe
the result you get depends on the C implementation and execution platform.
In Ada, the result should be consistent across all implementations and
platforms.

> Signed types clearly should be the primary way to represent actual integer
> quantities as most of us think of them. A signed integer range can represent
> any positive value (given enough bits); an unsigned range can't represent
> any positive or  negative value (not with a finite number of bits anyway).

I don't agree with this because in many practical cases unsigned integers
are more meaningful (counters, for example) and also extend the useful range
of machines with small word sizes. If really depends on your application.

> That's why it's odd that when there is any hint of a unsigned operand, C
> should switch to modular arithmetic for both.

I agree. It's the opposite of what you would expect. It seems to me unsigned
integers should probably be promoted to signed integer to be the most useful
but of course you will also need some way to handle overflows.

> With the new-unsigned type, a negation operation must have signed result
> (because, other than -0, it will be negative). While subtraction would need
> to be signed too, as results can be negative. And of course there is the 
> likelihood of overflow or underflow, for which I will leave to other 
> language proposals to deal with..

Re: condition true or false? -> (-1 < sizeof("test"))

[Dmitry A. Kazakov]

On Tue, 22 May 2012 18:26:58 +0100, BartC wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:3b5cewxtwayd.x41gqd4lwwm9.dlg@40tude.net...
>> On Tue, 22 May 2012 17:25:17 +0100, BartC wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> 
>>>> The answer is to have + and -
>>>> closed. What about *? That would make it x2 bits wider. What about
>>>> exponentiation? Much more bits. Factorial?
>>>
>>> We're talking about C where operations and their results usually have the
>>> same predefined width.
>>
>> Irrelevant. The concept either works or does not. In this case it does 
>> not.
> 
> That's fine. But in that case, every calculator or computer ever made is 
> useless, because you can always think up some calculation just beyond it's 
> capacity.

But calculators do not work with non-modular unsigned integers.

The idea of having a constrained subtype of a constrained or not integer
type is all OK. This is how such types are defined in Ada:

   subtype Natural is new Integer range 0..Integer'Last;

Wrong is an attempt to define a new type pretending it were unconstrained
because some extra bits.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: condition true or false? -> (-1 < sizeof("test"))

[Terence]

Les:
 See UK TV program "Geordy shore". I'm a northerner myself. The post-1945
period brought back voluble armed forces personnel and I first saw these
obsenities enter the spoken language (especially in the military area; I
also met this as a cadet sargeant, 1948-53). It's there; I'm ashamed for
usage on international programs fo rthe impresion it gives.

Re: condition true or false? -> (-1 < sizeof("test"))

[Les Neilson]

"Terence" <tbwright@bigpond.net.au> wrote in message 
news:z9Vur.7164$v14.1468@viwinnwfe02.internal.bigpond.com...
> Les:
> See UK TV program "Geordy shore". I'm a northerner myself. The post-1945
> period brought back voluble armed forces personnel and I first saw these
> obsenities enter the spoken language (especially in the military area; I
> also met this as a cadet sargeant, 1948-53). It's there; I'm ashamed for
> usage on international programs fo rthe impresion it gives.
>
You are probably right.
I have never watched "Geordy shore" (I'm not a fan of so-called "reality 
tv"). I guess I'm the one who has led a sheltered life :-)
Les 

Re: condition true or false? -> (-1 < sizeof("test"))

[Terence]

Funny; I remember the time when a "calculator' meant a person who calculated
for a living.
The clockwork machine he/she might very well use only understand a negative
input as rotation of the crank one way, and positive as going the other
over-the-top way.
Would you believe I did a postgraduate degree in how, precisely, to use one
of those hand-crank things properly, when studying Numerical Analysis? Yes,
we had electricity of a sort (D.C.at 240 volt; no coil-based transformers -
I had a minature train 00 layout with a dynamo-generator to get 240v down to
12v DC), but see R.Feynman on his opinion of the use of powered omputing
devices at Los Alamos.
It was very much later I met my first American Marchant machine (after we we
got A.C. power).
How could the electical power engineers guess wrong ?(like Edison did in the
USA actually).

Re: condition true or false? -> (-1 < sizeof("test"))

[robin.vowels]

On Tuesday, 22 May 2012 01:28:44 UTC+10, Nomen Nescio  wrote:
> Forwarding this to guys who write code in real languages to see what they
> think of this. AFAIK you cannot get something like that past the compiler in
> Ada...and you would have to define a type or a subtype to even have an
> unsigned int unless you use a modular type IIRC. In FORTRAN I don't remember
> an unsigned integer but I haven't used it much since FORTRAN IV.

> Basically C gives the coder no help in the example you wrote. It doesn't
> make sense to do what you did. It's almost surely an error and it should at
> least be flagged as a warning. The fact people calling themselves C
> programmers can defend any compiler just letting this go by without at least
> a warning amd flaming you and calling you an idiot and a noob really says a
> lot about their total lack of discipline and explains the pathetic state of
> buffer overflows and race conditions, ad naseum, found in C code..

> Nomen Nescio <nob...@dizum.com> wrote:

> > "BartC" <....@freeuk.com> wrote:
> > I don't know any C but it did raise my eyebrows. Looking into this a little:

> > #include <stdio.h>

> > int main() {
> >   unsigned int a = 4;
> >   signed int b = -2;

> >   printf("%u<%d = %d\n", a, b, a<b);
> >   printf("%d<%d = %d\n", 4, b, 4<b);
> >   printf("%u<%d = %d\n", a, -2, a<-2);
> >   printf("%d<%d = %d\n", 4, -2, 4<-2);
> > }

> > Works like yours:

> > /bartc
> > 4<-2 = 1
> > 4<-2 = 0
> > 4<-2 = 1
> > 4<-2 = 0

In PL/I:--

comparisons: procedure options (main);

   declare u unsigned fixed binary (31) initial ( 4),
           s          fixed binary (31) initial (-2);

   put skip list (u, s);
   put skip list ( u < s, u <= s, u > s, u >= s);

end comparisons;

Results:
             4                      -2
'0'B                    '0'B                    '1'B                    '1'B