Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #96811 > unrolled thread

C++ forcing unnecessary changes to C?

Back to article view | Back to comp.lang.c

Contents

  C++ forcing unnecessary changes to C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 20:34 +0800
    Re: C++ forcing unnecessary changes to C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-18 05:09 -0800
      Re: C++ forcing unnecessary changes to C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 21:42 +0800
        Re: C++ forcing unnecessary changes to C? jameskuyper@verizon.net - 2016-11-18 11:14 -0800
      Re: C++ forcing unnecessary changes to C? jameskuyper@verizon.net - 2016-11-18 11:10 -0800
        Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-19 15:26 +0100
          Re: C++ forcing unnecessary changes to C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-19 10:09 -0500
            Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-20 13:47 +0100
        Re: C++ forcing unnecessary changes to C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-21 03:25 -0800
          Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-21 14:15 +0100
            Re: C++ forcing unnecessary changes to C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-21 05:39 -0800
    Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 14:26 +0100
      Re: C++ forcing unnecessary changes to C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 21:41 +0800
        Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 15:20 +0100
          Re: conduct in comp.lang.c "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 22:23 +0800
    Re: C++ forcing unnecessary changes to C? Philipp Klaus Krause <pkk@spth.de> - 2016-11-18 15:16 +0100
      Re: C++ forcing unnecessary changes to C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 22:20 +0800
        Re: C++ forcing unnecessary changes to C? jameskuyper@verizon.net - 2016-11-18 11:18 -0800
      Re: C++ forcing unnecessary changes to C? supercat@casperkitty.com - 2016-11-18 07:15 -0800
        Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 16:55 +0100
          Re: C++ forcing unnecessary changes to C? supercat@casperkitty.com - 2016-11-18 08:31 -0800
            Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 17:38 +0100
    Re: C++ forcing unnecessary changes to C? John Bode <jfbode1029@gmail.com> - 2016-11-18 07:09 -0800
      Re: C++ forcing unnecessary changes to C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-18 07:22 -0800
        Re: C++ forcing unnecessary changes to C? Thiago Adams <thiago.adams@gmail.com> - 2016-11-18 07:31 -0800
          Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 17:04 +0100
    Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 16:37 +0100
      Re: C++ forcing unnecessary changes to C? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 23:53 +0800
      Re: C++ forcing unnecessary changes to C? supercat@casperkitty.com - 2016-11-18 08:00 -0800
        Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 17:34 +0100
        Re: C++ forcing unnecessary changes to C? Keith Thompson <kst-u@mib.org> - 2016-11-18 09:32 -0800
      Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-18 17:09 +0100
        Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-18 18:02 +0100
          Re: C++ forcing unnecessary changes to C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-21 03:26 -0600
            Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 11:11 +0100
              Re: C++ forcing unnecessary changes to C? jameskuyper@verizon.net - 2016-11-22 08:55 -0800
              Re: C++ forcing unnecessary changes to C? Robert Wessel <robertwessel2@yahoo.com> - 2016-11-25 03:25 -0600
                Re: C++ forcing unnecessary changes to C? supercat@casperkitty.com - 2016-11-25 10:00 -0800
                Re: C++ forcing unnecessary changes to C? Keith Thompson <kst-u@mib.org> - 2016-11-25 12:30 -0800
                  Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-26 00:38 +0100
                    Re: C++ forcing unnecessary changes to C? supercat@casperkitty.com - 2016-11-26 10:44 -0800
                      Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-26 20:44 +0100
                        Re: C++ forcing unnecessary changes to C? supercat@casperkitty.com - 2016-11-26 12:38 -0800
                      Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-26 21:00 +0100
    Re: C++ forcing unnecessary changes to C? jameskuyper@verizon.net - 2016-11-18 11:04 -0800
      Re: [OT] discipline and obedience "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-19 22:53 +0800
      Re: C & C++ Committee "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-19 22:55 +0800
        Re: C & C++ Committee jameskuyper@verizon.net - 2016-11-19 08:02 -0800
          Re: C & C++ Committee "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-20 00:09 +0800
            Re: C & C++ Committee jameskuyper@verizon.net - 2016-11-19 08:35 -0800
              Re: C & C++ Committee fir <profesor.fir@gmail.com> - 2016-11-19 08:51 -0800
                Re: Do you write C programs? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-20 01:00 +0800
              Re: C & C++ Committee "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-20 00:59 +0800
    Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 11:14 +0100
      Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-22 12:05 +0100
        Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 14:51 +0100
          Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-22 15:50 +0100
            Re: C++ forcing unnecessary changes to C? BartC <bc@freeuk.com> - 2016-11-22 15:01 +0000
              Re: C++ forcing unnecessary changes to C? Keith Thompson <kst-u@mib.org> - 2016-11-22 08:58 -0800
                Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 18:08 +0100
                Re: C++ forcing unnecessary changes to C? BartC <bc@freeuk.com> - 2016-11-22 18:14 +0000
                  Re: C++ forcing unnecessary changes to C? Ian Collins <ian-news@hotmail.com> - 2016-11-23 08:33 +1300
                    Re: C++ forcing unnecessary changes to C? BartC <bc@freeuk.com> - 2016-11-22 19:42 +0000
                      Re: C++ forcing unnecessary changes to C? Ian Collins <ian-news@hotmail.com> - 2016-11-23 08:51 +1300
                      Re: C++ forcing unnecessary changes to C? Keith Thompson <kst-u@mib.org> - 2016-11-22 12:13 -0800
                        Re: C++ forcing unnecessary changes to C? BartC <bc@freeuk.com> - 2016-11-22 21:35 +0000
                          Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-23 00:47 +0100
                    Re: C++ forcing unnecessary changes to C? Keith Thompson <kst-u@mib.org> - 2016-11-22 12:09 -0800
                  Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-23 00:40 +0100
                    Re: C++ forcing unnecessary changes to C? jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-26 01:27 +0100
                      Re: C++ forcing unnecessary changes to C? David Brown <david.brown@hesbynett.no> - 2016-11-26 01:48 +0100
                Re: C++ forcing unnecessary changes to C? Nathan Wagner <nw@hydaspes.if.org> - 2016-11-24 18:09 +0000

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#96859

On Friday, November 18, 2016 at 9:55:32 AM UTC-6, David Brown wrote:
> There was no "idiomatic way" to write rotate operations, because rotate
> operations are not common enough to warrant idioms.

Some compilers included and documented code to recognize the specific pattern
I gave; rotates are rare in some applications fields, but come up a lot more
in others (e.g. hashing, cryptography, and in some cases bitmap graphics).

> A compiler may or may not defined the behaviour of shifts outside the
> ranges given in the standard.  Someone needing a shift in their code may
> write correct portable code, or correct implementation-dependent code,
> or code that just happens to work without any guarantees.  I think it is
> this later choice that you think of as "idiomatic", and believe that
> because someone might have written this, compilers should be obliged to
> implement it.

When the Standard was written, there were implementations which would
behave badly if given a vastly-oversized shift amount.  In one case I
recall a processor would iterate up to four billion single-bit shift
operations with interrupts disabled; disabling interrupts for that long
would often cause other system problems.  So it made sense to recognize
that shifting by at least some oversize values could have bad consequences.

Further, there were two different ways that processors treated shifts that
were exactly equal to the word size, and in some cases it would have been
expensive for implementations to do one or the other consistently.  On the
other hand, some coding patterns will work equally well when handled either
way.

It would have been rather awkward for the authors of the Standard to say
that shifts smaller than wordsize yield an exact value, those between
wordsize and wordsize*2-1 may either yield an iterative shift by the
specified amount, or by (amount-wordsize), and other values yield UB,
and there was no reason to expect that implementations would do anything
different given that instruction, than if simply told they can do anything
they see for for all values wordsize and up.

I'd be curious to know what modern-hardware implementation first treated an
exact shift by word size in a fashion other than one of the above, in cases
where it wasn't asked to do a sanitizing build.

[toc] | [prev] | [next] | [standalone]

#96862

On 18/11/16 17:31, supercat@casperkitty.com wrote:
> On Friday, November 18, 2016 at 9:55:32 AM UTC-6, David Brown wrote:
>> There was no "idiomatic way" to write rotate operations, because rotate
>> operations are not common enough to warrant idioms.
> 
> Some compilers included and documented code to recognize the specific pattern
> I gave;

Then you have implementation-specific behaviour, and can be happy with that.

> rotates are rare in some applications fields, but come up a lot more
> in others (e.g. hashing, cryptography, and in some cases bitmap graphics).
> 
>> A compiler may or may not defined the behaviour of shifts outside the
>> ranges given in the standard.  Someone needing a shift in their code may
>> write correct portable code, or correct implementation-dependent code,
>> or code that just happens to work without any guarantees.  I think it is
>> this later choice that you think of as "idiomatic", and believe that
>> because someone might have written this, compilers should be obliged to
>> implement it.
> 
> When the Standard was written, there were implementations which would
> behave badly if given a vastly-oversized shift amount.  In one case I
> recall a processor would iterate up to four billion single-bit shift
> operations with interrupts disabled; disabling interrupts for that long
> would often cause other system problems.  So it made sense to recognize
> that shifting by at least some oversize values could have bad consequences.

There may still be such implementations.

> 
> Further, there were two different ways that processors treated shifts that
> were exactly equal to the word size, and in some cases it would have been
> expensive for implementations to do one or the other consistently.  On the
> other hand, some coding patterns will work equally well when handled either
> way.

That is why this was all made undefined behaviour.  And as always,
implementations are free to give it known behaviour if the compiler
developers think it will be useful.

> 
> It would have been rather awkward for the authors of the Standard to say
> that shifts smaller than wordsize yield an exact value, those between
> wordsize and wordsize*2-1 may either yield an iterative shift by the
> specified amount, or by (amount-wordsize), and other values yield UB,
> and there was no reason to expect that implementations would do anything
> different given that instruction, than if simply told they can do anything
> they see for for all values wordsize and up.
> 
> I'd be curious to know what modern-hardware implementation first treated an
> exact shift by word size in a fashion other than one of the above, in cases
> where it wasn't asked to do a sanitizing build.
> 

[toc] | [prev] | [next] | [standalone]

#96839

On Friday, November 18, 2016 at 6:34:12 AM UTC-6, Mr. Man-wai Chang wrote:
> IS it a stupid comment?

Is what a stupid comment?

C++ *has* influenced the development of C in the past, most notably the
adoption of function prototype syntax in C89.  I can't say any other C++
features will never be adopted, but I strongly doubt it.  

[toc] | [prev] | [next] | [standalone]

#96842

On Friday, November 18, 2016 at 1:09:37 PM UTC-2, John Bode wrote:
> On Friday, November 18, 2016 at 6:34:12 AM UTC-6, Mr. Man-wai Chang wrote:
> > IS it a stupid comment?
> 
> Is what a stupid comment?
> 
> C++ *has* influenced the development of C in the past, most notably the
> adoption of function prototype syntax in C89.  I can't say any other C++
> features will never be adopted, but I strongly doubt it.

I can say two more cases:
 - const
 - atomic, thread C++11 ( C11 influence)

(I agree with David Brown and I think he did valuable comments about how to communicate with other people)

[toc] | [prev] | [next] | [standalone]

#96844

On Friday, November 18, 2016 at 1:22:23 PM UTC-2, Thiago Adams wrote:
> On Friday, November 18, 2016 at 1:09:37 PM UTC-2, John Bode wrote:
> > On Friday, November 18, 2016 at 6:34:12 AM UTC-6, Mr. Man-wai Chang wrote:
> > > IS it a stupid comment?
> > 
> > Is what a stupid comment?
> > 
> > C++ *has* influenced the development of C in the past, most notably the
> > adoption of function prototype syntax in C89.  I can't say any other C++
> > features will never be adopted, but I strongly doubt it.
> 
> I can say two more cases:
>  - const
>  - atomic, thread C++11 ( C11 influence)
> 

- I think _Bool was influenced by C++

I can't find a good place to find the differences and incompatibilities between C 11 and  C++ 17. 

I had recent problems with named initializer

x.pt = (Point) {.x = 1, .y =2};

or 

x.pt = (Point) { 1, 2};

http://stackoverflow.com/questions/18731707/why-does-c11-not-support-designated-initializer-list-as-c99

[toc] | [prev] | [next] | [standalone]

#96857

On 18/11/16 16:31, Thiago Adams wrote:
> On Friday, November 18, 2016 at 1:22:23 PM UTC-2, Thiago Adams wrote:
>> On Friday, November 18, 2016 at 1:09:37 PM UTC-2, John Bode wrote:
>>> On Friday, November 18, 2016 at 6:34:12 AM UTC-6, Mr. Man-wai Chang wrote:
>>>> IS it a stupid comment?
>>>
>>> Is what a stupid comment?
>>>
>>> C++ *has* influenced the development of C in the past, most notably the
>>> adoption of function prototype syntax in C89.  I can't say any other C++
>>> features will never be adopted, but I strongly doubt it.
>>
>> I can say two more cases:
>>  - const
>>  - atomic, thread C++11 ( C11 influence)
>>
> 
> - I think _Bool was influenced by C++

Yes, and "inline" and _Static_assert.  There are no doubt more examples.

But these are cases either where the C folks have looked at the C++
standards and thought "there's a good idea that we should copy", or
where the two standards committees have got together to make sure a new
feature for both languages works in a similar way.  They are not cases
of C++ /forcing/ something on C.

> 
> I can't find a good place to find the differences and incompatibilities between C 11 and  C++ 17. 
> 

Is there a draft of the C++17 standards yet?  If so, then I would guess
Annex C would be a good place to start - in other C++ standards it talks
about compatibility between C++ and C.  (So in N3797 you get an overview
of incompatibilities between C++14 and C11.)

> I had recent problems with named initializer
> 
> x.pt = (Point) {.x = 1, .y =2};
> 
> or 
> 
> x.pt = (Point) { 1, 2};
> 
> http://stackoverflow.com/questions/18731707/why-does-c11-not-support-designated-initializer-list-as-c99
> 

That is simple one feature (there are not many) that C supports and C++
does not.  It is an annoying omission, and I haven't seen any good
arguments as to why it is omitted (I don't consider "C++ has
constructors, so it doesn't need designated initialisers" to be a good
argument).

[toc] | [prev] | [next] | [standalone]

#96846

Le 18/11/2016 à 13:34, Mr. Man-wai Chang a écrit :
>
> IS it a stupid comment?

One of those unnecessary changes was the very bad idea of an implicit 
return 0 when main returns.

int main(void)
{}

This returns zero.

The problem is that we can never know if the programmer just forgot to 
add a return statement or if he really wanted to returns zero.

[toc] | [prev] | [next] | [standalone]

#96853

On 18/11/2016 11:37 PM, jacobnavia wrote:
> One of those unnecessary changes was the very bad idea of an implicit
> return 0 when main returns.
>
> int main(void)
> {}
>
> This returns zero.
>
> The problem is that we can never know if the programmer just forgot to
> add a return statement or if he really wanted to returns zero.

It really depends on the operating system. Some dictate that a program 
must return an error-level.

[toc] | [prev] | [next] | [standalone]

#96856

On Friday, November 18, 2016 at 9:37:22 AM UTC-6, jacobnavia wrote:
> One of those unnecessary changes was the very bad idea of an implicit 
> return 0 when main returns.
> 
> int main(void)
> {}
> 
> This returns zero.
> 
> The problem is that we can never know if the programmer just forgot to 
> add a return statement or if he really wanted to returns zero.

A difficulty I think is that the C Standard has no way to define what should
and should not be guaranteed if a function with a declared return type runs
off the end.  In some application fields, it's common to have a function
like

    int doSomething(int action, void *parameters);

where some values of action will result in the function having something
meaningful to return and other actions won't.  The authors of the Standard
didn't want to force the called function to include code to set the return
value in situations where the caller is never going to use it, so they
allow valueless returns.  The difficulty is that if a system passes return
values in a register larger than the return type (e.g. TMS32050 uses 16-bit
"int" but returns values in a 32-bit register) and a caller does something
like:

    long x=doSomething(3,0);  // A value of 3 causes a valueless return

the Standard would have no terminology to say that x might receive an
Unspecified value *which could be outside the range of "int"* but behavior
would remain defined, since the Standard has no concept of an Unspecified
value that isn't guaranteed to be within range of its type.

As a consequence, while it's possible to have functions that sometimes
return a value and sometimes don't, there's no way to wrap a call to such
a function unless the wrapper somehow knows whether that call will yield
a meaningful value.  What's needed is a way to allow a function's return
value to be passed through to the caller such that behavior would be fully
defined if code never does anything with the value besides pass it up the
call stack, but no such feature exists.

Previously, the C Standard used to say that a valueless return from main()
was permissible provided that the environment never did anything with its
return value.  Unfortunately, if main() is being called from C code (e.g.
part of the startup library), there would be no way for that C code to
safely process the return.

Personally, I think that rather than having special return semantics for
"main", it would have been nicer to simply allow "void main(whatever)" as
a recognized form, and say that if "main" is declared in that form a
compiler should do what's necessary to have it treated as a function that
returns zero.  That would have made the intent clearer, but that's not
what the Standard does.

[toc] | [prev] | [next] | [standalone]

#96860

On 18/11/16 17:00, supercat@casperkitty.com wrote:
> On Friday, November 18, 2016 at 9:37:22 AM UTC-6, jacobnavia wrote:
>> One of those unnecessary changes was the very bad idea of an implicit 
>> return 0 when main returns.
>>
>> int main(void)
>> {}
>>
>> This returns zero.
>>
>> The problem is that we can never know if the programmer just forgot to 
>> add a return statement or if he really wanted to returns zero.
> 
> A difficulty I think is that the C Standard has no way to define what should
> and should not be guaranteed if a function with a declared return type runs
> off the end.  

The C standard is perfectly clear on the matter - the behaviour is
undefined is the value is used.  The C++ standards are also clear, but
slightly different - reaching the end of a function is equivalent to a
return with no value, and if the function has a non-void return type,
then the behaviour is undefined even if the "value" is never used.

The exception is main(), where running of the end is equivalent to
"return 0;".


> In some application fields, it's common to have a function
> like
> 
>     int doSomething(int action, void *parameters);
> 
> where some values of action will result in the function having something
> meaningful to return and other actions won't.  

I don't know what fields those might be, but I would consider this very
poor practice and it would bring up warnings from most toolchains with
even the most basic warnings enabled.  But it /is/ defined behaviour (in
C, but not C++) to fall off the end of doSomething(), as long as the
return value is never used.

> The authors of the Standard
> didn't want to force the called function to include code to set the return
> value in situations where the caller is never going to use it, so they
> allow valueless returns.

There is no indication as to the "intention" of the the Standard authors
here - merely what the standard says.

>  The difficulty is that if a system passes return
> values in a register larger than the return type (e.g. TMS32050 uses 16-bit
> "int" but returns values in a 32-bit register) and a caller does something
> like:
> 
>     long x=doSomething(3,0);  // A value of 3 causes a valueless return
> 
> the Standard would have no terminology to say that x might receive an
> Unspecified value *which could be outside the range of "int"* but behavior
> would remain defined, since the Standard has no concept of an Unspecified
> value that isn't guaranteed to be within range of its type.

If doSomething() does not return a value, the code above is undefined
behaviour - the standards are clear on that.

> 
> As a consequence, while it's possible to have functions that sometimes
> return a value and sometimes don't, there's no way to wrap a call to such
> a function unless the wrapper somehow knows whether that call will yield
> a meaningful value.  What's needed is a way to allow a function's return
> value to be passed through to the caller such that behavior would be fully
> defined if code never does anything with the value besides pass it up the
> call stack, but no such feature exists.

No, nothing of the sort is "needed".  C works perfectly well here.

> 
> Previously, the C Standard used to say that a valueless return from main()
> was permissible provided that the environment never did anything with its
> return value.  Unfortunately, if main() is being called from C code (e.g.
> part of the startup library), there would be no way for that C code to
> safely process the return.

Such behaviour is going to be implementation dependent as the startup
library that calls main() is part of the implementation.

> 
> Personally, I think that rather than having special return semantics for
> "main", it would have been nicer to simply allow "void main(whatever)" as
> a recognized form, and say that if "main" is declared in that form a
> compiler should do what's necessary to have it treated as a function that
> returns zero.  That would have made the intent clearer, but that's not
> what the Standard does.
> 

[toc] | [prev] | [next] | [standalone]

#96868

supercat@casperkitty.com writes:
[...]
> A difficulty I think is that the C Standard has no way to define what should
> and should not be guaranteed if a function with a declared return type runs
> off the end.  In some application fields, it's common to have a function
> like
>
>     int doSomething(int action, void *parameters);
>
> where some values of action will result in the function having something
> meaningful to return and other actions won't.  The authors of the Standard
> didn't want to force the called function to include code to set the return
> value in situations where the caller is never going to use it, so they
> allow valueless returns.
[...]

I don't believe that's the rationale.  Do you have a citation to support
your claim?

Pre-ANSI C did not have the "void" type and keyword.  It was not
possible to define a function that did not return a value.  To write a
function that doesn't return a *meaningful* value, the convention was to
define it with no explicit return type:

    func() {
        do_something;
    }

Of course func() implicitly returned int, but if the value was never
used it was acceptable not to return a value.

Later versions of C had to avoid breaking old code, so they permit a
function to fail to explicitly return a result as long as the caller
doesn't use that result.  If C had had "void" from the beginning, it
would have made more sense to make falling off the end of a non-void
function undefined behavior.

The *only* reason to support non-void functions that don't return
results is to support old code.

In well-written modern C, if an int function doesn't always return a
meaningful result, it can simply return 0, and if a function never
returns a meaningful result it can have a return type of void.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#96858

On 18/11/16 16:37, jacobnavia wrote:
> Le 18/11/2016 à 13:34, Mr. Man-wai Chang a écrit :
>>
>> IS it a stupid comment?
> 
> One of those unnecessary changes was the very bad idea of an implicit
> return 0 when main returns.
> 

I don't have an old enough C standard on hand to tell if this was a
change, but why would you classify it as a change /forced/ on C by C++?

Personally, I don't see it as a bad idea to make main() return 0 by
default.  But then, on most of my programs it is a /really/ bad idea if
main() returns at all.

> int main(void)
> {}
> 
> This returns zero.
> 
> The problem is that we can never know if the programmer just forgot to
> add a return statement or if he really wanted to returns zero.
> 

For most programs, the return value is irrelevant - and a default value
of "success" seems fine.  And for programs where it /is/ relevant, it is
unlikely that a return value would be forgotten.

[toc] | [prev] | [next] | [standalone]

#96864

Le 18/11/2016 à 17:09, David Brown a écrit :
> For most programs, the return value is irrelevant - and a default value
> of "success" seems fine.  And for programs where it /is/ relevant, it is
> unlikely that a return value would be forgotten.

Well, if you do forget to setup the return value you had a warning or an 
error before.

Now the compiler can't say anything since it is perfectly legal behavior.

[toc] | [prev] | [next] | [standalone]

#97173

On Fri, 18 Nov 2016 18:02:32 +0100, jacobnavia
<jacob@jacob.remcomp.fr> wrote:

>Le 18/11/2016 à 17:09, David Brown a écrit :
>> For most programs, the return value is irrelevant - and a default value
>> of "success" seems fine.  And for programs where it /is/ relevant, it is
>> unlikely that a return value would be forgotten.
>
>Well, if you do forget to setup the return value you had a warning or an 
>error before.
>
>Now the compiler can't say anything since it is perfectly legal behavior.


Falling off the end of main() without a return was legal in C89, but
the actual value returned to the environment was undefined.  In C99
falling off the end of main is still legal, only now the actual
returned value in that case is defined.

[toc] | [prev] | [next] | [standalone]

#97231

Le 21/11/2016 à 10:26, Robert Wessel a écrit :
> Falling off the end of main() without a return was legal in C89, but
> the actual value returned to the environment was undefined.

Any sensible compiler would complain since returning from a function 
that should return a value without assigning the return value is always 
an error.

In C99
> falling off the end of main is still legal, only now the actual
> returned value in that case is defined.

And now the compiler CAN'T DISTINGUISH between:

1) Programmer forgot to assign the return value
2) Programmer doesn't assign the return value since he/she knows that it 
will be set to zero.

So, it can't complain.

[toc] | [prev] | [next] | [standalone]

#97288

On Tuesday, November 22, 2016 at 5:12:00 AM UTC-5, jacobnavia wrote:
> Le 21/11/2016 à 10:26, Robert Wessel a écrit :
> > Falling off the end of main() without a return was legal in C89, but
> > the actual value returned to the environment was undefined.
> 
> Any sensible compiler would complain since returning from a function 
> that should return a value without assigning the return value is always 
> an error.
> 
> In C99
> > falling off the end of main is still legal, only now the actual
> > returned value in that case is defined.
> 
> And now the compiler CAN'T DISTINGUISH between:
> 
> 1) Programmer forgot to assign the return value
> 2) Programmer doesn't assign the return value since he/she knows that it 
> will be set to zero.
> 
> So, it can't complain.

Why not? Diagnostic messages are never prohibited, and I'd actually prefer a
compiler that always issued a diagnostic in this situation, despite the fact
that option 2 is a possibility. Other people would prefer to have an ability to
turn off such messages, and most compilers have some way of doing that.

[toc] | [prev] | [next] | [standalone]

#97452

On Tue, 22 Nov 2016 11:11:52 +0100, jacobnavia
<jacob@jacob.remcomp.fr> wrote:

>Le 21/11/2016 à 10:26, Robert Wessel a écrit :
>> Falling off the end of main() without a return was legal in C89, but
>> the actual value returned to the environment was undefined.
>
>Any sensible compiler would complain since returning from a function 
>that should return a value without assigning the return value is always 
>an error.


No, the point is that C89 makes a special dispensation (5.1.2.2.3) for
main() (only in a hosted environment, and for no other function), so
that falling off the end of main() without a return is *not* an error.
At least from a standard's perspective.  It's darn bad practice, of
course.


>In C99
>> falling off the end of main is still legal, only now the actual
>> returned value in that case is defined.
>
>And now the compiler CAN'T DISTINGUISH between:
>
>1) Programmer forgot to assign the return value
>2) Programmer doesn't assign the return value since he/she knows that it 
>will be set to zero.
>
>So, it can't complain.


As James pointed out, a warning in either C89 or C99 would be quite
reasonable.

[toc] | [prev] | [next] | [standalone]

#97471

On Friday, November 25, 2016 at 3:25:27 AM UTC-6, robert wrote:
> No, the point is that C89 makes a special dispensation (5.1.2.2.3) for
> main() (only in a hosted environment, and for no other function), so
> that falling off the end of main() without a return is *not* an error.
> At least from a standard's perspective.  It's darn bad practice, of
> course.

What would you think of simply allowing "main" to be declared as "void",
with the proviso that a compiler might interpret

   void main(...params...) {...}

as 

   void __main(...params...) {...}
   int main(...params...) { __main(...params...); return 0; }

or as a function returning "int", wherein all "return" statements would be
replaced with "return 0;", and a "return 0;" would be added at the end?

Having "main" return both with and without a value seems sloppy, but if
main() is never going to return anything meaningful requiring a "return 0;"
at the end of it would seem like a mandated waste of programmer effort.

[toc] | [prev] | [next] | [standalone]

#97478

Robert Wessel <robertwessel2@yahoo.com> writes:
> On Tue, 22 Nov 2016 11:11:52 +0100, jacobnavia
> <jacob@jacob.remcomp.fr> wrote:
>>Le 21/11/2016 à 10:26, Robert Wessel a écrit :
>>> Falling off the end of main() without a return was legal in C89, but
>>> the actual value returned to the environment was undefined.
>>
>>Any sensible compiler would complain since returning from a function 
>>that should return a value without assigning the return value is always 
>>an error.
>
> No, the point is that C89 makes a special dispensation (5.1.2.2.3) for
> main() (only in a hosted environment, and for no other function), so
> that falling off the end of main() without a return is *not* an error.
> At least from a standard's perspective.  It's darn bad practice, of
> course.

It depends on what you mean by "an error".  It is neither a constraint
violation nor undefined behavior.

C89 had no section 5.1.2.2.3; that's from the equivalent but renumbered
ISO C90 standard.  (It would have been 2.1.2.2.3 in the ANSI C89
standard.)

What that section says is that

    If the main function executes a return that specifies no value, the
    termination status returned to the host environment is undefined.

6.6.6.4 says that reaching the closing "}" is equivalent to a "return;".

Falling off the end of *any* function without returning a value is not
an error in C89/C90.  It's only attempting to use the result that has
undefined behavior.  C99 and C11 keep that rule; a "return;" with no
value is forbidden in a non-void function, but it's still legal (but a
bad idea) to fall off the end.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#97491

Le 25/11/2016 à 21:30, Keith Thompson a écrit :

> Falling off the end of *any* function without returning a value is not
> an error in C89/C90.  It's only attempting to use the result that has
> undefined behavior.  C99 and C11 keep that rule; a "return;" with no
> value is forbidden in a non-void function, but it's still legal (but a
> bad idea) to fall off the end.
>

It would be better that should be promoted to error. I have a warning 
when you forget to establish the return value of a non void function.

It would be better to promote that warning to an error. The code that 
does that is in general BROKEN, since any use of the return value of 
that function is a bomb that explodes into your software: the 
introduction of NOISE in the data stream. That noise is amplified (or 
not) by the position and importance of the usage of the noise in the 
software.

If the committee decided that the old behaviour is wrong, a lot of bugs 
in old C software would surface. It depends then, if the old C software 
is still being actively used for important stuff. All compilers would 
introduce a compatibility option, but the users of the software would be 
warned that the software has a real problem!

Old software is rarely used for unimportant stuff, and it would be much 
nicer for everyone that the old software is fixed too.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web