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

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

Making sense of warning about "initialization makes pointer from integer without a cast"

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

Contents

  Making sense of warning about "initialization makes pointer from integer without a cast" "Morten W. Petersen" <morphex@gmail.com> - 2015-10-04 04:40 +0200
    Re: Making sense of warning about "initialization makes pointer from integer without a cast" "Morten W. Petersen" <morphex@gmail.com> - 2015-10-04 04:59 +0200
      Re: Making sense of warning about "initialization makes pointer from integer without a cast" James Kuyper <jameskuyper@verizon.net> - 2015-10-03 23:23 -0400
      Re: Making sense of warning about "initialization makes pointer from integer without a cast" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-04 13:47 +0100
        Re: Making sense of warning about "initialization makes pointer from integer without a cast" Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-04 09:40 -0400
          Re: Making sense of warning about "initialization makes pointer from integer without a cast" "Morten W. Petersen" <morphex@gmail.com> - 2015-10-05 00:33 +0200
            Re: Making sense of warning about "initialization makes pointer from integer without a cast" James Kuyper <jameskuyper@verizon.net> - 2015-10-04 19:07 -0400
    Re: Making sense of warning about "initialization makes pointer from integer without a cast" Melzzzzz <mel@zzzzz.com> - 2015-10-04 05:08 +0200
    Re: Making sense of warning about "initialization makes pointer from integer without a cast" James Kuyper <jameskuyper@verizon.net> - 2015-10-03 23:16 -0400
      Re: Making sense of warning about "initialization makes pointer from integer without a cast" "Morten W. Petersen" <morphex@gmail.com> - 2015-10-04 05:23 +0200
        Re: Making sense of warning about "initialization makes pointer from integer without a cast" James Kuyper <jameskuyper@verizon.net> - 2015-10-03 23:34 -0400
          Re: Making sense of warning about "initialization makes pointer from integer without a cast" "Morten W. Petersen" <morphex@gmail.com> - 2015-10-04 05:50 +0200
            Re: Making sense of warning about "initialization makes pointer from integer without a cast" James Kuyper <jameskuyper@verizon.net> - 2015-10-04 13:49 -0400
              Re: Making sense of warning about "initialization makes pointer from integer without a cast" Richard Heathfield <rjh@cpax.org.uk> - 2015-10-04 19:11 +0100
                Re: Making sense of warning about "initialization makes pointer from integer without a cast" James Kuyper <jameskuyper@verizon.net> - 2015-10-04 15:12 -0400
                  Re: Making sense of warning about "initialization makes pointer from integer without a cast" Richard Heathfield <rjh@cpax.org.uk> - 2015-10-04 20:52 +0100
                  Re: Making sense of warning about "initialization makes pointer from integer without a cast" supercat@casperkitty.com - 2015-10-04 13:18 -0700
              Re: Making sense of warning about "initialization makes pointer from integer without a cast" "Morten W. Petersen" <morphex@gmail.com> - 2015-10-05 00:26 +0200
                Re: Making sense of warning about "initialization makes pointer from integer without a cast" Keith Thompson <kst-u@mib.org> - 2015-10-04 18:09 -0700
                  Re: Making sense of warning about "initialization makes pointer from integer without a cast" supercat@casperkitty.com - 2015-10-04 19:55 -0700
        Re: Making sense of warning about "initialization makes pointer from integer without a cast" Keith Thompson <kst-u@mib.org> - 2015-10-04 15:10 -0700
    Re: Making sense of warning about "initialization makes pointer from integer without a cast" Geoff <geoff@invalid.invalid> - 2015-10-03 22:04 -0700
      Re: Making sense of warning about "initialization makes pointer from integer without a cast" "Morten W. Petersen" <morphex@gmail.com> - 2015-10-04 07:07 +0200
        Re: Making sense of warning about "initialization makes pointer from integer without a cast" Geoff <geoff@invalid.invalid> - 2015-10-03 23:29 -0700
    Re: Making sense of warning about "initialization makes pointer from   integer without a cast" Ian Collins <ian-news@hotmail.com> - 2015-10-04 19:18 +1300
    Re: Making sense of warning about "initialization makes pointer from integer without a cast" Siri Cruz <chine.bleu@yahoo.com> - 2015-10-03 23:29 -0700

Page 1 of 2  [1] 2  Next page →

#71771 — Making sense of warning about "initialization makes pointer from integer without a cast"

Hi there.

In my project Smash XML, I'm getting a warning of an incompatible
pointer type (version getting the error is here):

https://github.com/morphex/smash_xml/tree/d381c7e596769dbcf6f2c0811f0f3cfd59bb8709

And the error is this:

$ make
gcc -std=c90 -Wall -Wno-implicit-function-declaration decode_xml.c 
tests.c -g -o decode_xml -I.
tests.c: In function `main':
tests.c:228:34: warning: initialization makes pointer from integer 
without a cast
      struct xml_element *result = parse_file(file);

The function definition parse_file says that it will return a pointer,
it also does in the function.

What's wrong here?

-Morten

[toc] | [next] | [standalone]

#71773

On 04.10.2015 04:55, Stefan Ram wrote:
> "Morten W. Petersen" <morphex@gmail.com> writes:
>> tests.c:228:34: warning: initialization makes pointer from integer
>> without a cast
>>       struct xml_element *result = parse_file(file);
>> The function definition parse_file says that it will return a pointer,
>> it also does in the function.
>
>    When the function /definition/ is in »decode_xml.c«, but not
>    in »test.c«, the compiler will not see it when compiling
>    »test.c«. During the compilation of »test.c« the compiler
>    will only see the function /declaration/ that is in
>    »decode_xml.h«, which is #included at the top of »test.c«.

OK.  So things are different when it comes to functions that
return pointers instead of for example an integer?

Other functions in decode_xml.c work in tests.c..

-Morten

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

#71777

On 10/03/2015 10:59 PM, Morten W. Petersen wrote:
> On 04.10.2015 04:55, Stefan Ram wrote:
>> "Morten W. Petersen" <morphex@gmail.com> writes:
>>> tests.c:228:34: warning: initialization makes pointer from integer
>>> without a cast
>>>       struct xml_element *result = parse_file(file);
>>> The function definition parse_file says that it will return a pointer,
>>> it also does in the function.
>>
>>    When the function /definition/ is in �decode_xml.c�, but not
>>    in �test.c�, the compiler will not see it when compiling
>>    �test.c�. During the compilation of �test.c� the compiler
>>    will only see the function /declaration/ that is in
>>    �decode_xml.h�, which is #included at the top of �test.c�.
> 
> OK.  So things are different when it comes to functions that
> return pointers instead of for example an integer?

If you provide the declaration he's talking about, it doesn't make any
difference. If you failed to provide a declaration, it does make a
difference, which is why I think that you didn't provide one. In C90,
when a function is called that has not been declared, a declaration for
the function is implicitly created, identifying it as returning an
'int'. This will work, if the function definition returns an 'int'.
-- 
James Kuyper

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

#71800

"Morten W. Petersen" <morphex@gmail.com> writes:

> On 04.10.2015 04:55, Stefan Ram wrote:
>> "Morten W. Petersen" <morphex@gmail.com> writes:
>>> tests.c:228:34: warning: initialization makes pointer from integer
>>> without a cast
>>>       struct xml_element *result = parse_file(file);
>>> The function definition parse_file says that it will return a pointer,
>>> it also does in the function.
>>
>>    When the function /definition/ is in »decode_xml.c«, but not
>>    in »test.c«, the compiler will not see it when compiling
>>    »test.c«. During the compilation of »test.c« the compiler
>>    will only see the function /declaration/ that is in
>>    »decode_xml.h«, which is #included at the top of »test.c«.
>
> OK.  So things are different when it comes to functions that
> return pointers instead of for example an integer?

Yes.  The implict declaration that C90 adds for an as-yet undefclared
function is

  extern int identifier();

and that is not a prototype.  This has implications for the semantics of
argument passing as well.  It's not worth finding out the gory details
because you should just *always* supply a prototype.

> Other functions in decode_xml.c work in tests.c..

I've not checked, but you might be hit by the subtle difference between
prototyped and un-prototyped functions.
>

-- 
Ben.

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

#71805

On 10/4/2015 8:47 AM, Ben Bacarisse wrote:
> "Morten W. Petersen" <morphex@gmail.com> writes:
>
>> On 04.10.2015 04:55, Stefan Ram wrote:
>>> "Morten W. Petersen" <morphex@gmail.com> writes:
>>>> tests.c:228:34: warning: initialization makes pointer from integer
>>>> without a cast
>>>>        struct xml_element *result = parse_file(file);
>>>> The function definition parse_file says that it will return a pointer,
>>>> it also does in the function.
>>>
>>>     When the function /definition/ is in »decode_xml.c«, but not
>>>     in »test.c«, the compiler will not see it when compiling
>>>     »test.c«. During the compilation of »test.c« the compiler
>>>     will only see the function /declaration/ that is in
>>>     »decode_xml.h«, which is #included at the top of »test.c«.
>>
>> OK.  So things are different when it comes to functions that
>> return pointers instead of for example an integer?
>
> Yes.  The implict declaration that C90 adds for an as-yet undefclared
> function is
>
>    extern int identifier();
>
> and that is not a prototype.  This has implications for the semantics of
> argument passing as well.  It's not worth finding out the gory details
> because you should just *always* supply a prototype.
>[...]

     Seconded -- thirded, and N'thed.

     In another thread, Morten W. Peterson refers to "when prototypes
are added," as a sort of late-stage cross-the-eyes-and-dot-the-tees
final cleanup.  One lesson to be learned from the experience recounted
in this thread is that prototypes are of greatest value *during* the
development phase.  They are not the fancy ribbons that are the last
bits you add to a gift box, but tools to help make the gift itself.

     Write prototypes first, not finally.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#71877

On 04.10.2015 15:40, Eric Sosman wrote:
[...]
>      Seconded -- thirded, and N'thed.
>
>      In another thread, Morten W. Peterson refers to "when prototypes
> are added," as a sort of late-stage cross-the-eyes-and-dot-the-tees
> final cleanup.  One lesson to be learned from the experience recounted
> in this thread is that prototypes are of greatest value *during* the
> development phase.  They are not the fancy ribbons that are the last
> bits you add to a gift box, but tools to help make the gift itself.
>
>      Write prototypes first, not finally.

I think that's a matter of programming style.  I'm used to writing in
Python, so just dishing out a function is natural to me.

Now with some white-space and \ adjustments to function definitions,
the makeheaders.c tool generates the prototypes and everything is good.

I'd still like a tool that can generate function prototypes with some
comments automatically, so I'll look around for that.

-Morten

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

#71891

On 10/04/2015 06:33 PM, Morten W. Petersen wrote:
> On 04.10.2015 15:40, Eric Sosman wrote:
> [...]
>>      Seconded -- thirded, and N'thed.
>>
>>      In another thread, Morten W. Peterson refers to "when prototypes
>> are added," as a sort of late-stage cross-the-eyes-and-dot-the-tees
>> final cleanup.  One lesson to be learned from the experience recounted
>> in this thread is that prototypes are of greatest value *during* the
>> development phase.  They are not the fancy ribbons that are the last
>> bits you add to a gift box, but tools to help make the gift itself.
>>
>>      Write prototypes first, not finally.
> 
> I think that's a matter of programming style.  I'm used to writing in
> Python, so just dishing out a function is natural to me.

By delaying the creation of function prototypes, you're depriving
yourself of valuable bug-detection capabilities that have their greatest
value during the early stages of development. It's a foolish kind of
laziness that delays creation of the prototype until after it has become
less useful. Also, a declaration (not necessarily a prototype) is needed
in scope whenever you call a function whose return value is anything
other than 'int' - which is precisely the problem that this thread is about.

If a function is declared with a prototype that's in scope at the point
of a function call, arguments that can be implicitly converted to the
type of the corresponding parameter, are so converted; without a
prototype, the default argument promotions occur.  If you ever write a
function prototype which declares a parameter type that is incompatible
with the promoted type of the corresponding argument, then the type of
the value passed to the function will change when the prototype is
introduced. If such code had defined behavior before the prototype was
introduced, then the prototype doesn't correctly match the function
definition, so introducing the function prototype will cause the
behavior to become undefined.

Therefore, it's a good idea to introduce the prototype at the same time
as the function definition, or even before then, so you can start
debugging any such mismatches as soon as possible.

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

#71774

On Sun, 4 Oct 2015 04:40:38 +0200
"Morten W. Petersen" <morphex@gmail.com> wrote:

> Hi there.
> 
> In my project Smash XML, I'm getting a warning of an incompatible
> pointer type (version getting the error is here):
> 
> https://github.com/morphex/smash_xml/tree/d381c7e596769dbcf6f2c0811f0f3cfd59bb8709
> 
> And the error is this:
> 
> $ make
> gcc -std=c90 -Wall -Wno-implicit-function-declaration decode_xml.c 
> tests.c -g -o decode_xml -I.
> tests.c: In function `main':
> tests.c:228:34: warning: initialization makes pointer from integer 
> without a cast
>       struct xml_element *result = parse_file(file);
> 
> The function definition parse_file says that it will return a pointer,
> it also does in the function.
> 
> What's wrong here?
> 
> -Morten

You don't have headers? Your function is implicitly declared, therefore
it returns int. You'll get crash as int is usually 4 bytes and pointer
8 bytes on 64 bit system...

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

#71776

On 10/03/2015 10:40 PM, Morten W. Petersen wrote:
> Hi there.
> 
> In my project Smash XML, I'm getting a warning of an incompatible
> pointer type (version getting the error is here):
> 
> https://github.com/morphex/smash_xml/tree/d381c7e596769dbcf6f2c0811f0f3cfd59bb8709
> 
> And the error is this:
> 
> $ make
> gcc -std=c90 -Wall -Wno-implicit-function-declaration decode_xml.c 
> tests.c -g -o decode_xml -I.
> tests.c: In function `main':
> tests.c:228:34: warning: initialization makes pointer from integer 
> without a cast
>       struct xml_element *result = parse_file(file);
> 
> The function definition parse_file says that it will return a pointer,
> it also does in the function.
> 
> What's wrong here?

It's not the function definition that matters. It's the declaration for
that function which is visible at this point in the code. A function
definition inherently contains a function declaration, but that
declaration is visible only it the same translation unit, and only in
the part after the function definition. If you want to call the function
from any other part of the program, you should provide a declaration for
that function which is in scope at the point where the function is
called. Show us that declaration, and we may be able to figure out what
went wrong with this program.

My guess is that you don't have such a declaration visible, which would
be a bad mistake on your part - but it's consistent with your confusion
about the proper role of header files.
If you have no declaration in scope, since you're using C90, an
declaration is implicitly created, which returns an 'int'. The error
message you get is due to the fact that there's no implicit conversion
from 'int' to 'struct xml_element*'.

Note: this is a mis-feature of C90, which is why it was corrected in
C99. In C99, the wording that required creation of the implicit
declaration was dropped - if you don't have an explicit function
declaration in scope, the identifier for the function doesn't have any
declared type associated with it, violating the constraint in 6.5.5.2p1.

If you insist on coding to an obsolete standard, you'll have to learn to
live with a version of the language that has a lot of known defects that
have since been fixed.
-- 
James Kuyper

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

#71778

On 04.10.2015 05:16, James Kuyper wrote:
> On 10/03/2015 10:40 PM, Morten W. Petersen wrote:
>> Hi there.
>>
>> In my project Smash XML, I'm getting a warning of an incompatible
>> pointer type (version getting the error is here):
>>
>> https://github.com/morphex/smash_xml/tree/d381c7e596769dbcf6f2c0811f0f3cfd59bb8709
>>
>> And the error is this:
>>
>> $ make
>> gcc -std=c90 -Wall -Wno-implicit-function-declaration decode_xml.c
>> tests.c -g -o decode_xml -I.
>> tests.c: In function `main':
>> tests.c:228:34: warning: initialization makes pointer from integer
>> without a cast
>>        struct xml_element *result = parse_file(file);
>>
>> The function definition parse_file says that it will return a pointer,
>> it also does in the function.
>>
>> What's wrong here?
>
[...]
> My guess is that you don't have such a declaration visible, which would
> be a bad mistake on your part - but it's consistent with your confusion
> about the proper role of header files.
> If you have no declaration in scope, since you're using C90, an
> declaration is implicitly created, which returns an 'int'. The error
> message you get is due to the fact that there's no implicit conversion
> from 'int' to 'struct xml_element*'.
>
> Note: this is a mis-feature of C90, which is why it was corrected in
> C99. In C99, the wording that required creation of the implicit
> declaration was dropped - if you don't have an explicit function
> declaration in scope, the identifier for the function doesn't have any
> declared type associated with it, violating the constraint in 6.5.5.2p1.

Wow, OK.  So I'll need to generate a header file with functions
declarations automatically then.

> If you insist on coding to an obsolete standard, you'll have to learn to
> live with a version of the language that has a lot of known defects that
> have since been fixed.

Well there was a thread some time ago on comp.lang.c where different
language variants was discussed, and the decision was made there.

If you want to point out what you think are flaws in the reasoning
there I'd listen to your arguments.

-Morten

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

#71780

On 10/03/2015 11:23 PM, Morten W. Petersen wrote:
...
> Well there was a thread some time ago on comp.lang.c where different
> language variants was discussed, and the decision was made there.
> 
> If you want to point out what you think are flaws in the reasoning
> there I'd listen to your arguments.

If you can identify the thread you're talking about, I'll review it to
see if there's anything I'd like to say about it. However, I monitor
this group pretty closely - if I didn't comment on the thread at the
time, it's probably because, for any of a number of possible reasons, I
did not "want to point out what [I] think are flaws". One likely reason
is that the flaws were in arguments posted by people whose messages I
filter out, so I didn't even see those flaws. Discussing those flaws
would involve engaging those people in a discussion, and I've filtered
out those messages precisely because I don't want to talk with them.
-- 
James Kuyper

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

#71781

On 04.10.2015 05:34, James Kuyper wrote:
> On 10/03/2015 11:23 PM, Morten W. Petersen wrote:
> ...
>> Well there was a thread some time ago on comp.lang.c where different
>> language variants was discussed, and the decision was made there.
>>
>> If you want to point out what you think are flaws in the reasoning
>> there I'd listen to your arguments.
>
> If you can identify the thread you're talking about, I'll review it to
> see if there's anything I'd like to say about it. However, I monitor
> this group pretty closely - if I didn't comment on the thread at the
> time, it's probably because, for any of a number of possible reasons, I
> did not "want to point out what [I] think are flaws". One likely reason
> is that the flaws were in arguments posted by people whose messages I
> filter out, so I didn't even see those flaws. Discussing those flaws
> would involve engaging those people in a discussion, and I've filtered
> out those messages precisely because I don't want to talk with them.

OK, look for the thread that starts with

Date: Wed, 10 Jun 2015 22:32:56 -0700 (PDT)
Message-ID: <869bae8d-e318-4e1c-865b-3c5890304279@googlegroups.com>
Subject: Reason for segmentation violation
From: "Morten W. Petersen" <morphex@gmail.com>

-Morten

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

#71831

On 10/03/2015 11:50 PM, Morten W. Petersen wrote:
> On 04.10.2015 05:34, James Kuyper wrote:
>> On 10/03/2015 11:23 PM, Morten W. Petersen wrote:
>> ...
>>> Well there was a thread some time ago on comp.lang.c where different
>>> language variants was discussed, and the decision was made there.
>>>
>>> If you want to point out what you think are flaws in the reasoning
>>> there I'd listen to your arguments.
>>
>> If you can identify the thread you're talking about, I'll review it to
>> see if there's anything I'd like to say about it. However, I monitor
>> this group pretty closely - if I didn't comment on the thread at the
>> time, it's probably because, for any of a number of possible reasons, I
>> did not "want to point out what [I] think are flaws". One likely reason
>> is that the flaws were in arguments posted by people whose messages I
>> filter out, so I didn't even see those flaws. Discussing those flaws
>> would involve engaging those people in a discussion, and I've filtered
>> out those messages precisely because I don't want to talk with them.
> 
> OK, look for the thread that starts with
> 
> Date: Wed, 10 Jun 2015 22:32:56 -0700 (PDT)
> Message-ID: <869bae8d-e318-4e1c-865b-3c5890304279@googlegroups.com>
> Subject: Reason for segmentation violation
> From: "Morten W. Petersen" <morphex@gmail.com>

OK. That thread has 184 messages, 13 of which were from me, but none of
my messages addressed the issue of which version of C was the best one
to use. Therefore, I looked for messages written by you that involved
that issue, and found one with the Date: header of "Thu, 11 Jun 2015
23:42:01 -0700 (PDT)".

In that sub-thread, Richard Heathfield correctly identified the common
sub-set of C90, C99, and C2011 as the maximally portable version of C to
use. However, if you're going to use that sub-set, I'd recommend
compiling it with C2011, and only compiling it with C90 to confirm that
the code is indeed within that common subset. There was very little
additional discussion of the matter, other than an erroneous comment by
David Kleinecke that was corrected by Keith Thompson.

However, a key issue is - do you really need your code to be "maximally
portable"? It's sort-of like shopping for computers - do you really need
the most powerful available desktop computer? It's easy to say, but when
you actually have to pay for it, it may make more sense to choose a less
powerful system that is still powerful enough for your needs, but costs
a whole lot less money.
If you insist on "maximally portable", that means you'll never be able
to use the nice features that were added in later versions of the
standard. Is that a price you're willing to pay? If everyone took that
same approach, no one would ever put any pressure on implementors to
implement the new features, nor would they put any pressure on system
administrators to install those updated implementations. That is, in my
opinion, the main reason why C99 was implemented so slowly.

Richard Heathfield has never seen any new feature that he considered
sufficiently worthwhile to justify accepting the reduction in
portability - the "never" in that statement make me suspect, that he's
letting a powerful preference for maximal portability cloud his judgment
of the value of those features.

Both revisions of the C standard have included new features that I'd be
willing to sacrifice portability for, in order to make use of those
features - if I were writing code that could make use of those features.
Our client for the MODIS project imposed a requirement that we use C95
(C90 + two technical corrigenda), so I can't make use of those features
in delivered MODIS code. Our code for the VIIRS NPP project has far
fewer formal constraints, but is written in C++, so I can only use those
new features of C that are also features of C++.

One of the key reasons I'd be willing to make that sacrifice in
portability is that it wouldn't be much of a sacrifice. As I understand
it, every new feature of C99, and most of the new features of C2011,
have been implemented both by gcc and clang, and those two compilers
between them cover the overwhelming majority of platforms that I'd ever
have a desire to port my code to.

Keith Thompson made comments to a similar affect in that sub-thread,
which is probably why I didn't bother saying the same thing.

Richard says that his clients require him to produce code that must be
portable even to machines for which there's no C99 implementation
available. Ordinarily, I'd be skeptical of such a claim, mainly because
there's relatively few such systems. However, I don't actually know who
his clients are, or what they've asked him to do, so he might be right -
but he himself has admitted that he's prone to exaggeration, so it might
be a need that he used to have, and hasn't bothered to check whether
it's still true. After all, he's comfortable restricting himself to a
forward-compatible subset of C90, so why should he bother checking?

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

#71833

On 04/10/15 18:49, James Kuyper wrote:

<snip>

> In that sub-thread, Richard Heathfield correctly identified the common
> sub-set of C90, C99, and C2011 as the maximally portable version of C to
> use. However, if you're going to use that sub-set, I'd recommend
> compiling it with C2011, and only compiling it with C90 to confirm that
> the code is indeed within that common subset.

I'd agree with that, actually. Well, the order doesn't matter very much 
to me, but I'd certainly agree that it should be compiled under the 
rules of each standard, and regression tests conducted for each 
executable program thus produced.

> However, a key issue is - do you really need your code to be "maximally
> portable"? It's sort-of like shopping for computers - do you really need
> the most powerful available desktop computer? It's easy to say, but when
> you actually have to pay for it, it may make more sense to choose a less
> powerful system that is still powerful enough for your needs, but costs
> a whole lot less money.

Right. Portability comes at a cost. (Non-portability comes at a 
different cost.)

If I don't need portable, I generally use <cough> C++.

<snip>

> Richard Heathfield has never seen any new feature that he considered
> sufficiently worthwhile to justify accepting the reduction in
> portability - the "never" in that statement make me suspect, that he's
> letting a powerful preference for maximal portability cloud his judgment
> of the value of those features.

Much as I love C, if portability is not an issue then I will tend to 
gravitate to the toy-box, and the biggest, brightest toy-box in the room 
is C++.

> Richard says that his clients require him to produce code that must be
> portable even to machines for which there's no C99 implementation
> available. Ordinarily, I'd be skeptical of such a claim, mainly because
> there's relatively few such systems. However, I don't actually know who
> his clients are, or what they've asked him to do, so he might be right -
> but he himself has admitted that he's prone to exaggeration,

No, I haven't! (Well, all right, maybe I have admitted that, a little 
bit. But hardly at all!)

For much of the C code I write, I have no idea what compiler most of my 
users are actually using. It has never occurred to me to ask. It has 
never occurred to me that the question might be interesting or the 
answer useful.

> so it might
> be a need that he used to have, and hasn't bothered to check whether
> it's still true. After all, he's comfortable restricting himself to a
> forward-compatible subset of C90, so why should he bother checking?

I used to use C for everything, but nowadays I /only/ use it when (a) I 
really do need portability between at least two disparate systems or 
when I have no idea what the users' implementations are, or (b) I'm 
writing tiny little CLI programs. For big GUI stuff, I use C++.

For CLI programs, I find the C90/C99 common subset (pace, C2011, if I 
spot any bits that I have to chop off to fit you in, I will indeed chop 
those bits off) to be so familiar that programming in it is easier and 
quicker than switching to C99 (or, nowadays, C11). Why switch if there's 
no need?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#71840

On 10/04/2015 02:11 PM, Richard Heathfield wrote:
...
> For CLI programs, I find the C90/C99 common subset (pace, C2011, if I 
> spot any bits that I have to chop off to fit you in, I will indeed chop 
> those bits off) to be so familiar that programming in it is easier and 
> quicker than switching to C99 (or, nowadays, C11). Why switch if there's 
> no need?

Just because there's no need, doesn't mean there's no desire. You
obviously don't desire to use the new features of C99 and C2011 - but I
certain would like to, if I could.

VLAs would simplify a lot of my code, which deals with small
multi-dimensional arrays whose dimensions are variable. The size-named
types would allow me to more precisely specify the characteristics I
want for each variable. Dropping implicit int, dropping implicit
function declarations, removing gets(), new restrictions on the use of
return statements, and standardizing the handling of a/b when a and b
have opposite signs are all significant fixes to misfeatures of C90. the
snprintf() family does something I've long wanted to be able to do.
Designated initializers would be helpful in a few special cases. Complex
math would make some things I'm interested in doing (but am not
currently doing) a lot easier - with C90 I'd have to write the code in
terms of separate real and imaginary parts, which makes it the code a
whole lot more obscure. The many other improvements to floating point
math support are also far more attractive to me than they are to most
people. // comments are a nice convenience. Declarations mixed in with
statements, and declarations in the first part of for() statements make
it easier to more tightly control the scope of my declarations.

I don't have any current need to write multi-threaded code, but if I
did, having the ability to rely upon <threads.h> rather than, for
instance, <pthreads.h> would have some attraction. Someday, the number
of non-POSIX platforms where <threads.h> is supported might exceed the
number of POSIX platforms where <threads.h> is not yet supported, though
I don't think we're there yet. If that happens, code that can be written
to use only <threads.h> would be more portable.
I think that _Static_assert and _Noreturn are definite improvements, and
that _Generic could reduce the need to switch to C++.

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

#71842

On 04/10/15 20:12, James Kuyper wrote:
> On 10/04/2015 02:11 PM, Richard Heathfield wrote:
> ...
>> For CLI programs, I find the C90/C99 common subset (pace, C2011, if I
>> spot any bits that I have to chop off to fit you in, I will indeed chop
>> those bits off) to be so familiar that programming in it is easier and
>> quicker than switching to C99 (or, nowadays, C11). Why switch if there's
>> no need?
>
> Just because there's no need, doesn't mean there's no desire. You
> obviously don't desire to use the new features of C99 and C2011

Right. There's nothing there that particularly floats my boat (or even 
doubles my boat).

> - but I certain would like to, if I could.

Vive la difference!

<list snipped - not to dismiss the list as unimportant, but simply 
because I have no particular observations to make about it>

> I think that _Static_assert and _Noreturn are definite improvements, and
> that _Generic could reduce the need to switch to C++.

In my case, I don't think it would make any difference. I use C++ for 
writing GUI programs. Can we write GUI programs in C? Sure, but it's 
much harder work. (Actually, we can't write GUIs in either C or C++, but 
you know what I mean - language+framework rather than language alone.) 
For X, I might conceivably use C, but for Win32 it's no contest - C++ 
definitely has the best framework (for my purposes, at least).

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#71846

On Sunday, October 4, 2015 at 2:12:31 PM UTC-5, James Kuyper wrote:
> . . .                                                   The size-named
> types would allow me to more precisely specify the characteristics I
> want for each variable.

Regrettably, they don't.  For each N greater than 15, the Standard defines two
kinds of uintN_t, one of which is always promoted to a signed integer type when
performing arithmetic, and the other of which is not.  Compilers where INT_MAX
is no less than (2^N)-1 are allowed to implement the first kind; those where
INT_MAX is smaller are allowed to implement the second.

IMHO, C would be hugely improved as a language for writing portable code if
new identifiers were defined for the two kinds of variable, such that any
compiler would only be allowed to define uwrap32_t if it could cause values
of that type to be promoted in essentially the same cases as they would on
a platform where INT_MAX was 2147483647, and implement unum32_t if it could
cause such values to be promoted to a larger integer type when performing
calculations upon them.  Some platforms could alias uwrap32_t to uint32_t,
and others could alias unum32_t likewise.  No platform could legitimately
alias both types to uint32_t, but (with suitable changes to the Standard)
a platform *could* legitimately define both types *if* it added support for
the necessary semantics.

The int-size-based behavior of "int32_t" needs to remain what it is to
allow both programs written for 32-bit systems where it has one meaning,
and programs written for 64-bit system where it has the other meaning, to
continue working.  That does not imply, however, that the Standard should
not define types whose behavior would be independent of the size of "int".

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

#71876

On 04.10.2015 19:49, James Kuyper wrote:
[...]
> In that sub-thread, Richard Heathfield correctly identified the common
> sub-set of C90, C99, and C2011 as the maximally portable version of C to
> use. However, if you're going to use that sub-set, I'd recommend
> compiling it with C2011, and only compiling it with C90 to confirm that
> the code is indeed within that common subset. There was very little
> additional discussion of the matter, other than an erroneous comment by
> David Kleinecke that was corrected by Keith Thompson.
>
> However, a key issue is - do you really need your code to be "maximally
> portable"? It's sort-of like shopping for computers - do you really need
> the most powerful available desktop computer? It's easy to say, but when
> you actually have to pay for it, it may make more sense to choose a less
> powerful system that is still powerful enough for your needs, but costs
> a whole lot less money.
> If you insist on "maximally portable", that means you'll never be able
> to use the nice features that were added in later versions of the
> standard. Is that a price you're willing to pay? If everyone took that
> same approach, no one would ever put any pressure on implementors to
> implement the new features, nor would they put any pressure on system
> administrators to install those updated implementations. That is, in my
> opinion, the main reason why C99 was implemented so slowly.
>
> Richard Heathfield has never seen any new feature that he considered
> sufficiently worthwhile to justify accepting the reduction in
> portability - the "never" in that statement make me suspect, that he's
> letting a powerful preference for maximal portability cloud his judgment
> of the value of those features.

Well, this is a specialized library, dealing with XML and Unicode only.

One of the goals is that (web) standards should be promoted, and having
something that works on "everything" goes hand-in-hand with that.

Another thing is that I assume C90 is simpler (has less features) than
the newer versions, and because of that is easier for a first project.

If I were to write some GUI-based application or something where for
example QT is one of the obvious choices, then basing my choices on
whatever they require is OK, so if QT requires C99 or C11, OK fine.

I agree that "never" is bombastic, but maybe it is easier to put up
a mental wall and not have to "grind over" which C version to choose
on a given project.

-Morten

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

#71914

"Morten W. Petersen" <morphex@gmail.com> writes:
[...]
> Another thing is that I assume C90 is simpler (has less features) than
> the newer versions, and because of that is easier for a first project.

It's true that the later standards have added more features.  That
doesn't necessarily mean that stringently avoiding those features makes
programming easier.

And in particular, C99 *dropped* some features of C90, specifically the
"implicit int" rule, which allowed calls to functions with no visible
declaration.  You recently ran into a problem because of that.

-- 
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]

#71921

On Sunday, October 4, 2015 at 8:09:21 PM UTC-5, Keith Thompson wrote:
> It's true that the later standards have added more features.  That
> doesn't necessarily mean that stringently avoiding those features makes
> programming easier.

It's also worth noting that throughout the 1990s, there were really two forms
of "Standard C": there was the set of behaviors that were officially
documented as C89/C90, but there was also a broader set of behaviors
which, while never acknowledged by the Standards Committee, were nonetheless
useful and supported by 99% of microcomputer C compilers.  If someone were
to transport back in time a compiler which performed the kind of
optimizations that have become fashionable lately, it would have been
considered broken, since it would not support the useful programming
language that microcomputer programmers were using.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web