From: Terje Mathisen "terje.mathisen at on
Andy 'Krazy' Glew wrote:
> On 6/26/2010 12:55 PM, Terje Mathisen wrote:
>> Anton Ertl wrote:
>>> But of course, all of this is outside the standardized subset of C.
>>
>> In my not so humble opinion, this is simply broken.
>
> What is broken? The code snippets, or the fact that this is outside the
> standard subset of C?

The latter: Currently the C standard is more or less useless for signed
variables. :-(

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
From: Terje Mathisen "terje.mathisen at on
MitchAlsup wrote:
> On Jun 26, 9:07 pm, Andy 'Krazy' Glew<ag-n...(a)patten-glew.net> wrote:
>> int
>> read(int d, char *buf, int nbytes)
>> DESCRIPTION
>>
>> Read() attempts to read nbytes of data from the object referenced by the file descriptor d into the buffer pointed to by
>> buf.
>>
>> RETURN VALUES
>>
>> If successful, the number of bytes actually read is returned. Upon reading end-of-file, zero is returned. Otherwise, a
>> -1 is returned and the global variable errno is set to indicate the error..- Hide quoted text -
>
> Clearly this is a case where an int is required by the library
> definition and similar definitions hold for argc,...
> My argument is not directed towards these, but after the code checks
> for error conditions (negative values), many times you will be better
> off assigning the now known to be positive value to an unsigned for
> future use.
> So the use code might look something like:
>
> { signed long int readc;
> unsigned long int index;
> readc = read(infile, inbuf, InBufMAX);
> if( readc>=0 )
> {
> for( index=0; index< readc; index++)
> // readc is known to be non-negative

Ouch!

I hope I never do it that way, I much prefer to do a single conversion
(copy/typecast/whatever) as soon as I know that the value is positive,
instead of having mixed-mode arithmetic in the loop control. :-)

> ....inbuf[index]....
> }
> }

Otherwise I agree completely.

I have a feeling that those who are used to thinking about computing as
a series of operations on bits are much more likely to prefer unsigned,
at least in C, just to get away from the standard madness which is C
signed. :-)

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
From: Chris Gray on
Andy 'Krazy' Glew <ag-news(a)patten-glew.net> writes:

> Note that the code you descrbe does NOT simply work with unsigneds in C, whereas it works with signed.
>
> I.e. you cannot simply say
>
> unsigned response_count;
> response_count++;
> assert( response_count > 0 );

The pattern we used is:

responsesLeft := <count_of_nodes>;

responseArrives:
ASSERT(responsesLeft != 0);
responsesLeft -= 1;

> Agreed. It wouyld be nice to have the system tell you are trying to make an unsigned number negative.

> Note, however, that the C standard defines this, saying that it is
> modulo arithmetic. Or maybe they only define modulo for positive
> numbers. Somebody'll tell me. In any case, C does not give you an
> error if you try to make an unsigned negative, except in the simplest
> cases.

Right, so this has to be done in a variant of C, or some other language.

> In general, specifying ranges for integers is a good idea. Remember

> var a 32..63 ?

I don't remember that syntax from anywhere. However, I had ranges in my
"Draco" language. I found they were not very useful and only ever used
them in one program, and they were clumsy there. Perhaps I was misusing
them, but what I found was that I needed to break out of the range far
too often.

--
Chris Gray cg(a)GraySage.COM
From: =?ISO-8859-1?Q?Niels_J=F8rgen_Kruse?= on
Andy 'Krazy' Glew <ag-news(a)patten-glew.net> wrote:

> On 6/27/2010 9:51 AM, Robert Myers wrote:
> > Terje Mathisen wrote:
> >> Anton Ertl wrote:
> >
> >>
> >>> But of course, all of this is outside the standardized subset of C.
> >>
> >> In my not so humble opinion, this is simply broken.
> >>
> >
> > What this thread has demonstrated to me, yet again, is what a fatally
> > flawed enterprise c is, and yet, I know that, without c or something
> > like it, we would never have anything like Linux.
>
> I think that C was less flawed before the standardization process got a
> hold of it. In this aspect, at least.

I think it is more a problem of some compiler writers choosing to
eliminate the difference between implementation defined and undefined.

Nothing other than common sense prevented something similar before the C
standard.

--
Mvh./Regards, Niels J�rgen Kruse, Vanl�se, Denmark
From: Jean-Marc Bourguet on
nospam(a)ab-katrinedal.dk (Niels J�rgen Kruse) writes:

> Andy 'Krazy' Glew <ag-news(a)patten-glew.net> wrote:
>
> > On 6/27/2010 9:51 AM, Robert Myers wrote:
> > > Terje Mathisen wrote:
> > >> Anton Ertl wrote:
> > >
> > >>
> > >>> But of course, all of this is outside the standardized subset of C.
> > >>
> > >> In my not so humble opinion, this is simply broken.
> > >>
> > >
> > > What this thread has demonstrated to me, yet again, is what a fatally
> > > flawed enterprise c is, and yet, I know that, without c or something
> > > like it, we would never have anything like Linux.
> >
> > I think that C was less flawed before the standardization process got a
> > hold of it. In this aspect, at least.
>
> I think it is more a problem of some compiler writers choosing to
> eliminate the difference between implementation defined and undefined.

Overflow for signed computation is undefined behavior, not implementation
defined; it's even the exemple of undefined behavior given in the section
defining "undefined behavior".

> Nothing other than common sense prevented something similar before the C
> standard.

Common sense: nobody thinks lacking it, everybody think other are missing
some.

I think this is a case of different people wanting different things for C.
The end result in gcc (options -fwrapv/-ftrapv allowing to ask for wrap
around/trapping instead of letting it uses all the lattitude open by the
standard) would be good if only -ftrapv worked reliably... It is more
difficult to test if -fwrapv work -- on the one hand it is probably more
tested than -ftrapv (it is implicit for Java according to the
documentation), on the other hand the fact that -ftrapv doesn't isn't a
confidence builder.

Is there other compilers allowing to control this? Or at least documenting
that they are using one or the other choice?

Yours,

--
Jean-Marc