Re: [9fans] porting help please (gcc void pointer handling)

Re: [9fans] porting help please (gcc void pointer handling)

[Fernan Bolando]

On Wed, Sep 9, 2009 at 4:36 PM, Greg Comeau<comeau@panix.com> wrote:
> In article <1d5d51400909080844q1bee4c3s114ccc5e51ce52f5@mail.gmail.com>,
> Fernan Bolando <fernanbolando@mailc.net> wrote:
>>...error: initializer is not a constant: F0_Prelude_46primLeave
>>--h file ---
>>#define VAP_TAG  1
>>#define WORDSHIFT  5
>>#define WORDSIZE   (1<<WORDSHIFT)
>>#define WORDMASK   (WORDSIZE-1)
>>#define NS         (WORDSIZE>>3)
>>#define ZAP_BIT    (1L<<(WORDSIZE-1))
>>-- c file ----
>>unsigned F0_Prelude_46primLeave[] = {
>>  CAPTAG(FN_Prelude_46primLeave,1)
>>#ifdef PROFILE
>>, useLabel(PROF_primLeave)
>>, 0
>>, 0
>>, 0
>>#endif
>
> The initializers to some things need to be constants.
> In your case, it appears that either CAPTAG or useLabel (or both)
> have ended up not being #define'd.  Probably the header they are
> #define'd in is not being #include'd (you don't show it above,
> but then you don't show enough of your code to even reproduce it).
>
> On a relate note, you can see the results of preprocessing
> from pcc by using the -E and/or -P options, that way you
> can see whether the macro ended up getting substituted
> and what it was substituted to -- or not in your case.
> Some compilers also have options which will emit the trail of
> files #include'd but I don't see that option for pcc.

gcc happily compiles a definition like
#define CT_v249	((void*)startLabel+464)

is it valid just to add to make the porting non-destructive?

#ifdef Plan9
#define void unsigned char
#endif


-- 
http://www.fernski.com

Re: [9fans] porting help please (gcc void pointer handling)

[erik quanstrom]

> gcc happily compiles a definition like
> #define CT_v249	((void*)startLabel+464)
>

no it doesn't.

$ cat > x.c
char	*startlab;
long long offset = (void*)startlab+464;
[...]
$ gcc -Wall x.c
x.c:2: error: initializer element is not constant

[...]

- erik

Re: [9fans] porting help please (gcc void pointer handling)

[roger peppe]

2009/9/9 erik quanstrom <quanstro@quanstro.net>:
>> gcc happily compiles a definition like
>> #define CT_v249       ((void*)startLabel+464)
>
> no it doesn't.

yes it does:

% cat > x.c
void *f(void *v){return v + 23;}
% gcc -Wall -c x.c
%

Re: [9fans] porting help please (gcc void pointer handling)

[Greg Comeau]

In article <df49a7370909090849wc1729bk469b15da35ec3798@mail.gmail.com>,
roger peppe <rogpeppe@gmail.com> wrote:
>2009/9/9 erik quanstrom <quanstro@quanstro.net>:
>>> gcc happily compiles a definition like
>>> #define CT_v249 =C2=A0 =C2=A0 =C2=A0 ((void*)startLabel+464)
>>
>> no it doesn't.
>
>yes it does:
>
>% cat > x.c
>void *f(void *v){return v + 23;}
>% gcc -Wall -c x.c
>%

use -pedantic:
q.c:1: warning: pointer of type 'void *' used in arithmetic

There is probably some option to have the warning as an error too.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] porting help please (gcc void pointer handling)

[Greg Comeau]

In article <ce56ea3d797a84d83b7c83620832b8c0@quanstro.net>,
erik quanstrom <quanstro@quanstro.net> wrote:
>> gcc happily compiles a definition like
>> #define CT_v249	((void*)startLabel+464)
>>
>
>no it doesn't.
>
>$ cat > x.c
>char	*startlab;
>long long offset = (void*)startlab+464;
>[...]
>$ gcc -Wall x.c
>x.c:2: error: initializer element is not constant

That also has the issue of converting a void * to a long long,
which may or may not work on the platform in question.
Notwithstanding that, there's also the case where it may
be say a non-static local which would be ok.
Anyway, to the OP, eric's point is that the #define by itself
may be fine, but *using it* as constant intializer is not,
since the value of startLabel, if it's something like a char *,
is not for use as a constant intiailizer
(so adding 464 to it is not either).
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] porting help please (gcc void pointer handling)

[erik quanstrom]

On Thu Sep 10 05:37:12 EDT 2009, comeau@panix.com wrote:
> In article <ce56ea3d797a84d83b7c83620832b8c0@quanstro.net>,
> erik quanstrom <quanstro@quanstro.net> wrote:
> >> gcc happily compiles a definition like
> >> #define CT_v249	((void*)startLabel+464)
> >>
> >
> >no it doesn't.
> >
> >$ cat > x.c
> >char	*startlab;
> >long long offset = (void*)startlab+464;
> >[...]
> >$ gcc -Wall x.c
> >x.c:2: error: initializer element is not constant
>
> That also has the issue of converting a void * to a long long,

sorry.  my mouse license has been revoked.  that
was actually void*.

- erik

Re: [9fans] porting help please (gcc void pointer handling)

[Charles Forsyth]

>is it valid just to add to make the porting non-destructive?

>#ifdef Plan9
>#define void unsigned char
>#endif

not really, as a global define. it's legal to write
	Type *t;

	t = malloc(sizeof(*t));
and that won't work unless malloc returns a real void* (only
void* is compatible with all types of data pointer). it's similar
for void* as a formal parameter; it accepts any type of data pointer
as an actual parameter, but uchar* will not.

Re: [9fans] porting help please (gcc void pointer handling)

[Fernan Bolando]

On Wed, Sep 9, 2009 at 11:35 PM, erik quanstrom<quanstro@quanstro.net> wrote:
>> gcc happily compiles a definition like
>> #define CT_v249       ((void*)startLabel+464)
>>
>
> no it doesn't.
>
> $ cat > x.c
> char    *startlab;
> long long offset = (void*)startlab+464;
> [...]
> $ gcc -Wall x.c
> x.c:2: error: initializer element is not constant
> [...]
>
I may not have posted the appropriate section of the code but, the app
that I am porting have a bunch of those and I always get for all the
section that calls those defines
AsciiTab.hc.c:140[stdin:1124] pointer addition not fully declared: VOID



After googling I found this in wikipedia
"Pointer arithmetic cannot be performed on void pointers because the
void type has no size, and thus the pointed address can not be added
to, although gcc and other compilers will perform byte arithmetic on
void* as a non-standard extension. For working 'directly' with bytes
they usually cast pointers to BYTE*, or unsigned char* if BYTE isn't
defined in the standard library used."

So I assumed that was the problem



-- 
http://www.fernski.com

Re: [9fans] porting help please (gcc void pointer handling)

[Greg Comeau]

In article <1d5d51400909090843h2905057et1a60474702faf0df@mail.gmail.com>,
Fernan Bolando <fernanbolando@mailc.net> wrote:
>>> gcc happily compiles a definition like
>>> #define CT_v249 =A0 =A0 =A0 ((void*)startLabel+464)
>I may not have posted the appropriate section of the code but, the app
>that I am porting have a bunch of those and I always get for all the
>section that calls those defines
>AsciiTab.hc.c:140[stdin:1124] pointer addition not fully declared: VOID

That looks right

>After googling I found this in wikipedia
>"Pointer arithmetic cannot be performed on void pointers because the
>void type has no size, and thus the pointed address can not be added
>to, although gcc and other compilers will perform byte arithmetic on
>void* as a non-standard extension. For working 'directly' with bytes
>they usually cast pointers to BYTE*, or unsigned char* if BYTE isn't
>defined in the standard library used."
>
>So I assumed that was the problem

Yes, the diagnostic and the gist of the wikipedia entry are correct:
there is nothing to scale up a void * with, so normally such an
operation has no meaning.  But it's still not clear what you're
eventually trying to do in/with the code in question, so changing
the cast to an unsigned char * cast may not necessarily be the solution
and/or best solution.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] porting help please (gcc void pointer handling)

[Charles Forsyth]

you might consider using a sed script to change the CT_.* style #defines,
and run the sed script from the mkfile/makefile, so although the
porting is (in your sense) `destructive' it's done by changing the
original source file automatically. you could sed (say) from a .h.orig to a .h
using a single rule.

Re: [9fans] porting help please (gcc void pointer handling)

[Fernan Bolando]

On Thu, Sep 10, 2009 at 12:08 AM, Charles Forsyth<forsyth@terzarima.net> wrote:
> you might consider using a sed script to change the CT_.* style #defines,
> and run the sed script from the mkfile/makefile, so although the
> porting is (in your sense) `destructive' it's done by changing the
> original source file automatically. you could sed (say) from a .h.orig to a .h
> using a single rule.
>

I am trying to port nhc98 the bytecode haskell compiler.
I am hoping to avoid changing those definition because I think those
are generated by the
haskell compiler and then fed to the C compiler. So there are a whole
bunch of them.

If I change those and assuming everything works. Every time I use the
haskell compiler it will
generate the same style of codes and the same set of compile issue in
C compiler phase.

so I guess some sort of wrapper script for the pcc is easiest option.

thanks.

--
http://www.fernski.com

Re: [9fans] porting help please (gcc void pointer handling)

[Charles Forsyth]

>I am trying to port nhc98 the bytecode haskell compiler.

i see. that makes it much harder to try my suggestion.
i wonder why the compiler doesn't generate char* (or unsigned char*) for
those defines? perhaps directly changing that would be better.
if it needed a void* result then

#define CT_v249	((void*)((char*)startLabel+464))

would make the addition portable (between byte-oriented machines, but that
was anyway assumed) and leave the result void*

Re: [9fans] porting help please (gcc void pointer handling)

[ron minnich]

On Wed, Sep 9, 2009 at 9:27 AM, Fernan Bolando<fernanbolando@mailc.net> wrote:

> I am trying to port nhc98 the bytecode haskell compiler.
> I am hoping to avoid changing those definition because I think those
> are generated by the
> haskell compiler and then fed to the C compiler. So there are a whole
> bunch of them.


maybe it's time to talk to the nhc98 guys and point out the problem?
Seems like a fix ought to be simple.

ron

Re: [9fans] porting help please (gcc void pointer handling)

[Fernan Bolando]

On Thu, Sep 10, 2009 at 2:17 AM, ron minnich <rminnich@gmail.com> wrote:
> On Wed, Sep 9, 2009 at 9:27 AM, Fernan Bolando<fernanbolando@mailc.net> wrote:
>
>> I am trying to port nhc98 the bytecode haskell compiler.
>> I am hoping to avoid changing those definition because I think those
>> are generated by the
>> haskell compiler and then fed to the C compiler. So there are a whole
>> bunch of them.
>
>
> maybe it's time to talk to the nhc98 guys and point out the problem?
> Seems like a fix ought to be simple.

Yes,  I recieved a few suggestions from Malcolm of nhc98.
Thanks for every who helped verify this.

fernan


--
http://www.fernski.com

Re: [9fans] porting help please (gcc void pointer handling)

[Greg Comeau]

In article <1d5d51400909090927u2a4e6742k9614b79df841d3b6@mail.gmail.com>,
Fernan Bolando <fernanbolando@mailc.net> wrote:
>I am trying to port nhc98 the bytecode haskell compiler.
>I am hoping to avoid changing those definition because I think those
>are generated by the
>haskell compiler and then fed to the C compiler. So there are a whole
>bunch of them.

So I'll wager a wild guess that there is a #if/def that controls
whether the compiling C compiler is gcc or not?  IOWs, that may cause
it to emit a more standard form of the #define?

>If I change those and assuming everything works. Every time I use the
>haskell compiler it will
>generate the same style of codes and the same set of compile issue in
>C compiler phase.
>
>so I guess some sort of wrapper script for the pcc is easiest option.

I'll go on another limb and wager even further that there is parens
-- or something -- mising from the #define in the first place.
(so instead of (void*)blah+99 this ((void*)(blah+99))) etc.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] porting help please (gcc void pointer handling)

[Greg Comeau]

In article <1d5d51400909090803n4c4d5b7ewba9dfe0573d02495@mail.gmail.com>,
Fernan Bolando <fernanbolando@mailc.net> wrote:
>On Wed, Sep 9, 2009 at 4:36 PM, Greg Comeau<comeau@panix.com> wrote:
>> In article <1d5d51400909080844q1bee4c3s114ccc5e51ce52f5@mail.gmail.com>,
>> Fernan Bolando <fernanbolando@mailc.net> wrote:
>>>...error: initializer is not a constant: F0_Prelude_46primLeave
>>>--h file ---
>>>#define VAP_TAG =A01
>>>#define WORDSHIFT =A05
>>>#define WORDSIZE =A0 (1<<WORDSHIFT)
>>>#define WORDMASK =A0 (WORDSIZE-1)
>>>#define NS =A0 =A0 =A0 =A0 (WORDSIZE>>3)
>>>#define ZAP_BIT =A0 =A0(1L<<(WORDSIZE-1))
>>>-- c file ----
>>>unsigned F0_Prelude_46primLeave[] =3D {
>>> =A0CAPTAG(FN_Prelude_46primLeave,1)
>>>#ifdef PROFILE
>>>, useLabel(PROF_primLeave)
>>>, 0
>>>, 0
>>>, 0
>>>#endif
>>
>> The initializers to some things need to be constants.
>> In your case, it appears that either CAPTAG or useLabel (or both)
>> have ended up not being #define'd. =A0Probably the header they are
>> #define'd in is not being #include'd (you don't show it above,
>> but then you don't show enough of your code to even reproduce it).
>>
>> On a relate note, you can see the results of preprocessing
>> from pcc by using the -E and/or -P options, that way you
>> can see whether the macro ended up getting substituted
>> and what it was substituted to -- or not in your case.
>> Some compilers also have options which will emit the trail of
>> files #include'd but I don't see that option for pcc.
>
>gcc happily compiles a definition like
>#define CT_v249	((void*)startLabel+464)
>
>is it valid just to add to make the porting non-destructive?
>
>#ifdef Plan9
>#define void unsigned char
>#endif

It could be however, two issues:
1) I don't see how this has anything to do with the original problem
   (so I assume it doesn't).
2) There are other uses of void where doing that may not be what you
   want it to be:

    void foo(void);

becomes:

   unsigned char foo(unsigned char);

doubtful this is your intent for either the argument list or
return value.

However, it may or may not make sense for you to typedef a type
that is either void * or char *.  You don't make it clear what
problem is being solved by your question though, so it's unclear
if offering these ideas are just solutions looking for (non)problems
or not :)

Also, re non-destructive, it's unclear what you mean?
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?