Compile errors: Curses.c...Perl5.8...AIX

[mailbox]

In trying to build the Perl Curses module (Curses-1.12)
under Perl 5.8 on a new AIX box I came up against the
limits of my C as well as my Unix knowledge. The thing
had built okay under Perl 5.6 on the old AIX system.
The only co-worker within reach who seems to know more
C than I do had no clue either.

I have put the error messages and excerpt from the
source file in question at
http://cpacker.org/aa.txt

The only thing that looks odd to me in perlio.h on the
error lines is "pTHX_" -- which isn't followed by a comma.
Looking around for what it might be, I see there are these
lines in perl.h in the same directory:

# define pTHX_ pTHX,
which is preceded a few lines back by

# define pTHX register PerlInterpreter *my_perl PERL_UNUSED_DECL
which is REALLY out of my league...

Interpretation welcomed.

 

[mailbox]

This is totally off-topic in comp.lang.c. I don't know about the other

Oh yeah? Please explain.

 

[CBFalconer]

Oh yeah? Please explain.

It shouldn't be here.

 

[Michael Wojcik]

I'm afraid you did not. There are at least two "source file
in question", and you excerpted only one area with errors from only
one of them.

When an implementation emits several diagnostics, it is often the
case that at least some of the later ones are "cascade errors"
caused by earlier ones. Begin your diagnosis with the *first*
error, not the second-to-last one.

C macros that do not use the token-pasting (##) or stringizing (#)
operators perform simple text substitution; unparameterized macros
perform only *literal* text substitution of the macro body for the
macro name. Here it should be obvious that:

pTHX_

becomes

register PerlInterpreter *my_perl PERL_UNUSED_DECL,

Unfortunately, strictly speaking we can't interpret this further
because we don't know what PERL_UNUSED_DECL is. It's likely another
macro name, because the only other thing it could be here is an
identifier, which would be a constraint violation (I think) in this
case.

Aside from PERL_UNUSED_DECL, this appears to be a declaration of the
identifer "my_perl" as a pointer to a PerlInterpreter (probably an
identifier from a previous typedef), and the PerlInterpreter has the
register storage class (which is a bit bizarre and very likely
completely useless on the vast majority of implementations). Actually,
since it's illegal to take the address of an object with register
storage class, a pointer to a register-sc object can't be used to
refer to an object of that type. I don't know what this is meant to
accomplish.

This is totally off-topic in comp.lang.c. I don't know about the other
groups because I don't read them.

I disagree. It's a question about the meaning of certain lines of C
code which do not appear to involve any nonstandard keywords or other
language "extensions", and about the probable meaning of diagnostics
issued by one implementation when compiling that code. The former
seems entirely topical for c.l.c to me, and the latter at least
arguably topical; even if it is implementation-dependant, we do treat
some questions of "typical implementations" here as topical.

I am setting followups to c.l.p.m and c.u.a.

On the other hand, it seems to me completely OT for c.l.p.m, since
it's a question about, at best, part of a specific Perl implementa-
tion, and not the Perl language or programs written in it. Indeed,
it's just the sort of question we regularly boot out of c.l.c for
just that reason.

Nor is it topical for c.u.a, as its only connection to AIX is that
happens to be the platform hosting the C implementation being used.

Followups reset.

 

[mailbox]

I disagree. It's a question about the meaning of certain lines of C
code which do not appear to involve any nonstandard keywords or other
language "extensions", and about the probable meaning of diagnostics
issued by one implementation when compiling that code. The former
seems entirely topical for c.l.c to me, and the latter at least
arguably topical; even if it is implementation-dependant, we do treat
some questions of "typical implementations" here as topical.


On the other hand, it seems to me completely OT for c.l.p.m, since
it's a question about, at best, part of a specific Perl implementa-
tion, and not the Perl language or programs written in it. Indeed,
it's just the sort of question we regularly boot out of c.l.c for
just that reason.

Nor is it topical for c.u.a, as its only connection to AIX is that
happens to be the platform hosting the C implementation being used.

Thanks for the analysis of the material I supplied. But why should I
have problems anyway? The Curses package is from CPAN and built okay
under Perl 5.6. There's nothing at the CPAN Web site that suggests that
Curses will not build under Perl 5.8. And from what I know so far,
there should be no reason to question why the Makefile on the new AIX
system shows the default C compiler as cc_r, whereas on our old AIX
system it was cc.

In other words, the problem didn't begin with doubtful C code that I
wrote. The C code was from an established vendor and built and executed
successfully in one environment but wouldn't even build in another. For
me to know in advance what single newsgroup to post in under these
circumstances would have been to know what variables were being
confounded when our sysadmin upgraded to new hardware and
software...and therefore to know the solution to the problem...and not
need to post at all...

 

[Michael Wojcik]

Thanks for the analysis of the material I supplied. But why should I
have problems anyway? The Curses package is from CPAN and built okay
under Perl 5.6.

That, I'm afraid, *is* an off-topic question for comp.lang.c. We have
no relationship to CPAN or Perl or Perl-Curses. You'll have to
address that question to the maintainer of the package.

In other words, the problem didn't begin with doubtful C code that I
wrote.

But that's all we can comment on here.

The C code was from an established vendor and built and executed
successfully in one environment but wouldn't even build in another.

Alas, this is all too common with C source. Many an "established
vendor" cannot write compliant C to save their lives. Your faith
in the code may be ill-founded.

For me to know in advance what single newsgroup to post in under these
circumstances would have been to know what variables were being
confounded when our sysadmin upgraded to new hardware and
software...and therefore to know the solution to the problem...and not
need to post at all...

This argument does not hold water, I'm afraid. There are a great
many examples of on-topic questions posted to newsgroups - and
thus of people who are able to determine where the problem lies,
yet unable to determine what it is, much less how to solve it.

At any rate, I'm unsure what your complaint is. You cross-posted to
various groups, including c.l.c. A few c.l.c participants felt your
query was off-topic and said so; I felt it was not, and responded in
the context of the C language. (Though, as I noted, I might have
been able to be more helpful had you supplied better diagnostic
information on your web page.) All of that seems to me entirely
within normal and accepted Usenet practice.

--
Michael Wojcik (e-mail address removed)

Against all odds, over a noisy telephone line, tapped by the tax authorities
and the secret police, Alice will happily attempt, with someone she doesn't
trust, whom she can't hear clearly, and who is probably someone else, to
fiddle her tax return and to organise a coup d'etat, while at the same time
minimising the cost of the phone call. -- John Gordon

 

[mailbox]

But that's all we can comment on here.

Oh really? Isn't there a comp.lang.c.moderated
for you strait-jacketed types? Who let you, and
especially Mac and CBFalconer, out of that cage?
It's universally acknowledged that technical
newsgroups are the place to get answers. They may
perhaps come to be populated by a few regulars
who enjoy debating the finer points of issues
that are over the heads -- and beyond the immediate
concerns -- of the rest of us. But the rest of us
know that more often than not these very regulars,
in MOST technical newsgroups, are glad to share
their knowledge. Therefore there is no such thing
as a query, made in good faith, that doesn't BELONG,
no matter how clueless. Let me say it in different
words: There is no such thing as an off-topic
technical query. We're not talking here about rants
about politics or Jesus, for christsake. If participants
in a technical newsgroup don't know the answer to
a query, they are actually free to ignore it, believe
it or not. Let the one who queries learn that it's the
wrong newsgroup by seeing no responses, or a
more helpful "The odds are," -- probabilities
matter here -- "nobody here KNOWS that, because..."

 

[Keith Thompson]

Oh really? Isn't there a comp.lang.c.moderated
for you strait-jacketed types? Who let you, and
especially Mac and CBFalconer, out of that cage?
It's universally acknowledged that technical
newsgroups are the place to get answers. They may
perhaps come to be populated by a few regulars
who enjoy debating the finer points of issues
that are over the heads -- and beyond the immediate
concerns -- of the rest of us. But the rest of us
know that more often than not these very regulars,
in MOST technical newsgroups, are glad to share
their knowledge. Therefore there is no such thing
as a query, made in good faith, that doesn't BELONG,
no matter how clueless. Let me say it in different
words: There is no such thing as an off-topic
technical query. We're not talking here about rants
about politics or Jesus, for christsake. If participants
in a technical newsgroup don't know the answer to
a query, they are actually free to ignore it, believe
it or not. Let the one who queries learn that it's the
wrong newsgroup by seeing no responses, or a
more helpful "The odds are," -- probabilities
matter here -- "nobody here KNOWS that, because..."

You are mistaken, sir.

Though I didn't witness it myself, I understand that several years ago
our sibling newsgroup, comp.lang.c++, was nearly destroyed by the
volume of off-topic postings. My participation here in comp.lang.c
leads me to believe that the same thing could easily happen here.

This newsgroup, by general consensus, is for discussion of the C
programming language as defined by the ANSI and ISO standards, and, in
historical context, by K&R and earlier documents. There is no
shortage of things to talk about within those boundaries; even if
off-topic and system-specific discussions are ignored, this is a
high-volume newsgroup. There are plenty of newsgroups for
system-specific issues.

There's no real difference in subject matter between comp.lang.c and
comp.lang.c.moderated. The difference is that clcm has a higher
signal-to-noise ratio, lower volume, and longer latency.

 

[Default User]

Oh really? Isn't there a comp.lang.c.moderated
for you strait-jacketed types? Who let you, and
especially Mac and CBFalconer, out of that cage?

This is an easy *plonk*.




Brian

 

[Flash Gordon]

Oh really? Isn't there a comp.lang.c.moderated
for you strait-jacketed types?

No, that is a group for people who want a fully moderated group with all
the delays that introduces.

> Who let you, and
especially Mac and CBFalconer, out of that cage?
It's universally acknowledged that technical
newsgroups are the place to get answers.

Yes, but only to the questions that are ON topic.

> They may
perhaps come to be populated by a few regulars
who enjoy debating the finer points of issues
that are over the heads -- and beyond the immediate
concerns -- of the rest of us.

Yes, plenty of that goes on. We also get plenty of helpful answers for
people of all levels.

> But the rest of us
know that more often than not these very regulars,
in MOST technical newsgroups, are glad to share
their knowledge.

CBFalconer and others DO share their knowledge, and I for one am
grateful for this.

> Therefore there is no such thing
as a query, made in good faith, that doesn't BELONG,
no matter how clueless.

Wrong. If it is off topic then it belongs else where in a group
dedicated to whatever the topic of the question is or in one of the
..misc groups if there is nowhere better. We also have comp.programming
which I believe covers a far wider range. Although, of course, you
should check what is on topic their before posting to it.

> Let me say it in different
words: There is no such thing as an off-topic
technical query.

So tell me, if I have exactly 100g of C12 and 0.004g of C14 what volume
of O2 do I require at STP to react with all of the carbon leaving no
excess oxygen and what mass of CO2 will this give me? How can I write a
COBOL program to calculate the answer?

That's a technical question, but even you might agree that it is
completely OFF topic even though it mentions C and programming and even
though people here could probably manage to produce a Cobol program that
solved the problem.

> We're not talking here about rants
about politics or Jesus, for christsake. If participants
in a technical newsgroup don't know the answer to
a query, they are actually free to ignore it, believe
it or not. Let the one who queries learn that it's the
wrong newsgroup by seeing no responses, or a
more helpful "The odds are," -- probabilities
matter here -- "nobody here KNOWS that, because..."

No, the way for someone to learn that it is the wrong group is for them
TO BE TOLD that it is the wrong group. Or better yet, for them to do the
polite thing and actually INVESTIGATE the group before posting.

 

[Alan Balmer]

Oh really? Isn't there a comp.lang.c.moderated
for you strait-jacketed types? Who let you, and
especially Mac and CBFalconer, out of that cage?

My, my. And after Michael went out of his way to give you what help he
could by extracting everything that was even close to topical.

There is indeed a comp.lang.c.moderated, and it's subject matter is
the same. The main difference is much less traffic and a much longer
turnaround. Because of the lower traffic, they may even be a bit more
tolerant of off-topic subjects.

It's universally acknowledged that technical
newsgroups are the place to get answers. They may
perhaps come to be populated by a few regulars
who enjoy debating the finer points of issues
that are over the heads -- and beyond the immediate
concerns -- of the rest of us. But the rest of us
know that more often than not these very regulars,
in MOST technical newsgroups, are glad to share
their knowledge. Therefore there is no such thing
as a query, made in good faith, that doesn't BELONG,
no matter how clueless. Let me say it in different
words: There is no such thing as an off-topic
technical query.

OK, sci.geo.mineralogy is a technical newsgroup, and they need some
increase in volume. Post there.

We're not talking here about rants
about politics or Jesus, for christsake. If participants
in a technical newsgroup don't know the answer to
a query, they are actually free to ignore it, believe
it or not. Let the one who queries learn that it's the
wrong newsgroup by seeing no responses, or a
more helpful "The odds are," -- probabilities
matter here -- "nobody here KNOWS that, because..."

The one who queries can also learn it's the wrong newsgroup by being
told "It's the wrong newsgroup."

The expertise available on this newsgroup is impressive by any
standard. However, it is a very busy newsgroup, as you would know if
you had monitored it before posting, and must be rather hard-nosed on
topicality to avoid being completely swamped.

 

[CBFalconer]

Oh really? Isn't there a comp.lang.c.moderated
for you strait-jacketed types? Who let you, and
especially Mac and CBFalconer, out of that cage?
It's universally acknowledged that technical
newsgroups are the place to get answers. They may
perhaps come to be populated by a few regulars
who enjoy debating the finer points of issues
that are over the heads -- and beyond the immediate
concerns -- of the rest of us. But the rest of us
know that more often than not these very regulars,
in MOST technical newsgroups, are glad to share
their knowledge. Therefore there is no such thing
as a query, made in good faith, that doesn't BELONG,
no matter how clueless. Let me say it in different
words: There is no such thing as an off-topic
technical query. We're not talking here about rants
about politics or Jesus, for christsake. If participants
in a technical newsgroup don't know the answer to
a query, they are actually free to ignore it, believe
it or not. Let the one who queries learn that it's the
wrong newsgroup by seeing no responses, or a
more helpful "The odds are," -- probabilities
matter here -- "nobody here KNOWS that, because..."

Obviously you are not interested in discussing the C language,
which is the topic of this newsgroup, but prefer to argue about
topicality. I, for one, will not be noticing you any more. PLONK.

 

[Michael Wojcik]

Oh really? Isn't there a comp.lang.c.moderated
for you strait-jacketed types?

No, comp.lang.c.moderated is for those who want a moderated newsgroup
in which to discuss C. That's entirely different from maintaining
topicality on a high-volume unmoderated newsgroup. And I'm afraid I
don't own a straitjacket.

Who let you, and especially Mac and CBFalconer, out of that cage?

Insulting the regulars is rarely an ideal way to get help. I must
say that I've really come to regret helping you. It's not a mistake
I'll make again.

It's universally acknowledged that technical
newsgroups are the place to get answers.

It most certainly is not, as anyone even vaguely familiar with Usenet
would know. Technical newsgroups are often a place to get answers to
on-topic questions. Rejecting questions on the grounds of topicality
is a long-standing and widespread practice.

In any event, claiming something is true because it's "universally
acknowledged" is a logical fallacy (a combination of argumentum ad
ignorantiam and converse accident), so this argument holds no water.

Therefore there is no such thing
as a query, made in good faith, that doesn't BELONG,
no matter how clueless.

A fascinating take on topicality. I've never encountered anyone
else who shares it.

 

[Mac]

On Sat, 20 Aug 2005 19:52:46 +0000, Michael Wojcik wrote:

[snip]

I disagree. It's a question about the meaning of certain lines of C
code which do not appear to involve any nonstandard keywords or other
language "extensions", and about the probable meaning of diagnostics
issued by one implementation when compiling that code. The former seems
entirely topical for c.l.c to me, and the latter at least arguably
topical; even if it is implementation-dependant, we do treat some
questions of "typical implementations" here as topical.

Well, build problems are seldom on-topic here. They are usually not
caused by problems with the C-code as such, but by problems with the
build setup. Perhaps I should have made more of an effort to redirect,
(for example, perhaps there is a relevant mailing list out there
somewhere) but I stand by the off-topic-ness in CLC.

On the other hand, it seems to me completely OT for c.l.p.m, since it's
a question about, at best, part of a specific Perl implementa- tion, and
not the Perl language or programs written in it. Indeed, it's just the
sort of question we regularly boot out of c.l.c for just that reason.

Nor is it topical for c.u.a, as its only connection to AIX is that
happens to be the platform hosting the C implementation being used.

It may well be that the question is off-topic in all three of the chosen
groups. As I said, I don't know because I don't read them.

--Mac

 

[Mac]

Oh yeah? Please explain.

I'm sorry, I was rather terse. Read the clc FAQ, or "welcome to CLC" or
something like that. You'll get the picture. Here are URL's:

http://www.eskimo.com/~scs/C-faq/top.html
http://groups-beta.google.com/group/comp.lang.c/msg/450012c33ebc1119?hl=en&

This newsgroup is for discussion of the C language as defined by the
relevant ANSI or ISO standards. Your question deals with a build problem
for a well known package.

My guess is that you will get much better expert help from people who use
your platform, people who deal with curses, or people who deal with Perl.
There is some possibility that you could find help at
comp.unix.programmer, but check first before posting.

Anyway, good luck with your problem. Build problems can be very
frustrating!

I'm posting to all three groups without setting followups this time since
it now appears likely that the question is not entirely topical in any of
the groups.

--Mac

 

[Michael Wojcik]

Well, build problems are seldom on-topic here.

While that may be useful as a heuristic, it doesn't constitute much
of an argument.

They are usually not
caused by problems with the C-code as such, but by problems with the
build setup.

Perhaps (though I wouldn't bet on it). However, my argument was
that the OP's question was not about a build issue, but about certain
apparently-legal C constructs and what they meant. It was presented
in the context of a build issue, but the question about what those
constructs meant was independent of implementation.

That said, of course people can reasonably disagree on what's topical,
and I don't believe we need to agree in this case.

--
Michael Wojcik (e-mail address removed)

As always, great patience and a clean work area are required for fulfillment
of this diversion, and it should not be attempted if either are compromised.
-- Chris Ware

 

[Mac]

While that may be useful as a heuristic, it doesn't constitute much
of an argument.

Hmm. I have to agree, considering the way I phrased it.

Perhaps (though I wouldn't bet on it). However, my argument was
that the OP's question was not about a build issue, but about certain
apparently-legal C constructs and what they meant. It was presented
in the context of a build issue, but the question about what those
constructs meant was independent of implementation.

OK. I accept that. ;-)

That said, of course people can reasonably disagree on what's topical,
and I don't believe we need to agree in this case.

Spoken like a true gentleman.

Best regards,
Mac

 

[Dave Thompson]

On 20 Aug 2005 19:52:46 GMT, (e-mail address removed) (Michael Wojcik)
wrote:

pTHX_ [is apparently a macro which] becomes

register PerlInterpreter *my_perl PERL_UNUSED_DECL,

Unfortunately, strictly speaking we can't interpret this further
because we don't know what PERL_UNUSED_DECL is. It's likely another
macro name, because the only other thing it could be here is an
identifier, which would be a constraint violation (I think) in this
case.

Actually it's a syntax error. But the required response (diagnostic)
is the same for syntax error or constraint violation.

Aside from PERL_UNUSED_DECL, this appears to be a declaration of the
identifer "my_perl" as a pointer to a PerlInterpreter (probably an
identifier from a previous typedef), and the PerlInterpreter has the
register storage class (which is a bit bizarre and very likely
completely useless on the vast majority of implementations). Actually,
since it's illegal to take the address of an object with register
storage class, a pointer to a register-sc object can't be used to
refer to an object of that type. I don't know what this is meant to
accomplish.

This is rather confused but I think not. _Qualifiers_ (const,
volatile, and C99 restrict) apply where they appear, at different
levels of pointerness or functionosity. _Storage class_ (register,
auto, static, extern, and quasi-SC typedef) apply to the declared
identifier(s), regardless of where (in the s-q-list) it appears.

Barring perverted/ing macros, this declares my_perl as a register
pointer to a PerlInterpreter, which is presumably a typedef as you
say. Whether specifying register is actually helpful (or even harmful)
on many or particular implementations especially modern ones is a
separate issue, but it is at least meaningful.

- David.Thompson1 at worldnet.att.net

 

[Michael Wojcik]

This is rather confused but I think not. _Qualifiers_ (const,
volatile, and C99 restrict) apply where they appear, at different
levels of pointerness or functionosity. _Storage class_ (register,
auto, static, extern, and quasi-SC typedef) apply to the declared
identifier(s), regardless of where (in the s-q-list) it appears.

Thanks for the correction, Dave. I thought I must be missing
something - it didn't occur to me that I was treating "register" as
a qualifier rather than as an sc-specifier.