[Tfug] C Compiler string limitations?

Bexley Hall bexley401 at yahoo.com
Mon Jul 17 13:43:57 MST 2006


--- TR <trexx at pobox.com> wrote:

> Bexley Hall wrote:
> 
> >I'm curious if anyone has had any experiences with
> >compilers choking on long strings/byte arrays.
> >
> >I have some data structures that look like:
> >"..." ## "..." ## "..." (etc)
>
> How is
> 
> "..." ## "..." ## "..." 
> any different then 
> "..." "..." "..." 
> or for that matter 
> "........."

The "....." doesn't let you avail yourself of other
symbols known to the preprocessor (e.g., manifest
constants).

So, you can't accommodate:

#define VOWELS "A" "E" "I" "O" "U"

CONSONANT VOWELS

if forced to cram everything between quotes.

The second form (assuming you accept the fact that
some tokens will not be strings -- e.g. "CONSONANT"
above) does let you build symbols that the
preprocessor
can resolve on your behalf:

#define FRONTVOWEL "E" "I" "Y"

CONSONANT FRONT ## VOWEL

<grin>

> I realize that the data may be 'generated'  for you
> but the the ANSI Token Pasting should not be the way
> to concatenate stings.   Two strings adjacent is all
> that is needed .

Only if those strings are in string form.
So, either token paste or use the "stringize"
operator.
 
> The Token Pasting feature is to allows concatenation
> within MACROs like 
> #define FILE_NAME( ext ) test.##ext 
> 
> So that 
>   fopen( FILE_NAME( bak ) ) ;
> becomes 
>   fopen( test.bak ) ;

Or, FRONT ## VOWEL becomes FRONTVOWEL  :>
 
> >and, in the interest of portability, would hope
> >that few compilers would gag on them.
>
> Using the Token pasting operator  could be non
> portable.

Not for an ANSI compliant compiler.
 
> >I can, alternatively, rewuite them as char[] but
> >that's a bit more processing in my scripts
> >(the structures are built automatically).
>  
> I would build the string what ever is the easiest
> way and save to a file.  Then write a function to
> read and parse that file to capture the strings.
> Now the string is not ever seen by the compiler.
> And only used at runtime.

Not all of us work in desktop environments!  :>

This approach requires a filesystem.

The "data" read must then reside in the DATA
segment (instead of a R/O TEXT segment).

It adds another set of error routines (what if
the "file" can't be found? or has been corrupted?
or "accidentally" overwritten with something else?
what if you don't have enough RAM on the heap to
accommodate the file's size?).  These checks then
require the ability to report these errors to the
user in a meaningful way.

It defers to runtime something that can be
done at compile time.  :>

> >I know GCC uses a crapload of VM when processing
> >large arrays but, with enough swap, that's not
> >an issue.  I'm just wondering if other toolchains
> >simply crash-and-burn in these cases...

Thanks!
--don

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 




More information about the tfug mailing list