Re: standard pragma's II

Discussion in 'C Programming' started by nmm1@cam.ac.uk, Oct 21, 2010.

  1. Guest

    In article <i9p6fr$408$-september.org>,
    James Kuyper <> wrote:
    >
    >As a point of Netiquette, it's considered polite to mention the fact
    >that you've changing which newsgroups a thread is being posted to.
    >Welcome to our new listeners in comp.lang.fortran!


    I was a little baffled, I agree.

    >The only comment I made about your cross-posting was to point out that
    >criticizing C as inferior to Fortran in a message posted to several
    >different C newsgroups is a bit ... confrontational. What you've just
    >told me doesn't make it any less so.


    That's a problem? :)

    >In any real-world program, even those which are primarily about number
    >crunching, there's always a fair amount of auxiliary code that has
    >nothing to do with floating point operations. For those who prefer C in
    >general, being able to get greater speed, accuracy and reliability with
    >floating point operations opens up the possibility of using C for both
    >parts of such code, avoiding the need to write anything in Fortran. This
    >argument will probably not be persuasive for Fortran partisans.


    If you think that Annex F or, indeed, IEEE 754, helps one iota
    with those aspects, then I am afraid that you have swallowed the
    propaganda, hook, line and sinker. In fact, C99 makes what was a
    bad situation immeasurably worse - and Annex F is NOT the only
    problem in this area.

    Heaven help me, this area of Fortran is pretty dangerous except in
    the hands of an expert - but this area of C is unsafe EVEN in the
    hands of an expert! If you think that you understand it, you don't;
    I understand it as well as anyone, and I know more undefined,
    ambiguous and inconsistent aspects than I know well-defined ones.
    And, yes, they show up in real programs on real systems.

    See: http://en.wikipedia.org/wiki/Dunning–Kruger_effect

    God help us all :-(


    Regards,
    Nick Maclaren.
     
    , Oct 21, 2010
    #1
    1. Advertising

  2. schrieb:

    >> In any real-world program, even those which are primarily about number
    >> crunching, there's always a fair amount of auxiliary code that has
    >> nothing to do with floating point operations. For those who prefer C in
    >> general, being able to get greater speed, accuracy and reliability with
    >> floating point operations opens up the possibility of using C for both
    >> parts of such code, avoiding the need to write anything in Fortran. This
    >> argument will probably not be persuasive for Fortran partisans.

    >
    > If you think that Annex F or, indeed, IEEE 754, helps one iota
    > with those aspects, then I am afraid that you have swallowed the
    > propaganda, hook, line and sinker. In fact, C99 makes what was a
    > bad situation immeasurably worse - and Annex F is NOT the only
    > problem in this area.
    >
    > Heaven help me, this area of Fortran is pretty dangerous except in
    > the hands of an expert - but this area of C is unsafe EVEN in the
    > hands of an expert! If you think that you understand it, you don't;
    > I understand it as well as anyone, and I know more undefined,
    > ambiguous and inconsistent aspects than I know well-defined ones.
    > And, yes, they show up in real programs on real systems.


    Care to enlighten me? I don't claim to understand it - except that
    you've to be pretty damn careful with floating point anyhow. So what do
    you think makes C, C99 in particular, more unsafe than FORTRAN? I don't
    get it.

    Greetings,

    Thomas
     
    Thomas Richter, Oct 21, 2010
    #2
    1. Advertising

  3. Guest

    In article <i9ptmq$793$>,
    Thomas Richter <-berlin.de> wrote:
    >
    >> No :-( There are at least the following major problems:

    >
    >I'm not in WG14, so I cannot say what the committee intended to say in
    >the standard.


    I was.

    >How do you want to specify what should happen if C99 code calls C90
    >code? Actually, even mixing code from different compilers is undefined,
    >so I wonder what you could reasonably expect? How is it with FORTRAN if
    >you link code compiled with different vendors - I wonder how that could
    >have a defined meaning?


    Most Fortran 66 code is valid Fortran 2003 code, and it has been
    essentially upwards compatible since Fortran 77. You wanted reasons
    to prefer Fortran - that's one. Oh, and C1X is going to be somewhat
    incompatible with C99, if it appears.

    >> 2) The specification is ambiguous and sometimes inconsistent,
    >> so it doesn't mean what even semi-experts think that it does. In
    >> some cases, such as the FP_CONTRACT and CX_LIMITED_RANGE, nobody
    >> knows what they mean (and that wasn't an accident).

    >
    >Why wasn't that an accident? Are you trolling? Or are you probably
    >willing to improve it? If you are a member of a national body in an ISO
    >committee, I suggest filing a defect report then?


    We did better - we tried to get it fixed before standardisation,
    but it was decided that the meaning should be left up to the vendors
    and standardised when they had reached consensus. No, I am not joking.

    >> 3) Calling ANY library function except <math.h>, <fenv.h> and
    >> <complex.h> can set the flags unpredictably - and that includes
    >> abs() and I/O. And they do :-( Ditto functions compiled without
    >> FENV_ACCESS ON - and you had better get the scope of that right.

    >
    >I wonder how ISO could define it? What does FORTRAN do here?


    Much better. It doesn't give all intrinsics liberty to trash the
    flags, and its scope is much easier to get right.

    >> 5) Setting the floating-point flags is a side-effect, so it is
    >> undefined behaviour if it happens twice without an intervening
    >> sequence point.

    >
    >Typical C thing - the order of what happens between sequence points is
    >not defined; for float this is, AFAIK, no longer the case. I would
    >believe this is deliberate because it allows the compiler to optimize.


    You are wrong. It's still undefined. And it's changing in C1X.

    >What about FORTRAN? Let's say I have a rather long mathematical formula.
    >What happens if one of the sub-expressions sets a floating point flag? I
    >don't seem to see a general solution to the problem. Unless you manually
    >break up the expression, and test flags after each sub-expression - but
    >that's not only unpractical. That makes the code completely unreadable,
    >and not maintainable. So, question, what do you do in FORTRAN?


    It's not undefined behaviour. The specification is usable, just.
    Read it and see.

    >> 6) Many parts of the text NOT in Annex F or shielded by other
    >> wording make no sense unless Annex F is in force (think copysign
    >> on a VAX, for example, or an IBM mainframe).

    >
    >Huh, sorry, I don't get your point.


    Clearly not. Some people use such systems. They will.

    >Again, what is the alternative and what would FORTRAN do?


    Look through the WG14 mail archives and read the Fortran standard.

    >In C++, you would have exceptions, though they are not used for such things.


    Don't even THINK of mixing exceptions and <fenv>.

    >> Don't blame me - I raised this in WG14 and both I and the UK voted
    >> "NO". My recommendation is:
    >>
    >> Annex F - just say "NO".

    >
    >"You" voted? (-: I guess, rather, your national body? I didn't know
    >individuals have a vote in an ISO committee?


    No. There are straw votes as well, and that's how I voted on the
    national body.

    >Anyhow, the most straightforward thing I can think about is file a
    >defect report and a draft corrigendum, and then let it go through the
    >ISO process. It is then the best thing to do.


    Don't be silly. I spent 10+ years on WG14, and am not going to
    waste any more time on it. You might care to inspect the minutes
    and see how many countries are currently active on it.


    Regards,
    Nick Maclaren.
     
    , Oct 21, 2010
    #3
  4. On Oct 21, 3:28 pm, wrote:
    > In article <i9ptmq$>,
    > Thomas Richter  <-berlin.de> wrote:


    <snip>

    > >How do you want to specify what should happen if C99 code calls C90
    > >code?


    <snip?

    > Most Fortran 66 code is valid Fortran 2003 code, and it has been
    > essentially upwards compatible since Fortran 77.



    As written this does not make sense to me. Is C90 code not valid C99
    code? What is the difference is saying that Fortran 66 code
    is valid Fortran 2003 code? What happens differently when
    Fortran 2003 code calls Fortran 66 code?
    Do you mean that there are things that are now defined
    in C99 that were not previously defined, or that mixing defined
    stuff with undefined stuff can cause problems or something else?

    - William Hughes
     
    William Hughes, Oct 21, 2010
    #4
  5. wrote:

    >> How do you want to specify what should happen if C99 code calls C90
    >> code? Actually, even mixing code from different compilers is undefined,
    >> so I wonder what you could reasonably expect? How is it with FORTRAN if
    >> you link code compiled with different vendors - I wonder how that could
    >> have a defined meaning?

    >
    > Most Fortran 66 code is valid Fortran 2003 code, and it has been
    > essentially upwards compatible since Fortran 77. You wanted reasons
    > to prefer Fortran - that's one. Oh, and C1X is going to be somewhat
    > incompatible with C99, if it appears.


    And so is FORTRAN 2003 code, I suppose. It is somewhat incompatible to
    FORTRAN 66. Why is the incompatibility between the FORTRAN dialects so
    minor, and the ones between C so major? Sorry, I don't understand.

    >>> 2) The specification is ambiguous and sometimes inconsistent,
    >>> so it doesn't mean what even semi-experts think that it does. In
    >>> some cases, such as the FP_CONTRACT and CX_LIMITED_RANGE, nobody
    >>> knows what they mean (and that wasn't an accident).

    >> Why wasn't that an accident? Are you trolling? Or are you probably
    >> willing to improve it? If you are a member of a national body in an ISO
    >> committee, I suggest filing a defect report then?

    >
    > We did better - we tried to get it fixed before standardisation,
    > but it was decided that the meaning should be left up to the vendors
    > and standardised when they had reached consensus. No, I am not joking.


    That's one option the committee can pick, namely to leave the
    implementations some freedoms. It is not that unusual. I do not know
    FORTAN enough whether there are corner cases that are intentionally
    undefined, but I would guess. I know (and worked on) a couple of other
    standards where this is the case for sure. You want to allow vendors to
    differentiate their products.

    >>> 3) Calling ANY library function except <math.h>, <fenv.h> and
    >>> <complex.h> can set the flags unpredictably - and that includes
    >>> abs() and I/O. And they do :-( Ditto functions compiled without
    >>> FENV_ACCESS ON - and you had better get the scope of that right.

    >> I wonder how ISO could define it? What does FORTRAN do here?

    >
    > Much better. It doesn't give all intrinsics liberty to trash the
    > flags, and its scope is much easier to get right.


    Again, you are very vague. Please specify "trash the flags". Why are,
    for example, I/O functions not allowed to perform floating point
    operations (it would make sense, for example, when printing floating
    point values to the console) and hence potentially modify the flags. And
    what is "much easier to get right". What do you mean? Why doesn't that
    happen in FORTRAN? Doesn't that mean that any implementation of WRITE
    must save the floating point flags when doing any type of FLOAT
    formatting with the FPU?

    Sorry, please be specific.

    >>> 5) Setting the floating-point flags is a side-effect, so it is
    >>> undefined behaviour if it happens twice without an intervening
    >>> sequence point.

    >> Typical C thing - the order of what happens between sequence points is
    >> not defined; for float this is, AFAIK, no longer the case. I would
    >> believe this is deliberate because it allows the compiler to optimize.

    >
    > You are wrong. It's still undefined. And it's changing in C1X.


    What is undefined?

    >> What about FORTRAN? Let's say I have a rather long mathematical formula.
    >> What happens if one of the sub-expressions sets a floating point flag? I
    >> don't seem to see a general solution to the problem. Unless you manually
    >> break up the expression, and test flags after each sub-expression - but
    >> that's not only unpractical. That makes the code completely unreadable,
    >> and not maintainable. So, question, what do you do in FORTRAN?

    >
    > It's not undefined behaviour. The specification is usable, just.
    > Read it and see.


    So please explain. I don't have the time to go through the entire
    FORTRAN spec, I've also other things to do.

    >>> 6) Many parts of the text NOT in Annex F or shielded by other
    >>> wording make no sense unless Annex F is in force (think copysign
    >>> on a VAX, for example, or an IBM mainframe).

    >> Huh, sorry, I don't get your point.

    >
    > Clearly not. Some people use such systems. They will.


    No. Please explain the point. I do not know what the Annex states, so
    what is your point?

    I'm not arguing. I'm only trying to follow you.

    >> Again, what is the alternative and what would FORTRAN do?

    >
    > Look through the WG14 mail archives and read the Fortran standard.


    Thanks, no. Can't you be more specific?

    >> In C++, you would have exceptions, though they are not used for such things.

    >
    > Don't even THINK of mixing exceptions and <fenv>.


    I do not attempt to. We're currently talking about C.

    >>> Don't blame me - I raised this in WG14 and both I and the UK voted
    >>> "NO". My recommendation is:
    >>>
    >>> Annex F - just say "NO".

    >> "You" voted? (-: I guess, rather, your national body? I didn't know
    >> individuals have a vote in an ISO committee?

    >
    > No. There are straw votes as well, and that's how I voted on the
    > national body.


    Ah, so it *is* the same in WG14 as it is in SC29WG01.

    >> Anyhow, the most straightforward thing I can think about is file a
    >> defect report and a draft corrigendum, and then let it go through the
    >> ISO process. It is then the best thing to do.

    >
    > Don't be silly. I spent 10+ years on WG14, and am not going to
    > waste any more time on it. You might care to inspect the minutes
    > and see how many countries are currently active on it.


    I don't know. How many are? I'm not in WG14, I don't think I have access
    to the minutes.

    And probably there is a reason why the NBs voted as they did. Without
    having an insight into the internal discussion, I cannot really judge. I
    haven't heart the opposite side.

    For me it rather seems that you have a grudge on some members of WG14,
    but that's probably an entirely different topic and should not be mixed
    with language features. I do not require numerics often enough to really
    judge which defects C might have in this area.

    So long,
    Thomas
     
    Thomas Richter, Oct 21, 2010
    #5
  6. Guest

    In article <>,
    William Hughes <> wrote:
    >
    >>=A0C99 is incompatible with C90 in several ways,
    >> some of which are important, both changing the meaning of valid
    >> programs and making them undefined.

    >
    >Some examples would be nice. Is this directly related to floating
    >point?


    Eh? Have people forgotten THAT fast? Here are a few of the more
    problematic:

    Things like size_t can now be longer than unsigned long,
    which caused 14 out of 24 widely-used programs that I looked at
    to break.
    I mentioned the errno change, which can and has cause programs
    to fail.
    Effective types change the semantics that are guaranteed, in
    ways that are ill-defined, and that has caused failure, too.
    There were reserved word and format descriptor changes of
    forms that C90 said would not happen, also causing programs to
    fail.
    You can find more if you search on the net.

    Why do you think that so many widely-used interfaces and libraries
    still explicitly specify C90?


    Anyway, it's not my job to educate the world, so I shan't continue.


    Regards,
    Nick Maclaren.
     
    , Oct 22, 2010
    #6
  7. Ian Collins Guest

    On 10/22/10 12:14 PM, wrote:
    > In article<>,
    > William Hughes<> wrote:
    >>
    >>> =A0C99 is incompatible with C90 in several ways,
    >>> some of which are important, both changing the meaning of valid
    >>> programs and making them undefined.

    >>
    >> Some examples would be nice. Is this directly related to floating
    >> point?

    >
    > Eh? Have people forgotten THAT fast? Here are a few of the more
    > problematic:
    >
    > Things like size_t can now be longer than unsigned long,
    > which caused 14 out of 24 widely-used programs that I looked at
    > to break.


    Probably because they assumed size_t was unsigned long, rather than
    using it as is.

    This kind of problem tends to happen when porting code from 32 to 64
    bit, where size_t is less of a problem than conversion between int and
    long int.

    > I mentioned the errno change, which can and has cause programs
    > to fail.


    I don't think I've ever come across that one, what ever it is.

    > Effective types change the semantics that are guaranteed, in
    > ways that are ill-defined, and that has caused failure, too.


    Eh?

    > There were reserved word and format descriptor changes of
    > forms that C90 said would not happen, also causing programs to
    > fail.


    Fail to compile maybe, but not fail at runtime. The are lots of C99
    changes that can cause C90 code to fail to compile (missing prototypes
    for one). These are generally good.

    > You can find more if you search on the net.
    >
    > Why do you think that so many widely-used interfaces and libraries
    > still explicitly specify C90?


    No one's bothered to update them. POSIX certainly uses C99.

    --
    Ian Collins
     
    Ian Collins, Oct 22, 2010
    #7
  8. Ian Collins <> writes:
    > On 10/22/10 12:14 PM, wrote:
    >> In article<>,
    >> William Hughes<> wrote:
    >>>
    >>>> =A0C99 is incompatible with C90 in several ways,
    >>>> some of which are important, both changing the meaning of valid
    >>>> programs and making them undefined.
    >>>
    >>> Some examples would be nice. Is this directly related to floating
    >>> point?

    >>
    >> Eh? Have people forgotten THAT fast? Here are a few of the more
    >> problematic:
    >>
    >> Things like size_t can now be longer than unsigned long,
    >> which caused 14 out of 24 widely-used programs that I looked at
    >> to break.

    >
    > Probably because they assumed size_t was unsigned long, rather than
    > using it as is.


    Or because they assumed (as C90 implicitly guaranteed) that size_t is no
    bigger than unsigned long. For example:

    size_t s = /* ... */;
    printf("s = %lu\n", (unsigned long)s);

    On the other hand, this fails, not if size_t is wider than unsigned
    long, but only if the value of s actually exceeds ULONG_MAX.

    C99 provides "%zu", but of course that can't be used in C90.

    [...]

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Oct 22, 2010
    #8
  9. Ian Collins Guest

    On 10/22/10 01:00 PM, Keith Thompson wrote:
    > Ian Collins<> writes:
    >> On 10/22/10 12:14 PM, wrote:
    >>> In article<>,
    >>> William Hughes<> wrote:
    >>>>
    >>>>> =A0C99 is incompatible with C90 in several ways,
    >>>>> some of which are important, both changing the meaning of valid
    >>>>> programs and making them undefined.
    >>>>
    >>>> Some examples would be nice. Is this directly related to floating
    >>>> point?
    >>>
    >>> Eh? Have people forgotten THAT fast? Here are a few of the more
    >>> problematic:
    >>>
    >>> Things like size_t can now be longer than unsigned long,
    >>> which caused 14 out of 24 widely-used programs that I looked at
    >>> to break.

    >>
    >> Probably because they assumed size_t was unsigned long, rather than
    >> using it as is.

    >
    > Or because they assumed (as C90 implicitly guaranteed) that size_t is no
    > bigger than unsigned long. For example:
    >
    > size_t s = /* ... */;
    > printf("s = %lu\n", (unsigned long)s);
    >
    > On the other hand, this fails, not if size_t is wider than unsigned
    > long, but only if the value of s actually exceeds ULONG_MAX.


    Which is why I said "This kind of problem tends to happen when porting
    code from 32 to 64 bit". It won't happen if the memory model does not
    change, or the system uses LP64.

    One could argue not using LP64 for 64 bit mode breaks the code, not C99!

    --
    Ian Collins
     
    Ian Collins, Oct 22, 2010
    #9
  10. James Kuyper Guest

    On 10/21/2010 10:08 AM, wrote:
    > In article<i9p6fr$408$-september.org>,
    > James Kuyper<> wrote:

    ....
    >> In any real-world program, even those which are primarily about number
    >> crunching, there's always a fair amount of auxiliary code that has
    >> nothing to do with floating point operations. For those who prefer C in
    >> general, being able to get greater speed, accuracy and reliability with
    >> floating point operations opens up the possibility of using C for both
    >> parts of such code, avoiding the need to write anything in Fortran. This
    >> argument will probably not be persuasive for Fortran partisans.

    >
    > If you think that Annex F or, indeed, IEEE 754, helps one iota
    > with those aspects, then I am afraid that you have swallowed the
    > propaganda, hook, line and sinker. In fact, C99 makes what was a
    > bad situation immeasurably worse - and Annex F is NOT the only
    > problem in this area.


    I've seen you point out many small flaws in C99 (if IEEE 754 doesn't
    help either, I'd have expected you point out the flaws in IEEE 754, as
    well, but you don't seem to have done so). What I have not seen you do
    is point out any flaws serious enough to justify the claim made above.
    C99 provides new guarantees that a programmer could, in principle rely
    on; such as the behavior of various code constructs when
    __STDC_IEC_559__ is predefined. These are guarantees about the behavior
    in circumstance where C90 had no guarantees at all. Those guarantees
    might have been rendered nearly useless by the problems you've described
    (though I think that would be overstating the case). But how in the
    world could even the most seriously flawed guarantee make things worse
    than having no guarantee at all? If it's that seriously flawed, people
    will quickly learn not to rely on it, in which case they're no worse off
    then they were without the guarantee.

    Similarly, C99 provides dozens of new tools for working with floating
    point numbers, such as isnan(), fpclassify(), fma(), and fenv(), to name
    just a few chosen at random. Those tools allow you to do portably things
    that could not be done portably in C90. No matter how serious the flaws
    in those tools (and I'm quite willing to believe that they might have
    serious flaws), how can having those tools available make things worse
    than if they were not available at all? At the very worst, you can
    simply choose not to use them, in which case you're no worse off than
    you were with C90.

    > Heaven help me, this area of Fortran is pretty dangerous except in
    > the hands of an expert - but this area of C is unsafe EVEN in the
    > hands of an expert! If you think that you understand it, you don't;
    > I understand it as well as anyone, and I know more undefined,
    > ambiguous and inconsistent aspects than I know well-defined ones.
    > And, yes, they show up in real programs on real systems.


    Is any aspect of C99 more undefined, more ambiguous, and more
    inconsistent than the corresponding parts of C90? That doesn't seem to
    be the case from the examples you've provided elsewhere in this thread.
     
    James Kuyper, Oct 22, 2010
    #10
  11. James Kuyper Guest

    On 10/21/2010 07:14 PM, wrote:
    > In article<>,
    > William Hughes<> wrote:
    >>
    >>> =A0C99 is incompatible with C90 in several ways,
    >>> some of which are important, both changing the meaning of valid
    >>> programs and making them undefined.

    >>
    >> Some examples would be nice. Is this directly related to floating
    >> point?

    >
    > Eh? Have people forgotten THAT fast? Here are a few of the more
    > problematic:
    >
    > Things like size_t can now be longer than unsigned long,
    > which caused 14 out of 24 widely-used programs that I looked at
    > to break.
    > I mentioned the errno change, which can and has cause programs
    > to fail.
    > Effective types change the semantics that are guaranteed, in
    > ways that are ill-defined, and that has caused failure, too.
    > There were reserved word and format descriptor changes of
    > forms that C90 said would not happen, also causing programs to
    > fail.



    You said that there were some important incompatibilities; as far as I
    can see, all of the incompatibilities you've listed so far, combined,
    add up to no more than an annoyance. For better or worse, I've had to
    deal with problems at least that bad with virtually every piece of
    software I've ever used, whenever it undergoes a major version number
    change.
     
    James Kuyper, Oct 22, 2010
    #11
  12. In comp.lang.fortran Keith Thompson <> wrote:
    (snip)

    > Or because they assumed (as C90 implicitly guaranteed) that size_t is no
    > bigger than unsigned long. For example:


    > size_t s = /* ... */;
    > printf("s = %lu\n", (unsigned long)s);


    > On the other hand, this fails, not if size_t is wider than unsigned
    > long, but only if the value of s actually exceeds ULONG_MAX.


    It happens even on 32 bit systems. I have had programs (closed
    source, so I don't know that they were in C) fail to install,
    claiming either not enough disk space or virtual memory when
    the actual space was between 2GB and 4GB, and way more than
    was required. Yes, way too many programs do signed arithmetic
    when determining available space.

    In on case, I ran enough other programs to get free VM
    below 2GB and then it worked.

    -- glen
     
    glen herrmannsfeldt, Oct 22, 2010
    #12
  13. Ian Collins Guest

    On 10/22/10 04:30 PM, glen herrmannsfeldt wrote:
    > In comp.lang.fortran Keith Thompson<> wrote:
    > (snip)
    >
    >> Or because they assumed (as C90 implicitly guaranteed) that size_t is no
    >> bigger than unsigned long. For example:

    >
    >> size_t s = /* ... */;
    >> printf("s = %lu\n", (unsigned long)s);

    >
    >> On the other hand, this fails, not if size_t is wider than unsigned
    >> long, but only if the value of s actually exceeds ULONG_MAX.

    >
    > It happens even on 32 bit systems. I have had programs (closed
    > source, so I don't know that they were in C) fail to install,
    > claiming either not enough disk space or virtual memory when
    > the actual space was between 2GB and 4GB, and way more than
    > was required. Yes, way too many programs do signed arithmetic
    > when determining available space.
    >
    > In on case, I ran enough other programs to get free VM
    > below 2GB and then it worked.


    That implies they are using int or long, rather than size_t (or unsigned
    long).

    --
    Ian Collins
     
    Ian Collins, Oct 22, 2010
    #13
  14. Tim Prince Guest

    On 10/21/2010 5:00 PM, Keith Thompson wrote:
    > Ian Collins<> writes:
    >> On 10/22/10 12:14 PM, wrote:


    >>>
    >>> Eh? Have people forgotten THAT fast? Here are a few of the more
    >>> problematic:
    >>>
    >>> Things like size_t can now be longer than unsigned long,
    >>> which caused 14 out of 24 widely-used programs that I looked at
    >>> to break.

    >>
    >> Probably because they assumed size_t was unsigned long, rather than
    >> using it as is.

    >
    > Or because they assumed (as C90 implicitly guaranteed) that size_t is no
    > bigger than unsigned long. For example:


    Guess which major compiler has size_t bigger than long. But that can't
    be blamed on C99; this is about the only C99 "feature" they have.
    My first customer on my present job, after several months work, informed
    me that size_t bigger than int (long not used) was a deal breaker.
    Exceptions raised in Fortran had to be caught by C++.

    We're about to see extended C and C++ compilers introducing new pragmas
    and namespaces hoping to compensate for the lack of acceptance of C99
    restrict qualifier, which does little more than support optimizations
    which Fortran supported from f66 on.

    Working with customers who forbid anything other than f77 plus old
    extensions and lowest common denominator C is a relative relief, even
    when they sneak C++ into C source files, plus occasional syntax guarded
    by HAVE_F90 conditional compilation. No, the applications won't build
    with any f77 compiler, due to some of the pre-f90 extensions needed.


    --
    Tim Prince
     
    Tim Prince, Oct 22, 2010
    #14
  15. Juergen Ilse Guest

    Hallo,

    In de.comp.lang.c Keith Thompson <> wrote:
    > Ian Collins <> writes:
    >> On 10/22/10 12:14 PM, wrote:
    >>> In article<>,
    >>> William Hughes<> wrote:
    >>>>> =A0C99 is incompatible with C90 in several ways,
    >>>>> some of which are important, both changing the meaning of valid
    >>>>> programs and making them undefined.
    >>>> Some examples would be nice. Is this directly related to floating
    >>>> point?
    >>> Eh? Have people forgotten THAT fast? Here are a few of the more
    >>> problematic:
    >>> Things like size_t can now be longer than unsigned long,
    >>> which caused 14 out of 24 widely-used programs that I looked at
    >>> to break.

    >> Probably because they assumed size_t was unsigned long, rather than
    >> using it as is.

    > Or because they assumed (as C90 implicitly guaranteed) that size_t is no
    > bigger than unsigned long. For example:
    >
    > size_t s = /* ... */;
    > printf("s = %lu\n", (unsigned long)s);
    >
    > On the other hand, this fails, not if size_t is wider than unsigned
    > long, but only if the value of s actually exceeds ULONG_MAX.


    So the problem is, that the change allows objects larger than ULONG_MAX?
    In C90, a program, which tries to use values greater than ULONG_MAX will
    unconditionally fail, because that value can't be represanted in the
    datatype size_t. All C90 programs, that will *not* fail because of that,
    will also *not* fail in C99, where size_t maybe bigger in size than unsigned
    long. So where is the problem? That there maybe C99 programs that are not
    C90 compatible? Sorry, in my eyes this is not a problem ...

    > C99 provides "%zu", but of course that can't be used in C90.


    In all situations, that are without any problem in C90, there is also no
    problem with size_t in C99. In all other cases, the bug with size_t is
    in the C90 Code.

    bye,
    Juergen Ilse ()
    --
    Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
    nicht mehr und nicht weniger ...
     
    Juergen Ilse, Oct 22, 2010
    #15
  16. On 22.10.10 11:06, Juergen Ilse wrote:
    > Hallo,
    >
    > In de.comp.lang.c Keith Thompson <> wrote:
    >> Ian Collins <> writes:
    >>> On 10/22/10 12:14 PM, wrote:
    >>>>
    >>>> Eh? Have people forgotten THAT fast? Here are a few of the more
    >>>> problematic:
    >>>> Things like size_t can now be longer than unsigned long,
    >>>> which caused 14 out of 24 widely-used programs that I looked at
    >>>> to break.


    > That there maybe C99 programs that are not
    > C90 compatible? Sorry, in my eyes this is not a problem ...


    Is "14 out of 24 widely-used programs" (58 %) still too small
    a fraction to recognize that there might be a real issue?

    Cost could be associated with upgrading everything to C99,
    should this bee needed.

    Doesn't take standard exegesis to see all this, I'd think?


    --
    Georg Bauhaus
     
    Georg Bauhaus, Oct 22, 2010
    #16
  17. Georg Bauhaus <> writes:
    > On 22.10.10 11:06, Juergen Ilse wrote:
    >> Hallo,
    >>
    >> In de.comp.lang.c Keith Thompson <> wrote:
    >>> Ian Collins <> writes:
    >>>> On 10/22/10 12:14 PM, wrote:
    >>>>>
    >>>>> Eh? Have people forgotten THAT fast? Here are a few of the more
    >>>>> problematic:
    >>>>> Things like size_t can now be longer than unsigned long,
    >>>>> which caused 14 out of 24 widely-used programs that I looked at
    >>>>> to break.

    >
    >> That there maybe C99 programs that are not
    >> C90 compatible? Sorry, in my eyes this is not a problem ...

    >
    > Is "14 out of 24 widely-used programs" (58 %) still too small
    > a fraction to recognize that there might be a real issue?


    According to a naive count, the computer I'm using to write has at
    least 2378 different programs installed. The actual number is
    certainly higher. Assuming that I happen to be using all of these '24
    widely used programs' (whatever they actually happen to be), about 1%
    of the 'programs' on my system have been examined and it has been
    claimed that about 0.59% would be 'broken', presumably, as seen from a
    rather theoretical standpoint. So what?
     
    Rainer Weikusat, Oct 22, 2010
    #17
  18. On Oct 21, 9:00 pm, Keith Thompson <> wrote:
    > because they assumed (as C90 implicitly guaranteed) that size_t is no
    > bigger than unsigned long.



    I can see that the guarantee holds in terms of range,
    but not in terms of size. Why couldn't (on a rather perverese
    implementation)
    size_t have samller range but larger size than unsigned long.

    >
    >     size_t s = /* ... */;
    >     printf("s = %lu\n", (unsigned long)s);


    More likely the error would be the form of

    size_t s = /* ... */;
    printf("s = %lu\n",s);

    Note that this would work on almost all implementations, and
    work silently on most. It might even "work" on an implementation
    where size_t was bigger than unsigned long.


    A more serious problem would be an attempt to store size_t
    in space sufficient for unsigned int. If there was
    indeed a space guarantee, this would not be a C90 error
    but would break under C99. (Here there are obvious
    parallels to storing time_t in 32 bits).

    - William Hughes
     
    William Hughes, Oct 22, 2010
    #18
  19. Tim Prince Guest

    On 10/22/2010 6:04 AM, William Hughes wrote:

    >
    > A more serious problem would be an attempt to store size_t
    > in space sufficient for unsigned int. If there was
    > indeed a space guarantee, this would not be a C90 error
    > but would break under C99.


    Exactly the practice which was a major factor in several months of my
    work with a customer being discarded, except that the (well-known)
    compiler was not C99.


    --
    Tim Prince
     
    Tim Prince, Oct 22, 2010
    #19
  20. On 22.10.10 15:00, Rainer Weikusat wrote:

    >> Is "14 out of 24 widely-used programs" (58 %) still too small
    >> a fraction to recognize that there might be a real issue?

    >
    > According to a naive count, [...] about 1%
    > of the 'programs' on my system have been examined and it has been
    > claimed that about 0.59% would be 'broken' [...]. So what?


    An assessment of what is or is not broken may start from counts
    of things, but will also assign importance(*) of the presumably
    broken programs. Standardization, then, becomes political in that
    decisions select alternative paragraphs: the resulting standard
    may affect program production, its cost, including the cost of making
    compilers (the vendors are part of it). When a C90-library + C99-program
    is more troublesome than, say, a Fortran 77 library + a Fortran 2003
    program, I'd assume some justification may be needed here and there.

    To illustrate the economic/political aspect, if some change
    in CXX -> CYY might mean that widely-used implementations
    of TCP will break, the standardization work will be affected
    by this effect, I'm sure, even when just two implementations
    will be at risk. Will the change pass?

    So that's what.

    __
    (*) Widely-used is one part of the definition of "important".

    --
    Georg Bauhaus
     
    Georg Bauhaus, Oct 22, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rick

    #pragma once in ISO standard yet?

    Rick, Dec 12, 2007, in forum: C Programming
    Replies:
    33
    Views:
    1,250
    CBFalconer
    Dec 15, 2007
  2. Rick
    Replies:
    4
    Views:
    442
    Pete Becker
    Dec 13, 2007
  3. Mr. Buffoon

    Re: standard pragma's?

    Mr. Buffoon, Oct 6, 2010, in forum: C Programming
    Replies:
    43
    Views:
    1,435
    Michael Schumacher
    Oct 12, 2010
  4. Lew Pitcher

    Re: standard pragma's?

    Lew Pitcher, Oct 6, 2010, in forum: C Programming
    Replies:
    0
    Views:
    448
    Lew Pitcher
    Oct 6, 2010
  5. Joachim Schmitz

    Re: standard pragma's II

    Joachim Schmitz, Oct 13, 2010, in forum: C Programming
    Replies:
    57
    Views:
    1,371
    Keith Thompson
    Nov 9, 2010
Loading...

Share This Page