new order doubt

N

new to c

Today I install new lcc-win32 version 3.8. Compilation date: Jul 13 2008 00:25:11

I write this code

#include <stdio.h>

int main (void)
{
int i = sizeof(signed short);
printf("%d\n", i);

i = sizeof(short signed);
printf("%d\n", i);

return 0;
}

He warn

lc -A -A -ansic -O -c test2.c -o test2.obj
Warning test2.c: 8 no type specified. Defaulting to int
0 errors, 1 warning
lc test2.obj -o test2.exe

Code print

4
2

Is signed short better or is short signed better?
 
V

vippstar

Today I install new lcc-win32 version 3.8. Compilation date: Jul 13 2008 00:25:11

I write this code

#include <stdio.h>

int main (void)
{
int i = sizeof(signed short);
printf("%d\n", i);

i = sizeof(short signed);
printf("%d\n", i);

return 0;

}

He warn

lc -A -A -ansic -O -c test2.c -o test2.obj
Warning test2.c: 8 no type specified. Defaulting to int
0 errors, 1 warning
lc test2.obj -o test2.exe

Code print

4
2

Is signed short better or is short signed better?

so what? the implementation printed a warning, the implementation is
free to do that.
your code is valid, the results were OK, it compiled. what's your
problem? what do you mean by "best"?
 
K

Kaz Kylheku

Is signed short better or is short signed better?

In the list of type specifiers in a declaration or a type-name, the type
specifiers may only be present in certain combinations. So for instance
``signed struct ...'' doesn't make sense and is ruled out.

A valid combination of type specifiers may be written in any order: for example
``long unsigned int'', ``int unsigned long'' and ``int long unsigned'' are
equivalent.

The compiler has a bug because sizeof (signed short) and sizeof (short signed)
should yield the same value.
 
J

jacob navia

so what? the implementation printed a warning, the implementation is
free to do that.
your code is valid, the results were OK, it compiled. what's your
problem? what do you mean by "best"?

Look, I have been correcting this since Saturday, and it is quite
complex to correct. The version of yesterday had bugs that I
introduced because previous posts of this guy.

I tried to correct the parser to accommodate for the "any order" rule
of C99, and in so doing now there are some declarations that were
previously correctly parsed that are no longer OK. I corrected
most of them in the version I am uploading now.

And people like this guy, make me work for just nothing, nobody ever
uses "char signed" or "long signed long int" instead of "long long"

Yes, they must be laughing all the time, looking at me work like
a stupid each time they find another weird combination that doesn't
work as it should.

I can do the same, and today I found that MSVC accepts

unsigned long double s;

Even Microsoft has problems with this obscure rules.

But nobody will ever write anything about that. Microsoft is OK.
lcc-win is much more fun because you see the guy work like a fool
for nothing you see?


correct
 
C

CBFalconer

jacob said:
.... snip ...

Yes, they must be laughing all the time, looking at me work like
a stupid each time they find another weird combination that
doesn't work as it should.

I can do the same, and today I found that MSVC accepts

unsigned long double s;

Even Microsoft has problems with this obscure rules.

But nobody will ever write anything about that. Microsoft is OK.
lcc-win is much more fun because you see the guy work like a fool
for nothing you see?

Well, maybe it is time to let you in on a secret. We have this
newsgroup, alt.lccbugs.pedantic.new, on which various C pedants
propose and report on things tried out on lcc-win. When we find
something especially trivial and probably hard to properly handle,
we agree on it and post the result to c.l.c. We get much more
amusement seeing you squirm from a properly vetted insect. Merde
puissance treze.
 
R

Robert Gamble

so what? the implementation printed a warning, the implementation is
free to do that.
your code is valid, the results were OK, it compiled. what's your
problem?

Did you actually read the code and the output? "short signed" was
changed to "int", this is *not* OK, even with a warning.
what do you mean by "best"?

Do you have a definition of "best" in which "short signed" would
qualify as being better than "signed short" given that the latter is
probably used 100 times more often than the former in the real world?
In this case, "signed short" is obviously better since the compiler
being used has a bug that prevents it from correctly recognizing
"short signed".
 
K

Keith Thompson

new to c said:
Today I install new lcc-win32 version 3.8. Compilation date: Jul 13
2008 00:25:11

I write this code

#include <stdio.h>

int main (void)
{
int i = sizeof(signed short);
printf("%d\n", i);

i = sizeof(short signed);
printf("%d\n", i);

return 0;
}

He warn

lc -A -A -ansic -O -c test2.c -o test2.obj
Warning test2.c: 8 no type specified. Defaulting to int
0 errors, 1 warning
lc test2.obj -o test2.exe

Code print

4
2

Is signed short better or is short signed better?

Both signed short and short signed are valid. In my opinion signed
short is better style.

If the program and compiler output are as you say, this appears to be
a bug in lcc-win32. You should report it in comp.compilers.lcc or
directly to the maintainer, not here.

Your use of "-A -A -ansic", and your use of a pseudonym, make me
suspect that you've been following the discussions here, and that
you're already perfectly well aware of everything I've just told you.
Please stop trolling; it's not at all amusing.

Note: given the warning message, I probably would have expected
2
4
rather than
4
2
 
K

Keith Thompson

jacob navia said:
I tried to correct the parser to accommodate for the "any order" rule
of C99, and in so doing now there are some declarations that were
previously correctly parsed that are no longer OK. I corrected
most of them in the version I am uploading now.

FYI, the "any order" rule exists in C90 as well as in C99. The only
change as far as I can tell is the addition of "long long" and
variants of it, of _Bool, and of _Complex. (The fact that "long long"
uses the same keyword twice makes it conceptually slightly harder, but
it's not at all difficult to come up with a consistent
interpretation.)
And people like this guy, make me work for just nothing, nobody ever
uses "char signed" or "long signed long int" instead of "long long"

Nobody makes you do anything.
Yes, they must be laughing all the time, looking at me work like
a stupid each time they find another weird combination that doesn't
work as it should.

This "new to c" person appears to be a troll. Sure, he might be
laughing at you; so what? My advice: take whatever useful information
you can (it does appear he's found a bug), and otherwise ignore him.

I get personal abuse from the trolls all the time. I ignore it.
I can do the same, and today I found that MSVC accepts

unsigned long double s;

Even Microsoft has problems with this obscure rules.

But nobody will ever write anything about that. Microsoft is OK.

Microsoft has a bug. They should fix it. I don't have anything more
to say about it.

And if you think the general attitude here is that "Microsoft is OK",
you haven't been paying attention.
lcc-win is much more fun because you see the guy work like a fool
for nothing you see?

No. I see the guy *respond* like a fool to anything that he sees as
criticism -- and it's not fun at all.
 
K

Kaz Kylheku

Look, I have been correcting this since Saturday, and it is quite
complex to correct. The version of yesterday had bugs that I
introduced because previous posts of this guy.

I tried to correct the parser to accommodate for the "any order" rule
of C99, and in so doing now there are some declarations that were
previously correctly parsed that are no longer OK. I corrected
most of them in the version I am uploading now.

Are you trying to use syntax rules to match the valid combinations
of type specifiers?

Why don't you parse the syntax as is specified (arbitrary sequence
of type specifiers, including sequences that don't make sense), and
then do the constraint check on the resulting list.

It's more easily framed as a processing task than a parsing task.

A type made with three specifiers generates six possible sequences.
Are you going to match that with six different syntax rules?
But nobody will ever write anything about that. Microsoft is OK.
lcc-win is much more fun because you see the guy work like a fool
for nothing you see?

The improvement of your program isn't nothing. If you are unhappy with
that compensation, ask for money. Humm.
 
S

santosh

Gordon said:
jacob navia wrote:


Someone who owns their compiler should report this. I think Microsoft
is fairly proud of their standards conformance when it doesn't get
in the way of locking you in to non-standard extensions.


It's not nearly as much fun with Microsoft since (a) you have to
pay for the new version of the compiler to test it, and (b) it
probably takes at least a year to correct a bug, even if it's
mis-spelling "Microsoft" in the copyright notice.

You mean that existing owners of legal copies of MSVC are not entitled
to free service patches and maintenance!?
 
V

vippstar

Did you actually read the code and the output? "short signed" was
changed to "int", this is *not* OK, even with a warning.

Yeah, I just noticed. I guess I was tired at the time, I thought the
"new to c" poster complained about the warning rather than the result.
Do you have a definition of "best" in which "short signed" would
qualify as being better than "signed short" given that the latter is
probably used 100 times more often than the former in the real world?
In this case, "signed short" is obviously better since the compiler
being used has a bug that prevents it from correctly recognizing
"short signed".

It's better because it's more oftenly used in the real world? In that
case, <stdio.h> is better than <stdlib.h>.
0 is also better than 42. PHP is better than lisp. </unjustified
claims> My question was rhetorical, "best" wasn't making sense.
 
B

Bartc

Look, I have been correcting this since Saturday, and it is quite

The original post is clearly provocation.

Since it seems this 'bug' has been there for years, and there is a very
simple workaround, I would not have given it very high priority.

Perhaps you should make this a feature of your compiler, forcing people to
use a declaration style consistent with 99% (or whatever) of other code, and
then maybe in the next C standard, the 'any order' rule will be deprecated.
 
R

Robert Gamble

Yeah, I just noticed. I guess I was tired at the time, I thought the
"new to c" poster complained about the warning rather than the result.



It's better because it's more oftenly used in the real world? In that
case, <stdio.h> is better than <stdlib.h>.
0 is also better than 42. PHP is better than lisp. </unjustified
claims> My question was rhetorical, "best" wasn't making sense.

It's better because it is *the same* except for the fact that it is
more easily recognized by most programmers, more widely supported by
compilers, etc. The OP might not have given a definition for "best"
in this case but I can think of several reasons to suggest "signed
short", can you think of one serious reason to suggest "short signed"?
 
3

31349 83652

Robert said:
[...] I can think of several reasons to suggest "signed
short", can you think of one serious reason to suggest "short signed"?

In several languages, the adjective usually follows the noun; unlike
in English where usually the adjective precedes the noun.

signed short ==> adjective noun ==> English and possibly other
languages
short signed ==> noun adjective ==> some other languages
 
B

Bartc

31349 83652 said:
Robert said:
[...] I can think of several reasons to suggest "signed
short", can you think of one serious reason to suggest "short signed"?

In several languages, the adjective usually follows the noun; unlike
in English where usually the adjective precedes the noun.

signed short ==> adjective noun ==> English and possibly other
languages
short signed ==> noun adjective ==> some other languages

Good answer, although I doubt the designers of C had that in mind!

But which language uses adjective-noun-adjective as in long int long?
 
3

31349 83652

Richard said:
31349 83652 said:
Robert said:
[...] I can think of several reasons to suggest "signed
short", can you think of one serious reason to suggest "short signed"?

In several languages, the adjective usually follows the noun; unlike
in English where usually the adjective precedes the noun.

signed short ==> adjective noun ==> English and possibly other
languages
short signed ==> noun adjective ==> some other languages

"short" and "signed" are both adjectives.

Right.
But I'm sure my meaning was understood :)


Anyway ... with proper nouns

signed char ==> adjective noun ==> English
char signed ==> noun adjective ==> other

volatile int ==> adj noun
int volatile ==> noun adj

etc
 
B

Bartc

Richard Heathfield said:
31349 83652 said:
Robert said:
[...] I can think of several reasons to suggest "signed
short", can you think of one serious reason to suggest "short signed"?

In several languages, the adjective usually follows the noun; unlike
in English where usually the adjective precedes the noun.

signed short ==> adjective noun ==> English and possibly other
languages
short signed ==> noun adjective ==> some other languages

"short" and "signed" are both adjectives.

"short" can be either. In C I guess short is an adjective when followed by
int, and a noun otherwise.
 
K

Keith Thompson

31349 83652 said:
Robert said:
[...] I can think of several reasons to suggest "signed
short", can you think of one serious reason to suggest "short signed"?

In several languages, the adjective usually follows the noun; unlike
in English where usually the adjective precedes the noun.

signed short ==> adjective noun ==> English and possibly other
languages
short signed ==> noun adjective ==> some other languages

But "signed" and "short" are both adjectives, abbreviations for
"signed int" and "short int" respectively. And both can be used as
nouns by dropping the "int": "signed" is a valid name for int, and
"short" is of course a valid name for short int.
 
K

Keith Thompson

Bartc said:
The original post is clearly provocation.
Agreed.

Since it seems this 'bug' has been there for years, and there is a
very simple workaround, I would not have given it very high
priority.

Perhaps you should make this a feature of your compiler, forcing
people to use a declaration style consistent with 99% (or whatever)
of other code, and then maybe in the next C standard, the 'any
order' rule will be deprecated.

He's certainly free to do that, if he's willing to give up on the idea
of conforming to the C standard. He can enforce consistent
indentation if he wants to, or reject functions longer than N lines.

He's not required to produce a conforming C99 compiler if he doesn't
want to. (Personally, I haven't even attempted to do so, so I'm in no
position to complain if he doesn't. But then I don't claim that I
have.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top