warning: string length greater than '509'

[JohnF]

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.

 

[jacob navia]

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.

 

[JohnF]

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.)

 

[jacob navia]

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.

 

[JohnF]

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.

 

[Jens Thoms Toerring]

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

 

[James Kuyper]

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.

 

[Eric Sosman]

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.

 

[Kaz Kylheku]

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.

Doh, you asked for pedantic and so you got it!

only solution. But a straightforward way around the
warning would be even nicer.

Delete "-pedantic" from the compiler command line.

 

[Seebs]

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

 

[Keith Thompson]

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?

 

[Jens Gustedt]

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

 

[rudolf]

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

I would guess so, since the committee tends to standardize things that
are already implemented. (At least that's how I understand it)

 

[JohnF]

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.

Thanks for the additional info. C89 should work fine for everything,
except the silly long string initialization. And although I usually
try to code in completely portable ansi standard C, this particular
program is pretty much Unix only. Maybe I should clarify, it's the
gpl'ed program http://www.forkosh.com/mathtex.html that recently
got that silly long string due to the enhancement
http://www.forkosh.com/mathtex.html?valignment which vertically
aligns emitted images precisely ("middle" or "absmiddle" doesn't
usually do a decent job). And since it's a one-line build, I don't
provide any configure/make-type script, just instructions what to
put on the cc line. And I won't bother adding -std to that. But I
occasionally get email about -pedantic warnings from sticklers, and
so try to eliminate them when it's feasible and reasonably easy.
This time it apparently ain't, so the heck with it. The 4095 limit
pointed out by Jacob Navia is quite more than I actually need,
so there's no actual problem, just the pesky message. And I hoped
there might be a tricky way to easily accomplish the equivalent
initialization without raising the warning. But I'm not materially
changing the code just to deal with it.

 

[JohnF]

If the command line option is an issue, there's an equivalent #pragma.

Yeah, I hate those kinds of constructs, which are nonportable by nature.
I usually try to (functionally) decompose a problem domain into two
subdomains: a computable function part, programmable a la Church's thesis
in any Turing complete language, and an environment/os-specific part
(usually i/o-related, or file/resource handling/locking-related, or
interprocess communication-related, or otherwise concurrency-related, etc).
And I try to minimize and isolate/sandbox the os-part as much as possible,
leaving the "business logic", and as much i/o as possible, completely
portable and reusable.
Anyway, that's getting way off-topic.
Thanks for your help,

 

[Patrick Scheible]

Since the 2011 ISO C standard officially supersedes the C99 standard,

So, is there a new edition of Harbison and Steele in the works?

Thanks,

-- Patrick

 

[Keith Thompson]

So, is there a new edition of Harbison and Steele in the works?

I have no inside information on that, but the web site
<http://careferencemanual.com/> hasn't been updated since 2006-08-14.

But there is an e-mail address for the author.

 

[Patrick Scheible]

I have no inside information on that, but the web site
<http://careferencemanual.com/> hasn't been updated since 2006-08-14.

But there is an e-mail address for the author.

If a couple of days goes by and nobody here volunteers an answer, I'll
send him an e-mail. Thanks!

-- Patrick

 

[Nick Keighley]

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


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

 

[James Kuyper]

C89/90 is still the most portable standard

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