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

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

error: initializer element is not constant|

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

Contents

  error: initializer element is not constant| jak <please@nospam.tnx> - 2017-05-08 09:55 +0200
    Re: error: initializer element is not constant| jak <please@nospam.tnx> - 2017-05-08 10:05 +0200
    Re: error: initializer element is not constant| Noob <root@127.0.0.1> - 2017-05-08 10:38 +0200
      Re: error: initializer element is not constant| jak <please@nospam.tnx> - 2017-05-08 11:55 +0200
        Re: error: initializer element is not constant| bartc <bc@freeuk.com> - 2017-05-08 11:01 +0100
          Re: error: initializer element is not constant| jak <please@nospam.tnx> - 2017-05-08 12:18 +0200
            Re: error: initializer element is not constant| bartc <bc@freeuk.com> - 2017-05-08 12:02 +0100
              Re: error: initializer element is not constant| Keith Thompson <kst-u@mib.org> - 2017-05-08 09:00 -0700
                Re: error: initializer element is not constant| bartc <bc@freeuk.com> - 2017-05-08 17:50 +0100
                  Re: error: initializer element is not constant| Keith Thompson <kst-u@mib.org> - 2017-05-08 11:37 -0700
                    Re: error: initializer element is not constant| bartc <bc@freeuk.com> - 2017-05-08 19:49 +0100
                      Re: error: initializer element is not constant| Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-08 20:13 +0100
                      Re: error: initializer element is not constant| Keith Thompson <kst-u@mib.org> - 2017-05-08 12:44 -0700
                      Re: error: initializer element is not constant| scott@slp53.sl.home (Scott Lurndal) - 2017-05-08 20:24 +0000
              Re: error: initializer element is not constant| jak <please@nospam.tnx> - 2017-05-09 09:54 +0200
                Re: error: initializer element is not constant| jak <please@nospam.tnx> - 2017-05-09 10:15 +0200
                Re: error: initializer element is not constant| GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-09 12:12 +0200
                Re: error: initializer element is not constant| bartc <bc@freeuk.com> - 2017-05-09 11:47 +0100
                  Re: error: initializer element is not constant| jak <please@nospam.tnx> - 2017-05-09 19:06 +0200
                    Re: error: initializer element is not constant| scott@slp53.sl.home (Scott Lurndal) - 2017-05-09 17:10 +0000
                      Re: error: initializer element is not constant| jak <please@nospam.tnx> - 2017-05-09 19:20 +0200
                        Re: error: initializer element is not constant| Barry Schwarz <schwarzb@dqel.com> - 2017-05-09 10:35 -0700
                          Re: error: initializer element is not constant| jak <please@nospam.tnx> - 2017-05-09 20:04 +0200
                            Re: error: initializer element is not constant| Keith Thompson <kst-u@mib.org> - 2017-05-09 11:57 -0700
                              Re: error: initializer element is not constant| supercat@casperkitty.com - 2017-05-09 12:50 -0700
                                Re: error: initializer element is not constant| Keith Thompson <kst-u@mib.org> - 2017-05-09 12:54 -0700
                            Re: error: initializer element is not constant| bartc <bc@freeuk.com> - 2017-05-09 20:15 +0100
                          Re: error: initializer element is not constant| "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-09 14:13 -0400
                          Re: error: initializer element is not constant| Keith Thompson <kst-u@mib.org> - 2017-05-09 11:41 -0700
                Re: error: initializer element is not constant| Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-09 12:16 +0100
                Re: error: initializer element is not constant| Keith Thompson <kst-u@mib.org> - 2017-05-09 08:11 -0700
            Re: error: initializer element is not constant| Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-08 12:12 +0100
              Re: error: initializer element is not constant| bartc <bc@freeuk.com> - 2017-05-08 13:45 +0100
                Re: error: initializer element is not constant| Keith Thompson <kst-u@mib.org> - 2017-05-08 09:04 -0700
                Re: error: initializer element is not constant| Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-08 19:53 +0100
                  Re: error: initializer element is not constant| bartc <bc@freeuk.com> - 2017-05-08 20:44 +0100
                    Re: error: initializer element is not constant| Noob <root@127.0.0.1> - 2017-05-09 09:27 +0200
                Re: error: initializer element is not constant| Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-09 07:10 -0700
              Re: error: initializer element is not constant| Keith Thompson <kst-u@mib.org> - 2017-05-08 09:30 -0700
    Re: error: initializer element is not constant| John Bode <jfbode1029@gmail.com> - 2017-05-08 08:05 -0700

Page 2 of 2 — ← Prev page 1 [2]

#109606

Il 09/05/2017 19:10, Scott Lurndal ha scritto:
> jak <please@nospam.tnx> writes:
>> Il 09/05/2017 12:47, bartc ha scritto:
>
>>
>> No, I do not want anything different. Only I can not understand the
>> reason why the compiler wants the initializer to be constant. When I
>> write this:
>>
>> char *Phrase[] =
>> {
>>    NULL, /*1*/
>>    NULL, /*2*/
>>    NULL, /*3*/
>>    NULL  /*4*/
>> };
>>
>> I ask the compiler to allocate for me 4 contiguous memory areas, each
>> large to contain a pointer. Each pointer is char type and then uses this
>> step in its arithmetic. If at runtime I can modify, with new values,
>> each of the 4 pointers I have declared; Why does the compiler want it to
>> be constant during the definition?
>
> Because you're defining file-scope static data, which must
> be fully resolved at compile time since it will be stored in
> the executable (ELF, PE/COFF), long before run-time.
>
Ok. Then return to the first question. What information is missing from 
the compiler to solve this?

char *Date = "01-01-80";
char *Phrase[] =
{
    NULL, /*1*/
    Date, /*2*/
    NULL, /*3*/
    NULL  /*4*/
};

...and why does it solve this?

char *DescDate = "Date: ";
char *Date = "01-01-80";
char *CrLf = "\r\n";
char *Text = "Dear friend...";

char **Phrase[] =
{
   &DescDate, &Date, &CrLf,
   &Text, &CrLf
};

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

#109609

On Tue, 9 May 2017 19:20:41 +0200, jak <please@nospam.tnx> wrote:

>Il 09/05/2017 19:10, Scott Lurndal ha scritto:
>> jak <please@nospam.tnx> writes:
>>> Il 09/05/2017 12:47, bartc ha scritto:
>>
>>>
>>> No, I do not want anything different. Only I can not understand the
>>> reason why the compiler wants the initializer to be constant. When I
>>> write this:
>>>
>>> char *Phrase[] =
>>> {
>>>    NULL, /*1*/
>>>    NULL, /*2*/
>>>    NULL, /*3*/
>>>    NULL  /*4*/
>>> };
>>>
>>> I ask the compiler to allocate for me 4 contiguous memory areas, each
>>> large to contain a pointer. Each pointer is char type and then uses this
>>> step in its arithmetic. If at runtime I can modify, with new values,
>>> each of the 4 pointers I have declared; Why does the compiler want it to
>>> be constant during the definition?
>>
>> Because you're defining file-scope static data, which must
>> be fully resolved at compile time since it will be stored in
>> the executable (ELF, PE/COFF), long before run-time.
>>
>Ok. Then return to the first question. What information is missing from 
>the compiler to solve this?
>
>char *Date = "01-01-80";
>char *Phrase[] =
>{
>    NULL, /*1*/
>    Date, /*2*/
>    NULL, /*3*/
>    NULL  /*4*/
>};
>
>...and why does it solve this?
>
>char *DescDate = "Date: ";
>char *Date = "01-01-80";
>char *CrLf = "\r\n";
>char *Text = "Dear friend...";
>
>char **Phrase[] =
>{
>   &DescDate, &Date, &CrLf,
>   &Text, &CrLf
>};

Possibly because the address of a static variable is a compile time
const (note const, not constant) while the value of a static variable
is not.

-- 
Remove del for email

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

#109612

>> Ok. Then return to the first question. What information is missing from
>> the compiler to solve this?
>>
>> char *Date = "01-01-80";
>> char *Phrase[] =
>> {
>>    NULL, /*1*/
>>    Date, /*2*/
>>    NULL, /*3*/
>>    NULL  /*4*/
>> };
>>
>> ...and why does it solve this?
>>
>> char *DescDate = "Date: ";
>> char *Date = "01-01-80";
>> char *CrLf = "\r\n";
>> char *Text = "Dear friend...";
>>
>> char **Phrase[] =
>> {
>>   &DescDate, &Date, &CrLf,
>>   &Text, &CrLf
>> };
>
> Possibly because the address of a static variable is a compile time
> const (note const, not constant) while the value of a static variable
> is not.
>
You would be right if the compiler information was not the same in both 
cases. Also at runtime you can change any value in * Phrase [] and in ** 
Phrase [], too, so why const? I'm afraid it's just a syntactic 
imposition. :(

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

#109616

jak <please@nospam.tnx> writes:
>>> Ok. Then return to the first question. What information is missing from
>>> the compiler to solve this?
>>>
>>> char *Date = "01-01-80";
>>> char *Phrase[] =
>>> {
>>>    NULL, /*1*/
>>>    Date, /*2*/
>>>    NULL, /*3*/
>>>    NULL  /*4*/
>>> };
>>>
>>> ...and why does it solve this?
>>>
>>> char *DescDate = "Date: ";
>>> char *Date = "01-01-80";
>>> char *CrLf = "\r\n";
>>> char *Text = "Dear friend...";
>>>
>>> char **Phrase[] =
>>> {
>>>   &DescDate, &Date, &CrLf,
>>>   &Text, &CrLf
>>> };
>>
>> Possibly because the address of a static variable is a compile time
>> const (note const, not constant) while the value of a static variable
>> is not.
>>
> You would be right if the compiler information was not the same in both 
> cases. Also at runtime you can change any value in * Phrase [] and in ** 
> Phrase [], too, so why const? I'm afraid it's just a syntactic 
> imposition. :(

The language standard has to have some consistent definition of what is
or is not a constant expression.  It can't just say "anything whose
value the compiler can figure out is a constant expression"; that would
imply that the criteria could change depending on how clever the
compiler happens to be.

In general, the standard doesn't require compilers to perform data flow
analysis.

Let's take a simple example:

    char *foo = "hello";
    char *bar = foo;

In this case, sure, a compiler *could* perform an analysis that
determines that the value of foo, when it's used in an initializer
for the static object bar, cannot have changed from its initial
value.  But although the compiler must generate code that will
cause foo to be properly initialized before entry to main(), it's
not required to remember what that initial value is.  It would have
to do so to be able to implement those declarations.

On the other hand, given:

    char foo[] = "hello";
    char *bar = foo;

the expression `foo` in the initializer yields the address of a
static object, not the (current) value of that object.  The compiler
has to be able to generate code that refers to the address of a
static object anyway, so there's no extra burden in requiring it
to treat such an address as a compile-time constant expression.

Given modern optimizing compiler technology, it might be possible to
loosen the rules for constant expressions by requiring *some* data
flow analysis.  But (a) that would still impose an extra burden
on small non-optimizing compilers, and (b) defining the exact
new rules in Standardese would be a difficult task (and reaching
agreement on just what those rules should be would be even harder).
A small tweak to the rules, to cover just a case like this one,
might partially avoid those problems, but it's unlikely that it
would be considered worthwhile.  The committee isn't going to change
the language to fix a problem that already has a workaround.

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

#109624

On Tuesday, May 9, 2017 at 1:57:22 PM UTC-5, Keith Thompson wrote:
> On the other hand, given:
> 
>     char foo[] = "hello";
>     char *bar = foo;
> 
> the expression `foo` in the initializer yields the address of a
> static object, not the (current) value of that object.  The compiler
> has to be able to generate code that refers to the address of a
> static object anyway, so there's no extra burden in requiring it
> to treat such an address as a compile-time constant expression.

Actually, in some cases the latter may be a significant burden, but it is
one that the authors of the C Standard thought was worthwhile to impose.
Most notably, there are some platforms where static variables are accessed
using a displacement from an address register.  Such a design makes it
practical for a system without a memory-management unit (e.g. the classic
Macintosh) to have multiple applications in memory simultaneously but means
that after a program is loaded into memory as a blob, the startup code will
need to patch all static objects that are initialized to hold addresses of
functions or other static objects.

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

#109625

supercat@casperkitty.com writes:
> On Tuesday, May 9, 2017 at 1:57:22 PM UTC-5, Keith Thompson wrote:
>> On the other hand, given:
>> 
>>     char foo[] = "hello";
>>     char *bar = foo;
>> 
>> the expression `foo` in the initializer yields the address of a
>> static object, not the (current) value of that object.  The compiler
>> has to be able to generate code that refers to the address of a
>> static object anyway, so there's no extra burden in requiring it
>> to treat such an address as a compile-time constant expression.
>
> Actually, in some cases the latter may be a significant burden, but it is
> one that the authors of the C Standard thought was worthwhile to impose.
> Most notably, there are some platforms where static variables are accessed
> using a displacement from an address register.  Such a design makes it
> practical for a system without a memory-management unit (e.g. the classic
> Macintosh) to have multiple applications in memory simultaneously but means
> that after a program is loaded into memory as a blob, the startup code will
> need to patch all static objects that are initialized to hold addresses of
> functions or other static objects.

I said it's no *extra* burden.  It's a burden that's required for
handling static objects at all.

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

#109619

On 09/05/2017 19:04, jak wrote:
>>> Ok. Then return to the first question. What information is missing from
>>> the compiler to solve this?
>>>
>>> char *Date = "01-01-80";
>>> char *Phrase[] =
>>> {
>>>    NULL, /*1*/
>>>    Date, /*2*/
>>>    NULL, /*3*/
>>>    NULL  /*4*/
>>> };
>>>
>>> ...and why does it solve this?
>>>
>>> char *DescDate = "Date: ";
>>> char *Date = "01-01-80";
>>> char *CrLf = "\r\n";
>>> char *Text = "Dear friend...";
>>>
>>> char **Phrase[] =
>>> {
>>>   &DescDate, &Date, &CrLf,
>>>   &Text, &CrLf
>>> };
>>
>> Possibly because the address of a static variable is a compile time
>> const (note const, not constant) while the value of a static variable
>> is not.
>>
> You would be right if the compiler information was not the same in both
> cases. Also at runtime you can change any value in * Phrase [] and in **
> Phrase [], too, so why const? I'm afraid it's just a syntactic
> imposition. :(

Yes, it's a rule about what kind of expressions are allowed. Sometimes, 
as here, it might be 'obvious' what value should be used. But in general 
it's not possible to evaluate such expressions, or they are ambiguous.

This is the rule:

int A=1200;
int B=A;

This is not allowed. But you can do this:

#define K 1200
int A=K;
int B=K;

or:

int A=1200;
int main(void){
   int B=A;
...

-- 
bartc

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

#109613

On 05/09/2017 01:35 PM, Barry Schwarz wrote:
> On Tue, 9 May 2017 19:20:41 +0200, jak <please@nospam.tnx> wrote:
...
>> Ok. Then return to the first question. What information is missing from
>> the compiler to solve this?

It's not that the information is missing - but that the C standard 
doesn't require implementation to figure it out.

>> char *Date = "01-01-80";
>> char *Phrase[] =
>> {
>>    NULL, /*1*/
>>    Date, /*2*/
>>    NULL, /*3*/
>>    NULL  /*4*/
>> };
>>
>> ...and why does it solve this?
>>
>> char *DescDate = "Date: ";
>> char *Date = "01-01-80";
>> char *CrLf = "\r\n";
>> char *Text = "Dear friend...";
>>
>> char **Phrase[] =
>> {
>>   &DescDate, &Date, &CrLf,
>>   &Text, &CrLf
>> };
>
> Possibly because the address of a static variable is a compile time
> const (note const, not constant) while the value of a static variable
> is not.

Note, in particular, that the unnamed array of char in which "01-01-80" 
is stored has static storage duration (6.4.5p6), and that the value of 
that string literal, which is automatically converted into a pointer to 
the first element of that array, is therefore a perfectly legitimate 
address constant (6.6p8). A sufficient intelligent compiler could have 
noticed that they have the same value, and initialized Phrase 
accordingly - but the C standard doesn't require the compiler to be that 
bright: "... the value of an object shall not be accessed ..." (6.6p9).

Trivial work-arounds:

     char Date[] = "01-01-80";

or

     #define Date "01-01-80"

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

#109614

Barry Schwarz <schwarzb@dqel.com> writes:
> On Tue, 9 May 2017 19:20:41 +0200, jak <please@nospam.tnx> wrote:
[...]
>>Ok. Then return to the first question. What information is missing from 
>>the compiler to solve this?
>>
>>char *Date = "01-01-80";
>>char *Phrase[] =
>>{
>>    NULL, /*1*/
>>    Date, /*2*/
>>    NULL, /*3*/
>>    NULL  /*4*/
>>};
>>
>>...and why does it solve this?
>>
>>char *DescDate = "Date: ";
>>char *Date = "01-01-80";
>>char *CrLf = "\r\n";
>>char *Text = "Dear friend...";
>>
>>char **Phrase[] =
>>{
>>   &DescDate, &Date, &CrLf,
>>   &Text, &CrLf
>>};
>
> Possibly because the address of a static variable is a compile time
> const (note const, not constant) while the value of a static variable
> is not.

You got that backwards.  The address of a static variable is a compile
time *constant*.  Specifically, it's an *address constant* as defined in
N1570 6.6p9.

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

#109576

jak <please@nospam.tnx> writes:

> Il 08/05/2017 13:02, bartc ha scritto:
>> On 08/05/2017 11:18, jak wrote:
>>
>>> I would like to create an array of pointers, of pointers to strings. In
>>> this way I can have the pointers as constant and I wrote this:
>>>
>>> char *Date = "01-01-80";
>>>
>>> typedef char * ch;
>>> typedef ch * p_ch;
>>>
>>> p_ch foo[] =
>>> {
>>>   &Date,
>>>   (p_ch)&"Date"
>>> };
>>>
>>> This works but I do not know how to declare foo without using typedef.
>>
>> Those types would look like this without typedefs:
>>
>> char *  str;
>> char *  array_of_str[];
>> char ** ptr_to_str;
>> char ** array_of_ptr_to_str[];
>>
>> (The arrays will need a dimension, or need to be initialised.)
>>
>> But arrays of pointers to strings would be unusual, and be harder to
>> initialise as you can't just have "ABC", but need to set up a named
>> string: char* abc="ABC", then use &abc.
>>
>> I don't think you can apply a cast to "ABC" to get the pointer you need.
>> (Well, you can cast it, but it won't be a proper pointer to string,
>> it'll just be a string, and will crash when you apply the dereference
>> below.)
>>
>> Using the array would be harder too as you'll need an extra dereference
>> to extract the string:
>>
>>    puts(*array_of_ptr_to_str[0]);
>>
> Ok ok. Bugs have also been put in the middle. The first time I wrote the declaration in this way:
>
> char *Date = "01-01-80";
> char **Phrases[]
> {
>    &Date
> }

This looks like a typing error.  You should cut and paste code.

> and gcc gave me a lot of errors.

If that was the code, you will get errors.  It's just not correct C.  I
suspect you meant to write:

     char *Date = "01-01-80";
     char **Phrases[] = { 
              &Date
     };

which should work.

<snip>
> Now I'm using this work around:
>
> char *Phrases[]
> {
>    "Date: ",
>    NULL,
>    "\r\n"
> };

Are you missing an = again?  As shown, this should not work.

> char **DatePos = Phrases[1];

And this won't work (because the types don't match) if you have "char
*Phrases" as shown.  Programming is about detail, and you will get very
confused with things that seem to work and then don't or change from
working to broken because you don't spot these details.

> foo()
> {
>    *DatePos = ctime(&t);
>    *DatePos[strlen(Date) - 1] = '\0';

This is all wrong.  You really need to back-up, take a breath, and
re-think.  For a start, *DatePos[strlen(Date) - 1] = '\0'; does not do
what you think.  It means *(DatePos[strlen(Date) - 1]) = '\0' and
DatePos does not have that many elements.

What is the ultimate purpose of these pointers and arrays of pointers?

> }
>
> But I still do not understand why the compiler does not allow me this:
>
> char *Date = NULL;
> char *Phrases[]
> {
>    "Date: ",
>    Date,
>    "\r\n"
> };

The main reason is syntax.  This is not valid declaration in C.  Correct
the syntax and yo may find it compiles.  Whether is does what you want
is another matter altogether, but since you don't say what you want, I
can't help with that.

> In the end I'm just asking him to allocate space to write in an
> address exactly as it happens when I write NULL instead of 'Date'.

-- 
Ben.

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

#109597

jak <please@nospam.tnx> writes:
[...]
> Ok ok. Bugs have also been put in the middle. The first time I wrote the 
> declaration in this way:
>
> char *Date = "01-01-80";
> char **Phrases[]
> {
>     &Date
> }
>
> and gcc gave me a lot of errors.

You have two simple syntax errors.  You need an "=" before the
initializer, and a semicolon after it.  With those changes, it compiles.

[...]

> But I still do not understand why the compiler does not allow me this:
>
> char *Date = NULL;
> char *Phrases[]
> {
>     "Date: ",
>     Date,
>     "\r\n"
> };
>
> In the end I'm just asking him to allocate space to write in an address 
> exactly as it happens when I write NULL instead of 'Date'.

The initializer for an object defined at file scope must consist only of
constant expressions.  The expression `Date` yields the value of a
variable, which obviously is not constant.  (A compiler might be able to
determine that the object hasn't been modified since its initialization,
but that doesn't make its name a constant expression.  Adding "const"
wouldn't help either; "const" means read-only, not constant.)

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

#109489

jak <please@nospam.tnx> writes:

> Il 08/05/2017 12:01, bartc ha scritto:
<snip>
>> In C, declaring the type of a variable is optional,

Not for nearly two decades.  If you can ask the compiler to follow a
modern standard, you will be told about such things.

<snip>
> I would like to create an array of pointers, of pointers to
> strings. In this way I can have the pointers as constant and I wrote
> this:

I think you should back-up a bit.  How do you plan to use this data?  I
ask because "a pointer to a string" is not well-defined in C.  A C
strings are not a type but a format of data (essentially insisting on a
null terminator) so must program represent a "pointer to string" as
char * -- i.e. as a pointer to the first character of the string.

> char *Date = "01-01-80";
>
> typedef char * ch;
> typedef ch * p_ch;
>
> p_ch foo[] =
> {
>   &Date,
>   (p_ch)&"Date"

Woop! Woop! Woop!
In C, a cast should alert you to something that needs to be scrutinised.
It often means something is wrong in the design.  (Casts that are there
to silence an advisory warning that you otherwise like to see are not
quite the same.)

In this case there is a real problem.

> };
>
> This works but I do not know how to declare foo without using typedef.

char **foo[] = { ... };

But you can't point to the pointer that points to "Date".  The cast has
simply papered over a real problem.  If you need to change the
pointed-to pointers, you will come unstuck when using literal strings.

So, can you say what you are aiming for here?

-- 
Ben.

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

#109492

On 08/05/2017 12:12, Ben Bacarisse wrote:
> jak <please@nospam.tnx> writes:
>
>> Il 08/05/2017 12:01, bartc ha scritto:
> <snip>
>>> In C, declaring the type of a variable is optional,
>
> Not for nearly two decades.  If you can ask the compiler to follow a
> modern standard, you will be told about such things.

If I say -std=c99 or -std=c11 to gcc, it still just gives me a warning 
about implicit int.

Ergo, it is still optional.

If I try the same in a language where it's definitely not optional, I 
will get a hard error not just a telling-off.

-- 
bartc

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

#109506

bartc <bc@freeuk.com> writes:
> On 08/05/2017 12:12, Ben Bacarisse wrote:
>> jak <please@nospam.tnx> writes:
>>> Il 08/05/2017 12:01, bartc ha scritto:
>> <snip>
>>>> In C, declaring the type of a variable is optional,
>>
>> Not for nearly two decades.  If you can ask the compiler to follow a
>> modern standard, you will be told about such things.
>
> If I say -std=c99 or -std=c11 to gcc, it still just gives me a warning 
> about implicit int.
>
> Ergo, it is still optional.
>
> If I try the same in a language where it's definitely not optional, I 
> will get a hard error not just a telling-off.

That warning is a diagnostic message about a constraint violation.
It is not optional.  (I personally consider it unfortunate that gcc
chooses to issue non-fatal warnings for some constraint violations,
but that can be worked around using the "-pedantic-errors" option.)

In C99 and C11, declaring the type of a variable is not optional.
A program that fails to do so is just as invalid as a program
containing a syntax error.  gcc's odd way of diagnosing such errors
is not a language issue (except for the fact that the C standard
permits such treatment).

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

#109528

bartc <bc@freeuk.com> writes:

> On 08/05/2017 12:12, Ben Bacarisse wrote:
>> jak <please@nospam.tnx> writes:
>>
>>> Il 08/05/2017 12:01, bartc ha scritto:
>> <snip>
>>>> In C, declaring the type of a variable is optional,
>>
>> Not for nearly two decades.  If you can ask the compiler to follow a
>> modern standard, you will be told about such things.
>
> If I say -std=c99 or -std=c11 to gcc, it still just gives me a warning
> about implicit int.
>
> Ergo, it is still optional.

No.  You are (again) drawing unwarranted conclusions about C from what
gcc tells you.

<snip>
-- 
Ben.

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

#109534

On 08/05/2017 19:53, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
>
>> On 08/05/2017 12:12, Ben Bacarisse wrote:
>>> jak <please@nospam.tnx> writes:
>>>
>>>> Il 08/05/2017 12:01, bartc ha scritto:
>>> <snip>
>>>>> In C, declaring the type of a variable is optional,
>>>
>>> Not for nearly two decades.  If you can ask the compiler to follow a
>>> modern standard, you will be told about such things.
>>
>> If I say -std=c99 or -std=c11 to gcc, it still just gives me a warning
>> about implicit int.
>>
>> Ergo, it is still optional.
>
> No.  You are (again) drawing unwarranted conclusions about C from what
> gcc tells you.

Most people can only use C via a compiler.

The compilers I've tried don't seem to rigorously enforce the 
requirement that variables and functions must have an explicit type:

    a=1234;           // at file scope

pelles c           warning
lccwin             warning
dmc                nothing
gcc                warning
tiny c             nothing

All run with default options, except gcc which is the only one where I 
know how to specify a standard.

(My own compiler allowed implicit types because I thought it had to. But 
now it no longer does so and a hard error is reported.)

Maybe, as Keith suggested, the fault is also with the language in not 
requiring such errors to be reported seriously.

(All the compilers on godbolt.org report this as an actual error. But I 
think they are compiling as C++ not C.)

-- 
bartc

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

#109564

On 08/05/2017 21:44, bartc wrote:

> The compilers I've tried don't seem to rigorously enforce the 
> requirement that variables and functions must have an explicit type

This set of flags:

  gcc -std=c11 -Wall -Werror -pedantic -pedantic-errors

will put gcc in a mode which is closer to your expectations.

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

#109591

bartc <bc@freeuk.com> writes:

> If I say -std=c99 or -std=c11 to gcc, it still just gives me a warning
> about implicit int.

Use -pedantic-errors (in addition to -std=...).

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

#109513

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> I think you should back-up a bit.  How do you plan to use this data?  I
> ask because "a pointer to a string" is not well-defined in C.

In fact it is.

>                                                                A C
> strings are not a type but a format of data (essentially insisting on a
> null terminator) so must program represent a "pointer to string" as
> char * -- i.e. as a pointer to the first character of the string.

N1570 7.1.1p1:

    A *string* is a contiguous sequence of characters terminated by
    and including the first null character.  [...]  A *pointer to a
    string* is a pointer to its initial (lowest addressed) character.

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

#109503

On Monday, May 8, 2017 at 2:55:12 AM UTC-5, jak wrote:
> Hello to all,
> Is there any way, in standard C, to write something like this without 
> getting an error?
> 
> static char *Date = "2017-05-08";
> 
> static char *Phrase[] =
> {
>    "Date: ",
>    Date,
>    "\r\n"
> };

Does Phrase really need to be static?  If so, then you'll have to replace
Date with a string literal or a macro that expands to a string literal:

#define DATE "2017-05-08"

static char *Phrase[] = 
{
  "Date: ",
  DATE,
  "\r\n"
};

Since you declared Phrase to be static, you can only use constant 
expressions in the initializer.  

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web