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

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

warning: string length greater than '509'

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

Contents

  warning: string length greater than '509' JohnF <john@please.see.sig.for.email.com> - 2011-12-23 10:01 +0000
    Re: warning: string length greater than '509' jacob navia <jacob@spamsink.net> - 2011-12-23 11:19 +0100
    Re: warning: string length greater than '509' pete <pfiland@mindspring.com> - 2011-12-23 05:49 -0500
      Re: warning: string length greater than '509' jacob navia <jacob@spamsink.net> - 2011-12-23 13:52 +0100
        Re: warning: string length greater than '509' Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-28 03:27 -0800
          Re: warning: string length greater than '509' James Kuyper <jameskuyper@verizon.net> - 2011-12-28 08:16 -0500
          Re: warning: string length greater than '509' Keith Thompson <kst-u@mib.org> - 2011-12-28 13:04 -0800
            Re: warning: string length greater than '509' Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-25 16:47 -0800
      Re: warning: string length greater than '509' JohnF <john@please.see.sig.for.email.com> - 2011-12-23 13:04 +0000
        Re: warning: string length greater than '509' Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-12-23 09:36 -0500
    Re: warning: string length greater than '509' Robert Wessel <robertwessel2@yahoo.com> - 2011-12-23 04:59 -0600
      Re: warning: string length greater than '509' JohnF <john@please.see.sig.for.email.com> - 2011-12-23 12:41 +0000
        Re: warning: string length greater than '509' jt@toerring.de (Jens Thoms Toerring) - 2011-12-23 13:50 +0000
        Re: warning: string length greater than '509' James Kuyper <jameskuyper@verizon.net> - 2011-12-23 09:14 -0500
        Re: warning: string length greater than '509' Robert Wessel <robertwessel2@yahoo.com> - 2011-12-23 12:27 -0600
          Re: warning: string length greater than '509' Seebs <usenet-nospam@seebs.net> - 2011-12-23 19:04 +0000
            Re: warning: string length greater than '509' Robert Wessel <robertwessel2@yahoo.com> - 2011-12-23 16:11 -0600
          New C standard (was Re: warning: string length greater than '509') Keith Thompson <kst-u@mib.org> - 2011-12-23 12:21 -0800
            Re: New C standard (was Re: warning: string length greater than '509') Jens Gustedt <jens.gustedt@loria.fr> - 2011-12-23 22:54 +0100
            Re: New C standard (was Re: warning: string length greater than '509') Robert Wessel <robertwessel2@yahoo.com> - 2011-12-23 16:27 -0600
            Re: New C standard (was Re: warning: string length greater than '509') rudolf <r.thered@gmail.com> - 2011-12-23 15:36 -0800
            new edition of Harbison and Steele? Patrick Scheible <kkt@zipcon.net> - 2011-12-26 18:57 -0800
              Re: new edition of Harbison and Steele? Keith Thompson <kst-u@mib.org> - 2011-12-27 02:48 -0800
                Re: new edition of Harbison and Steele? Patrick Scheible <kkt@zipcon.net> - 2011-12-27 11:45 -0800
          Re: warning: string length greater than '509' JohnF <john@please.see.sig.for.email.com> - 2011-12-24 05:42 +0000
            Re: warning: string length greater than '509' Robert Wessel <robertwessel2@yahoo.com> - 2011-12-24 00:47 -0600
              Re: warning: string length greater than '509' JohnF <john@please.see.sig.for.email.com> - 2011-12-24 08:51 +0000
    Re: warning: string length greater than '509' Stars and Midnight China Blue <chine.bleu@yahoo.com> - 2011-12-23 03:34 -0800
    Re: warning: string length greater than '509' Kaz Kylheku <kaz@kylheku.com> - 2011-12-23 16:48 +0000

Page 1 of 2  [1] 2  Next page →

#14901 — warning: string length greater than '509'

I like to compile (linux/gcc) with -pedantic -Wall
and neaten up the code to eliminate all warnings.
But the following code emits the message
  warning: string length '1008' is greater than the
  length '509' ISO C90 compilers are required to support
and I can't see a neat way around it. The offending
statement is,
static  char latexwrapper[16384] =
        "\\documentclass[10pt]{article}\n"
        "\\usepackage[latin1]{inputenc}\n"
        "\\usepackage{amsmath}\n"
        "\\usepackage{amsfonts}\n"
        "...lots-more-junk...";
I could obviously break it up into several smaller
initializations and strcat() them all at runtime,
but that (in my opinion) isn't what I meant by "neat".
It works as is, which is how I'd leave it if that's
(strcat() several smaller strings at runtime) is the
only solution. But a straightforward way around the
warning would be even nicer.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [next] | [standalone]

#14902

Le 23/12/11 11:01, JohnF a écrit :
> I like to compile (linux/gcc) with -pedantic -Wall
> and neaten up the code to eliminate all warnings.
> But the following code emits the message
>    warning: string length '1008' is greater than the
>    length '509' ISO C90 compilers are required to support
> and I can't see a neat way around it. The offending
> statement is,
> static  char latexwrapper[16384] =
>          "\\documentclass[10pt]{article}\n"
>          "\\usepackage[latin1]{inputenc}\n"
>          "\\usepackage{amsmath}\n"
>          "\\usepackage{amsfonts}\n"
>          "...lots-more-junk...";
> I could obviously break it up into several smaller
> initializations and strcat() them all at runtime,
> but that (in my opinion) isn't what I meant by "neat".
> It works as is, which is how I'd leave it if that's
> (strcat() several smaller strings at runtime) is the
> only solution. But a straightforward way around the
> warning would be even nicer.

You are using gcc in an obsolete mode. The minimum
string length any compiler is REQUIRED to support is
4095 characters as specified in the C99 standard
(5.2.4.1)

The compiler is warning that you have exceeded the
limit of specified in the 1989 version of the standard.

Anyway, you have exceeded the C99 limit too, so the compiler
is right to "complain" in PEDANTIC mode.

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

#14903

JohnF wrote:
> 
> I like to compile (linux/gcc) with -pedantic -Wall
> and neaten up the code to eliminate all warnings.
> But the following code emits the message
>   warning: string length '1008' is greater than the
>   length '509' ISO C90 compilers are required to support
> and I can't see a neat way around it. The offending
> statement is,
> static  char latexwrapper[16384] =
>         "\\documentclass[10pt]{article}\n"
>         "\\usepackage[latin1]{inputenc}\n"
>         "\\usepackage{amsmath}\n"
>         "\\usepackage{amsfonts}\n"
>         "...lots-more-junk...";
> I could obviously break it up into several smaller
> initializations and strcat() them all at runtime,
> but that (in my opinion) isn't what I meant by "neat".
> It works as is, which is how I'd leave it if that's
> (strcat() several smaller strings at runtime) is the
> only solution. But a straightforward way around the
> warning would be even nicer.

Using strcat might only have the effect of avoiding the warning,
while retaining the portability problem,
which may or may not be acceptable to you.

If you actually want the portability that the warning is reffering to,
and if latexwrapper is supposed to be constant,
and all that you are ever going to do with it, 
is to write it to a file 
or to files such as standard output for example,
then you might try something like
   static  char latexwrapper[33][510] = /* {"",""} */
and use fputs in a loop to do write operations
on 33 strings of acceptable length.

The number (509) appears more than once 
in the C90 standard 
in a related context.

ISO/IEC 9899: 1990

7.9.6 Formatted input/output functions
7.9.6.1 The fprintf function

Environmental limit
    The minimum value for the maximum number of characters
    produced by any single conversion shall be 509.

G.2 Undefined behavior
    — A single conversion by the fprintf function 
      produces more than 509 characters of output (7.9.6.1).

-- 
pete

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

#14911

Le 23/12/11 11:49, pete a écrit :

> The number (509) appears more than once
> in the C90 standard
> in a related context.
>
> ISO/IEC 9899: 1990

That is not the C standard, it has been obsoleted by the standard of
1999 where the enviromental limits have been increased to more
reasonable values.

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

#15093

On Dec 23, 12:52 pm, jacob navia <ja...@spamsink.net> wrote:
> Le 23/12/11 11:49, pete a écrit :

> > The number (509) appears more than once
> > in the C90 standard
> > in a related context.
>
> > ISO/IEC 9899: 1990
>
> That is not the C standard, it has been obsoleted by the standard of
> 1999 where the enviromental limits have been increased to more
> reasonable values.

C89/90 is still the most portable standard

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

#15108

On 12/28/2011 06:27 AM, Nick Keighley wrote:
> On Dec 23, 12:52�pm, jacob navia <ja...@spamsink.net> wrote:
>> Le 23/12/11 11:49, pete a �crit :
> 
>>> The number (509) appears more than once
>>> in the C90 standard
>>> in a related context.
>>
>>> ISO/IEC 9899: 1990
>>
>> That is not the C standard, it has been obsoleted by the standard of
>> 1999 where the enviromental limits have been increased to more
>> reasonable values.
> 
> C89/90 is still the most portable standard

Do you still keep the length of your identifiers within the
corresponding environmental limits from C90?
-- 
James Kuyper

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

#15132

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
> On Dec 23, 12:52 pm, jacob navia <ja...@spamsink.net> wrote:
>> Le 23/12/11 11:49, pete a écrit :
>> > The number (509) appears more than once
>> > in the C90 standard
>> > in a related context.
>>
>> > ISO/IEC 9899: 1990
>>
>> That is not the C standard, it has been obsoleted by the standard of
>> 1999 where the enviromental limits have been increased to more
>> reasonable values.
>
> C89/90 is still the most portable standard

And with the recent publication of the ISO C 2011 standard, C99 is now
just as obsolete as C89/C90.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#16246

Keith Thompson <kst-u@mib.org> writes:

> Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
>> On Dec 23, 12:52 pm, jacob navia <ja...@spamsink.net> wrote:
>>> Le 23/12/11 11:49, pete a @C3{A9}crit :
>>> > The number (509) appears more than once
>>> > in the C90 standard
>>> > in a related context.
>>>
>>> > ISO/IEC 9899: 1990
>>>
>>> That is not the C standard, it has been obsoleted by the standard of
>>> 1999 where the enviromental limits have been increased to more
>>> reasonable values.
>>
>> C89/90 is still the most portable standard
>
> And with the recent publication of the ISO C 2011 standard, C99 is now
> just as obsolete as C89/C90.

Well, maybe not quite _just_ as obsolete.

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

#14913

pete <pfiland@mindspring.com> wrote:
> JohnF wrote:
>> 
>> warning: string length '1008' is greater than the
>> length '509'
>> static  char latexwrapper[16384] =
>>         "\\documentclass[10pt]{article}\n"
>>         "\\usepackage[latin1]{inputenc}\n"
>>         "\\usepackage{amsmath}\n"
>>         "\\usepackage{amsfonts}\n"
>>         "...lots-more-junk...";
>
> if latexwrapper is supposed to be constant,

Nope, it contains embedded keywords like %%expression%%
(always something delimited by %%...%%) that later gets
substituted with the user's input expression, and various
other substitutions like font size and similar
gobbledy-gook. (And, yeah, I make sure the 16384 allocation
doesn't overflow.)

>   static  char latexwrapper[33][510] = /* {"",""} */

One big long contiguous string is what's really required
to neatly solve the problem. An array of shorter ones
represents the situation in a way that requires more
lines of code in several different places. (But I appreciate
how you calculated [33] to match my 16384 total:)

> The number (509) appears more than once in the C90 standard 
Yes, it's a very nice number, indeed.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

#14916

On 12/23/2011 8:04 AM, JohnF wrote:
> pete<pfiland@mindspring.com>  wrote:
>> JohnF wrote:
>>>
>>> warning: string length '1008' is greater than the
>>> length '509'
>>> static  char latexwrapper[16384] =
>>>          "\\documentclass[10pt]{article}\n"
>>>          "\\usepackage[latin1]{inputenc}\n"
>>>          "\\usepackage{amsmath}\n"
>>>          "\\usepackage{amsfonts}\n"
>>>          "...lots-more-junk...";
>>
>> if latexwrapper is supposed to be constant,
>
> Nope, it contains embedded keywords like %%expression%%
> (always something delimited by %%...%%) that later gets
> substituted with the user's input expression, and various
> other substitutions like font size and similar
> gobbledy-gook. (And, yeah, I make sure the 16384 allocation
> doesn't overflow.)

     Replacement in situ?  Yukk!  Not only does it pose a significant
risk of buffer overflow, but it also means that a string of this kind
is not reusable: Process it once, and all those %%foo%% bits have
vanished.  And just to heighten the sense of outrage, the substitution
probably takes quadratic time ...

     If you're still interested in staying within the 509-character
limit (thus ensuring that resource-constrained compilers won't choke
on your source code), I'd suggest chopping the big blob of text into
chunks of convenient size.  Before processing, you can allocate a big
buffer and strcpy/strcat the little strings into it, then use the big
buffer exactly as you're now using the latexwrapper[] array.  (This
solves the reusability problem, by the way, although you still face the
buffer overflow and quadratic time issues.)

     Others have mentioned the possibility of reading this block of text
from a file instead of burying it in the program code.  Although that
gives up some degree of self-containment, it brings some advantages.
For example, if you decide you'd like 12-point instead of 10-point
titles you can just edit the external file without rebuilding the
program from source -- if you're an end user, you might not even have
access to the source.  Don't reject the idea out-of-hand.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#14904

On Fri, 23 Dec 2011 10:01:55 +0000 (UTC), JohnF
<john@please.see.sig.for.email.com> wrote:

>I like to compile (linux/gcc) with -pedantic -Wall
>and neaten up the code to eliminate all warnings.
>But the following code emits the message
>  warning: string length '1008' is greater than the
>  length '509' ISO C90 compilers are required to support
>and I can't see a neat way around it. The offending
>statement is,
>static  char latexwrapper[16384] =
>        "\\documentclass[10pt]{article}\n"
>        "\\usepackage[latin1]{inputenc}\n"
>        "\\usepackage{amsmath}\n"
>        "\\usepackage{amsfonts}\n"
>        "...lots-more-junk...";
>I could obviously break it up into several smaller
>initializations and strcat() them all at runtime,
>but that (in my opinion) isn't what I meant by "neat".
>It works as is, which is how I'd leave it if that's
>(strcat() several smaller strings at runtime) is the
>only solution. But a straightforward way around the
>warning would be even nicer.


Compile with: -Wno-overlength-strings

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

#14910

Robert Wessel <robertwessel2@yahoo.com> wrote:
> JohnF <john@please.see.sig.for.email.com> wrote:
> 
>>  warning: string length '1008' is greater than the
>>  length '509' ISO C90 compilers are required to support
> 
> Compile with: -Wno-overlength-strings

Who knew??? So I took a look at  man cc  and also found
-std=gnu99 which also works. Weirdly, though, -std=c99,
which seems equivalent as described on the manpage,
emits about a dozen new warnings, including some
"obviously wrong" (meaning they could be right?) ones
like "implicit declaration of function 'popen'", even
though stdio.h is included. (Note: I haven't actually
tested the executable images created using either switch,
and certainly not looked for any differences in the
generated instructions.)
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

#14914

JohnF <john@please.see.sig.for.email.com> wrote:
> Robert Wessel <robertwessel2@yahoo.com> wrote:
> > JohnF <john@please.see.sig.for.email.com> wrote:
> > 
> >>  warning: string length '1008' is greater than the
> >>  length '509' ISO C90 compilers are required to support
> > 
> > Compile with: -Wno-overlength-strings

> Who knew??? So I took a look at  man cc  and also found
> -std=gnu99 which also works. Weirdly, though, -std=c99,
> which seems equivalent as described on the manpage,
> emits about a dozen new warnings, including some
> "obviously wrong" (meaning they could be right?) ones
> like "implicit declaration of function 'popen'", even
> though stdio.h is included.

popen() isn't a standard C function but is from POSIX. Thus
when compiling for absolutely clean C it won't be defined.
You will need to define some extra macro (e.g. define
_POSIX_C_SOURCE to at least 2 or define one of _XOPEN_SOURCE,
_BSD_SOURCE or _SVID_SOURCE before including <stdio.h>) that
results in popen() (and other non-standard C functions) to
become declared in <stdio.h> (but, of course, at a loss of
portability). What I'm surprised about though is that you
didn't get those complaints already when compiling for C89
- I get them with '-ansi -pedantic'.

                          Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#14915

On 12/23/2011 07:41 AM, JohnF wrote:
> Robert Wessel <robertwessel2@yahoo.com> wrote:
>> JohnF <john@please.see.sig.for.email.com> wrote:
>>
>>>  warning: string length '1008' is greater than the
>>>  length '509' ISO C90 compilers are required to support
>>
>> Compile with: -Wno-overlength-strings
> 
> Who knew??? So I took a look at  man cc  and also found
> -std=gnu99 which also works. Weirdly, though, -std=c99,
> which seems equivalent as described on the manpage,
> emits about a dozen new warnings, including some
> "obviously wrong" (meaning they could be right?) ones
> like "implicit declaration of function 'popen'", even
> though stdio.h is included.

Using -std=c99 imposes strict C99 mode. turning off a lot os OS-specific
extensions to the C standard library. popen() is one of those
extensions. There's several different ways to turn it on. You can define
_BSD_SOURCE, or _SVID_SOURCE, or _POSIX_C_SOURCE with a value >= 2, or
_XOPEN_SOURCE with a value >= 500, or simply define _GNU_SOURCE, which
causes all of the others to be set as well.
-- 
James Kuyper

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

#14923

On Fri, 23 Dec 2011 12:41:30 +0000 (UTC), JohnF
<john@please.see.sig.for.email.com> wrote:

>Robert Wessel <robertwessel2@yahoo.com> wrote:
>> JohnF <john@please.see.sig.for.email.com> wrote:
>> 
>>>  warning: string length '1008' is greater than the
>>>  length '509' ISO C90 compilers are required to support
>> 
>> Compile with: -Wno-overlength-strings
>
>Who knew??? So I took a look at  man cc  and also found
>-std=gnu99 which also works. Weirdly, though, -std=c99,
>which seems equivalent as described on the manpage,
>emits about a dozen new warnings, including some
>"obviously wrong" (meaning they could be right?) ones
>like "implicit declaration of function 'popen'", even
>though stdio.h is included. (Note: I haven't actually
>tested the executable images created using either switch,
>and certainly not looked for any differences in the
>generated instructions.)


As others have pointed out, gnu99 leaves a bunch of commonly used GCC
extensions enabled.

A word about C99 mode (with or without extensions), though.  If C99
support is a reasonable prerequisite for the targets you're intending
to port to (or if you're writing strictly for the local machine), by
all means, go ahead and use that, there are certainly some useful
additions to the language (and also a few changes).

But while C89/C90 has been officially superseded by C99 (or actually
C11 as of a couple of weeks ago), there are a significant number of
compilers in the world that have not fully implemented C99 (or any of
C99) while still providing a full C89 implementation.  MS's standard
compiler falls into that category, for example, as do many compilers
for embedded targets.

So if you intend a port to Windows, you'll have to use a compiler
other than MSVC if you use C99 features.  If I understand the
situation correctly, Jacob Navia, who has posted in this thread, has
produced such a creature, and would apparently be willing to sell you
a license.  The GCC ports for Windows should work too, as would
Intel's ICC.  But there are certainly some advantages to using MSVC
for Windows development.

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

#14926

On 2011-12-23, Robert Wessel <robertwessel2@yahoo.com> wrote:
> But while C89/C90 has been officially superseded by C99 (or actually
> C11 as of a couple of weeks ago), there are a significant number of
> compilers in the world that have not fully implemented C99 (or any of
> C99) while still providing a full C89 implementation.  MS's standard
> compiler falls into that category, for example, as do many compilers
> for embedded targets.

Well, I'd be curious to know how many of them are in the "none at all"
category.  In theory, gcc doesn't fully support C99, but I've never actually
run into anything I wanted that it didn't have.

I regularly use designated initializers and struct literals, and I don't think
I've ever had a problem with that.  Of course, none of what I write has to
run on Windows.  :)

As to embedded targets... Obviously I'm biased as I'm mostly working with
Linux these days, but it's been quite a while since I saw an embedded target
vendor not provide gcc for their target.  Maintaining your own compiler is
a lot more work.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#14933

On 23 Dec 2011 19:04:48 GMT, Seebs <usenet-nospam@seebs.net> wrote:

>On 2011-12-23, Robert Wessel <robertwessel2@yahoo.com> wrote:
>> But while C89/C90 has been officially superseded by C99 (or actually
>> C11 as of a couple of weeks ago), there are a significant number of
>> compilers in the world that have not fully implemented C99 (or any of
>> C99) while still providing a full C89 implementation.  MS's standard
>> compiler falls into that category, for example, as do many compilers
>> for embedded targets.
>
>Well, I'd be curious to know how many of them are in the "none at all"
>category.  In theory, gcc doesn't fully support C99, but I've never actually
>run into anything I wanted that it didn't have.
>
>I regularly use designated initializers and struct literals, and I don't think
>I've ever had a problem with that.  Of course, none of what I write has to
>run on Windows.  :)


MSVC falls pretty much into the "none" category.  Basically none of
the C99 language features are supported, but they've picked up some of
the library, particularly since much of the C99 library was added to
C++11.

I've never quite understood their position.  MS has exerted
considerable effort to support the latest C++ standards (although
unfortunately some of the C++11 features have been pulled from the
next release, apparently due to time constraints, they've stated that
their intention is full support).  They even did a lot of work to
clean up their C89 issues (and MSVC has been a pretty good C89
compiler for years).  The added effort to keep up with C99 would have
been minimal.  And they're heavy C users - more-or-less the entire
kernel is still in C, although it may be analogous to the Linux folks
and GCC - they're interested in GCC's dialect of C, not so much the
standard.  There have also not been any commitments to support C11

I presume the fundamental problem is little or none of their user base
cares.  Perhaps as more C99 (and C11) starts being used on other
platforms, they'll reconsider.


>As to embedded targets... Obviously I'm biased as I'm mostly working with
>Linux these days, but it's been quite a while since I saw an embedded target
>vendor not provide gcc for their target.  Maintaining your own compiler is
>a lot more work.


GCC works well for the larger embedded processors (ARMs, MIPS, etc.),
but not so much for the smaller ones.

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

#14929 — New C standard (was Re: warning: string length greater than '509')

Robert Wessel <robertwessel2@yahoo.com> writes:
[...]
> But while C89/C90 has been officially superseded by C99 (or actually
> C11 as of a couple of weeks ago), there are a significant number of
> compilers in the world that have not fully implemented C99 (or any of
> C99) while still providing a full C89 implementation.  MS's standard
> compiler falls into that category, for example, as do many compilers
> for embedded targets.
[...]

Which raises an interesting point.  Since the 2011 ISO C standard
officially supersedes the C99 standard, both C90 and C99 now have
exactly the same status.  They're both officially obsolete standards
that still have some level of support from current implementations.
(C90 happens to have more support than C99.)

I presume that no implementations yet support all of C2011.  Are there
implementations that support some of the new C2011 features?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#14931 — Re: New C standard (was Re: warning: string length greater than '509')

Am 12/23/2011 09:21 PM, schrieb Keith Thompson:
> I presume that no implementations yet support all of C2011.  Are there
> implementations that support some of the new C2011 features?

gcc 4.6 has some, nothing dramatic, but AFAIR there are:

 -  _Static_assert
 -  redefinitions of typedefs
 -  anonymous struct or unions are supported since long.
 -  Some features such as _Noreturn or _Allignas could probably just
    be implemented as macros to some __attribute__

my guess would be that on POSIX systems the implementation of the
library side of threads and atomics could be realized quickly.

Jens

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

#14934 — Re: New C standard (was Re: warning: string length greater than '509')

On Fri, 23 Dec 2011 12:21:15 -0800, Keith Thompson <kst-u@mib.org>
wrote:

>Robert Wessel <robertwessel2@yahoo.com> writes:
>[...]
>> But while C89/C90 has been officially superseded by C99 (or actually
>> C11 as of a couple of weeks ago), there are a significant number of
>> compilers in the world that have not fully implemented C99 (or any of
>> C99) while still providing a full C89 implementation.  MS's standard
>> compiler falls into that category, for example, as do many compilers
>> for embedded targets.
>[...]
>
>Which raises an interesting point.  Since the 2011 ISO C standard
>officially supersedes the C99 standard, both C90 and C99 now have
>exactly the same status.  They're both officially obsolete standards
>that still have some level of support from current implementations.
>(C90 happens to have more support than C99.)
>
>I presume that no implementations yet support all of C2011.  Are there
>implementations that support some of the new C2011 features?


Starting with v4.6, GCC supports a subset of C11 features.  The
currently release of ICC does not (although there's a fair bit of
C++11 support), but the rumor is that the next release will.

I'm not aware of anyone with a full implementation, but I've not been
paying that close attention.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web