_JoyDef and _Control

[Richard Bos]

Another question if I may, I'm running into a lot of other errors
which have to do with C syntax and such, is it ok to post questions on
those issues here? (nothing to do with compilers)

Sure. As long as it's ISO C, and not a problem with, say, the POSIX
libraries, comp.lang.c is the place for it. And if not, we'll usually
know where the place is.

Richard

 

[Richard Heathfield]

Displacer said:

Another question if I may, I'm running into a lot of other errors
which have to do with C syntax and such, is it ok to post questions on
those issues here? (nothing to do with compilers)

Yes, that's fine. Obviously, it makes sense to try to work it out yourself
first, using your C book as a guide (if it's a good book!), but to post
questions about C syntax is very common and widely accepted here. Nobody -
er, make that "almost nobody"! - will criticise you for asking C questions
in a C newsgroup.

 

[Richard]

As I noted in my reply, and as Mr. Heathfield also implied, Mr.
McCormack is a troll, the post you are referring to being but one of
many damning pieces of evidence against Mr. McCormack. Please do not
interpret Mr. McCormack's behavior as typical of comp.lang.c posters.

Except McCormack's reply, albeit tongue in cheek and inflammatory, was
right about one thing. This was not a C question : it was about
compiling a platform specific DOS game using a specific compiler and
platform compiler specific subsystem specific libraries. Off Topic.

 

[Displacer]

Displacer said:



Yes, that's fine. Obviously, it makes sense to try to work it out yourself
first, using your C book as a guide (if it's a good book!), but to post
questions about C syntax is very common and widely accepted here. Nobody -
er, make that "almost nobody"! - will criticise you for asking C questions
in a C newsgroup.

Yes, thats what I'm doing, and by looking over someone elses source
with a reference book at my side I'm learning quite a bit.

With that said it appears this source is relying on the compiler to
declare some of its code for it (guess this was common in the past)
anyway heres what I have in the .h file:

#define LEVELZONESIZE 250000

And in the .c file:

static levelzonesize=LEVELZONESIZE;

which triggers a warning. Should I make this:

static int levelzonesize=LEVELZONESIZE;
or
static long levelzonesize=LEVELZONESIZE;

or does it matter which?

 

[Displacer]

Except McCormack's reply, albeit tongue in cheek and inflammatory, was
right about one thing. This was not a C question : it was about
compiling a platform specific DOS game using a specific compiler and
platform compiler specific subsystem specific libraries. Off Topic.

Yes I know now and have spanked myself accordingly

 

[Richard Heathfield]

Displacer said:

anyway heres what I have in the .h file:

#define LEVELZONESIZE 250000

And in the .c file:

static levelzonesize=LEVELZONESIZE;

which triggers a warning. Should I make this:

static int levelzonesize=LEVELZONESIZE;
or
static long levelzonesize=LEVELZONESIZE;

C guarantees that ints can represent values in the range -32767 to +32767 -
you might get a wider range or you might not. But long ints are guaranteed
to represent values in the range -2147483647 to +2147483647.

So the answer is: the second one.

 

[Displacer]

Displacer said:



C guarantees that ints can represent values in the range -32767 to +32767 -
you might get a wider range or you might not. But long ints are guaranteed
to represent values in the range -2147483647 to +2147483647.

So the answer is: the second one.

Thats what I thought as the define was for 250000
Thanks!

 

[Keith Thompson]

With that said it appears this source is relying on the compiler to
declare some of its code for it (guess this was common in the past)
anyway heres what I have in the .h file:

#define LEVELZONESIZE 250000

And in the .c file:

static levelzonesize=LEVELZONESIZE;

which triggers a warning.

In C90 and earlier, a declaration with no type defaults to int
("implicit int"). C99 removed this feature, and it wasn't a very good
idea even in C90.

Should I make this:

static int levelzonesize=LEVELZONESIZE;
or
static long levelzonesize=LEVELZONESIZE;

or does it matter which?

It matters which, but it's not clear which you should use. If you
want to be sure levelzonesize can hold the value 250000 on all
platforms, you need to declare it as long; int is only guaranteed to
be able to hold values in the range -32767 .. +32767. But if other
code in the program assumes levelzonesize is an int, for example:

printf("levelzonesize = %d\n", levelzonesize);

then changing levelzonesize to long could break such code.

The safest approach is to make levelzonesize a long, then go through
the entire program and check all references to it.

 

[Rod Pemberton]

In C90 and earlier, a declaration with no type defaults to int
("implicit int"). C99 removed this feature, and it wasn't a very good
idea even in C90.

IMO, the problem wasn't "implicit int" but the LALR(1) conflict created when
typedef's were added to C.


Rod Pemberton

 

[Keith Thompson]

IMO, the problem wasn't "implicit int" but the LALR(1) conflict created when
typedef's were added to C.

Who says there can't be more than one problem?

In my opinion, taking advantage of C90's permission to omit the
keyword "int" in a declaration is a bad idea. It's always better to
specify "int" explicitly. One reason is that using implicit int makes
code incompatible with C99. Another is that avoiding implicit int
makes the code clearer and more explicit.

(I'm not saying that supporting implicit int in the C90 standard was a
bad idea; it was necessary to support existing code.)

The syntactical issues created by typedef (which was added long before
C90) are another problem; I don't see how that's related to implicit
int.

 

[Rod Pemberton]

[...]
With that said it appears this source is relying on the compiler to
declare some of its code for it (guess this was common in the past)
anyway heres what I have in the .h file:

#define LEVELZONESIZE 250000

And in the .c file:

static levelzonesize=LEVELZONESIZE;

which triggers a warning.

In C90 and earlier, a declaration with no type defaults to int
("implicit int"). C99 removed this feature, and it wasn't a very good
idea even in C90.

IMO, the problem wasn't "implicit int" but the LALR(1) conflict created when
typedef's were added to C.

Who says there can't be more than one problem?

In my opinion, taking advantage of C90's permission to omit the
keyword "int" in a declaration is a bad idea. It's always better to
specify "int" explicitly. One reason is that using implicit int makes
code incompatible with C99. Another is that avoiding implicit int
makes the code clearer and more explicit.

I agree.

But, if it weren't for typedef's, we'd still have a default type of implicit
ints, because they don't create any serious language issues without
typedef's.

Also, if we want to completely eliminate ambiguity in the grammar (true
LALR(1)) we need two more tokens. One for an explicitly terminated if and
another for the use of a typedef as a type qualifier since we can't use
'typedef' itself (i.e., typedefname).

As I said to Torek (using an example of his), it's very easy to fix the
grammar:

#define typedefname ut
typedef int x;
int *a;
ut x *b; /* typedefname x *b */
int **p = &b;

void f(x); /* int x */
void f(ut x); /* typedefname x */

It's even portable:

#define ut

(I'm not saying that supporting implicit int in the C90 standard was a
bad idea; it was necessary to support existing code.)

The syntactical issues created by typedef (which was added long before
C90) are another problem; I don't see how that's related to implicit
int.

It was my understanding (?), that implicit int's were removed to help solve
the ambiguities of a determining an implicit int versus a typedef.

C++ "GETTING RID OF DEFAULT INT" 3)b) :
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0358.asc


From what I'm able to locate, it appears that typedef's were added after
implicit int's.

C in 1977 or so, typedef's added:
http://www.darwinsys.com/history/hist.html

C in 1974-5 has implicit int's, but no typedef's ("13. Implicit
declarations"):
http://cm.bell-labs.com/cm/cs/who/dmr/cman.pdf
http://cm.bell-labs.com/cm/cs/who/dmr/cman74.pdf


Rod Pemberton

 

[Keith Thompson]

I agree.

But, if it weren't for typedef's, we'd still have a default type of implicit
ints, because they don't create any serious language issues without
typedef's.

Also, if we want to completely eliminate ambiguity in the grammar (true
LALR(1)) we need two more tokens. One for an explicitly terminated if and
another for the use of a typedef as a type qualifier since we can't use
'typedef' itself (i.e., typedefname).

As I said to Torek (using an example of his), it's very easy to fix the
grammar:

#define typedefname ut
typedef int x;
int *a;
ut x *b; /* typedefname x *b */
int **p = &b;

void f(x); /* int x */
void f(ut x); /* typedefname x */

It's even portable:

#define ut

(Why "ut"?)

Yes, I suppose requiring "typedefname foo" rather than just "foo"
would probably solve the syntax problem -- though it would largely
defeat some of the purpose of having typedefs in the first place. At
least nobody would bother with:

typedef struct foo { ... } foo;

if it only meant being to refer to the type as either "struct foo" or
"typedefname foo".

It was my understanding (?), that implicit int's were removed to help solve
the ambiguities of a determining an implicit int versus a typedef.

C++ "GETTING RID OF DEFAULT INT" 3)b) :
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0358.asc

It's always been my assumption that implicit int was removed just
because it's ugly (my word, not the committee's). The web page you
cited (which, BTW, discusses C++ not C, but the issues are very
similar) gives 4 major reasons for getting rid of implicit int. Two
of them have nothing to do with parsing issues, and IMHO those are the
strongest reasons.

From what I'm able to locate, it appears that typedef's were added after
implicit int's.

C in 1977 or so, typedef's added:
http://www.darwinsys.com/history/hist.html

C in 1974-5 has implicit int's, but no typedef's ("13. Implicit
declarations"):
http://cm.bell-labs.com/cm/cs/who/dmr/cman.pdf
http://cm.bell-labs.com/cm/cs/who/dmr/cman74.pdf

Right, so C has had implicit int since time immemorial, and typedef
since 1977 or so. It survived from 1977 to 1999 with both typedef and
implicit int. And removing implicit int has not, as far as I can
tell, completely solved the typedef problem. For example,
"sizeof(foo)" goes through a different grammatical production
depending on whether "foo" is currently a typedef name or not. (I'm
too lazy to come up with a better example right not.)

 

[Kenny McCormack]

As I noted in my reply, and as Mr. Heathfield also implied, Mr.
McCormack is a troll, the post you are referring to being but one of
many damning pieces of evidence against Mr. McCormack. Please do not
interpret Mr. McCormack's behavior as typical of comp.lang.c posters.

Grrrr. Somebody get up on the wrong side of the broom this morning?

 

[Jordan Abel]

Yes I found what I needed there. Seems I opened a can of worms here,
but being pointed to a site on mental illness for asking a off topic
question was uncalled for.

Yes, well... in his (rather dubious) defense, he wasn't saying _you_
were in any way mentally ill, he was saying that the rest of us were for
caring about on-topic-ness, and "trying" to be "helpful" by "explaining"
our reaction.

Of course my rude reply to that was rather
childish, and I apologize for that.

Yeah, well he is a bit of a...

nevermind.

 

[Kenny McCormack]

Yes, well... in his (rather dubious) defense, he wasn't saying _you_
were in any way mentally ill, he was saying that the rest of us were for
caring about on-topic-ness, and "trying" to be "helpful" by "explaining"
our reaction.


Yeah, well he is a bit of a...

nevermind.

Plus the fact, and I've been meaning to point this out for a while now,
I don't think most people think of wikipedia as a "site on mental
illness". I know people around here (clc) don't much care for
wikipedia, but I doubt many would go far as to say it is a site for
crazy people.

 

[Displacer]

On Tue, 24 Oct 2006 19:45:50 +0000 (UTC),

Plus the fact, and I've been meaning to point this out for a while now,
I don't think most people think of wikipedia as a "site on mental
illness". I know people around here (clc) don't much care for
wikipedia, but I doubt many would go far as to say it is a site for
crazy people.

I was refering to the link to aspergers

 

[Keith Thompson]

[the usual]
I was refering to the link to aspergers

I'm sure he knows perfectly well what you were referring to.

Kenny McCormack is a self-proclaimed troll. *Please* ignore him.

 

[Kenny McCormack]

[the usual]
I was refering to the link to aspergers

I'm sure he knows perfectly well what you were referring to.

Kenny McCormack is a self-proclaimed troll. *Please* ignore him.

Keith Thompson is a self-proclaimed netcop. *Please* ignore him.

 

[Paul Connolly]

Keith Thompson is a self-proclaimed netcop. *Please* ignore him.

I'd rather read anything Keith Thompson writes than anything Kenney McComack
writes - rationality takes precedence over the Celtic soul botherhood.

 

[Kenny McCormack]

I'd rather read anything Keith Thompson writes than anything Kenney McComack
writes - rationality takes precedence over the Celtic soul botherhood.

As you wish. But I haven't seen KT post anything other than "Off topic,
can't discuss it here, blah, blah, blah" (of course not in those
specific words) in, literally, years.