new order doubt

[Flash Gordon]

jacob navia wrote, On 16/07/08 00:45:

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.

You don't have to fix bugs the minute they are found. If you are going
to fix a bug (and non-paying users have no automatic right to expect you
to fix bugs they report) then fix them when it is convenient to you and
when you can take the time to fix them properly.

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"

Actually we have had a couple of people posting here in the past who
would use "char unsigned" or "long unsigned" etc. rather than the more
conventional order.

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.

No, people get frustrated by the way you seem to take bug reports as
personal attacks.

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.

No, Microsoft is *not* OK. Look at my headers and you will see that I am
not using any MS SW on this (my personal) machine.

You have reported here a bug in MSVC that means it does not conform. No
one from MS has attacked you for posting it. Someone else has reported
it to MS and we will no doubt see what kind of reaction it gets.

lcc-win is much more fun because you see the guy work like a fool
for nothing you see?

correct

Wrong. I would be much happier if in response to bug reports you just
posted a reply along the lines of:

Yes, that is a bug and I will investigate it when I have the time.

Or even:

I don't consider that to be an important bug so it may be a while
before it is fixed.

If your bug responses were more along those lines (acknowledging the
bug, neutral, not committing yourself to specific time scales so you)
you would probably find that baring propagation delays the thread would
stop immediately.

For a repeat of a bug report I would suggest a response along the line of:

I am aware of that bug and it is on my list of things to do when time
permits.


These suggestions are *not* attacking you, I am trying to help you by
suggesting ways you can avoid what you are seeing as attacks on you.

 

[Kaz Kylheku]

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.)

This is not much different from command line programs which allow the
repetition of some option to take on additional semantics. E.g. ``-v -v''
might specify that the program is to be more verbose than when only ``-v'' is
specified.

Hundreds of command line programs have to deal with attribute combination logic
similar to type specifier combinations. A myriad of options can be specified,
in any order. Some of them are permitted only in certain combinations. Those
that are boolean flip a flag. Those that are counted increment a counter.
After the options are syntactically processed, the constraints can be easily
verified by evaluating a set of predicates against the values of the variables.

The C specifiers can be handled similarly.

C has only a handful of specifiers. Of these, only long is repeatable. You
could use a bitset to represent the type specifiers, giving two bits to
``long''. When scanning the type specifiers, just flip the bits, or increment
the two-bit bitfield corresponding to long.

After the list is scanned, some simple bit tests can be used to determine
what the type is, and to detect invalid combinations. One strategy could
be a switch which handles all of the valid combinations. The default:
case reports an invalid combination of specifiers (which can be reported
that way, or more finely analyzed):

#define TS_INT 0x01
#define TS_UNSIGNED 0x02
#define TS_SIGNED 0x04
#define TS_LONG1 0x08
#define TS_LONG2 0x10

// ...

switch (typespec) {
case TS_INT:
case TS_INT | TS_SIGNED:
// signed int
break;
case TS_LONG1:
case TS_LONG1 | TS_INT:
// long int
break;
case TS_LONG2:
case TS_LONG2 | TS_INT:
// long long int
break;
case TS_UNSIGNED:
case TS_UNSIGNED | TS_INT:
// unsigned int
break;
case TS_UNSIGNED | TS_LONG1:
case TS_UNSIGNED | TS_LONG1 | TS_INT:
// unsigned long
break;
case TS_UNSIGNED | TS_LONG2:
case TS_UNSIGNED | TS_LONG2 | TS_INT:
// unsigned long long int
break;
// ...
default:
// invalid combination
break;
}

A better strategy perhaps would be to normalize the combinations first to
reduce the number of cases, since certain type specifier combinations are a
shorthand for longer combinations. For instance:

switch (typespec) {
case TS_UNSIGNED: // signed or unsigned by themselves imply int
case TS_SIGNED:
ts != TS_INT;
break;
case TS_CHAR: // plain char is either signed or unsigned
ts |= ((config_char_is_signed) ? TS_SIGNED : TS_UNSIGNED);
break;
}

// if it includes ``long'' or ``long long'' or ``short'', it's a kind of int
// except if ``double'', ``_Complex'', or ``_Imaginary'' are specified.

if ((typespec & TS_LONG1) || (typespec & TS_LONG2) || (typespec & TS_SHORT))
if (!(typespec & TS_DOUBLE) && !(typespec & TS_COMPLEX)
&& !(typespec & TS_IMAGINARY))
typespec |= TS_INT;

// if it is some kind of int, or char, and is not unsigned,
// then it must be signed.

if ((typespec && (TS_CHAR | TS_INT)) != 0 && (typespec & TS_UNSIGNED) != 0)
typespec |= TS_SIGNED;

Et cetera. After this, the typespec contains the canonical versions of all of
the types which have shorthand notations. So ``long'' has become ``signed long
int'', for instance. We can use a much simpler switch to validate the
combinations.

 

[Kaz Kylheku]

[...] 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!

What probably happened is that compilers historically accepted various
orders. Why? Because it's easier not to enforce an order in a syntax for
specifying a list of attributes. You simply loop over the syntax, and collect
the attributes. Enforcing order adds complexity to the program (and from the
user's point of view, unnecessary rigidity).

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

French.

Adjective before noun:

une petite table (a small table)

Adjective after noun:

une table ronde (a round table)

Both:

une petite table ronde

Of course, it's not the same adjective.

 

[Mark L Pappin]

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

No, it's still an adjective - the noun is implied.

ml "you rotten little ... " p

 

[new to c]

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.

But first people say -pedantic is god flag.
Then people say pedantic is bad flag.
Then compiler say pedantic not longer supported and people
say -A -A needed compile portable codes.
Portable very urgent of me because other people use other compiler.

In May sizeof(signed short) 2 and now sizeof(signed short) 4.

Codes use lot of signed short.

Friend still use compiler from May.

sizeof(short unsigned) still 2 but print warn.

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

No, compiler warn on line that print 2:

#include <stdio.h>

int main (void)
{
int i = sizeof(signed short); int j = __LINE__; // <-- line 5
printf("line: %d, sizeof: %d\n", j, i);

i = sizeof(short signed); j = __LINE__; // <-- line 8
printf("line: %d, sizeof: %d\n", j, i);

return 0;
}

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

test2

line: 5, sizeof: 4
line: 8, sizeof: 2

Is short signed better portable or is signed short better portable?

Is -A -A good flag or bad flag?

 

[santosh]

But first people say -pedantic is god flag.

Really!? Must be one powerful flag then.

Then people say pedantic is bad flag.

Who? Who are these "people" you keep mentioning anyway?

Then compiler say pedantic not longer supported

Shame. If you don't like it either take it up with the compiler vendor
or switch compilers.

and people
say -A -A needed compile portable codes.

"People" haven't said anything of the sort. Jacob co-developer of the
compiler that you are apparently using reported that to set lcc to
the "highest warning level" the -A -A flag combination is needed.

Portable very urgent of me because other people use other compiler.

If portability is very important to you then the following document will
be more important than implementation specific documentation and
understanding what it says will serve you better than conducting random
experiments.

In May sizeof(signed short) 2 and now sizeof(signed short) 4.

Codes use lot of signed short.
Friend still use compiler from May.

Tell him upgrade. After all it's a few minutes' download at best.

Is short signed better portable or is signed short better portable?

They refer to the same type and hence equally "portable".

Is -A -A good flag or bad flag?

That depends on whether you consider increased diagnostics and messages
during compilation a good thing or a bad thing.

Nice troll by the way.

 

[Keith Thompson]

new to c wrote: [snip]
Nice troll by the way.

No such thing.

 

[Joachim Schmitz]

jacob navia wrote, On 16/07/08 00:45:

No, Microsoft is *not* OK. Look at my headers and you will see that I
am not using any MS SW on this (my personal) machine.

You have reported here a bug in MSVC that means it does not conform.
No one from MS has attacked you for posting it. Someone else has
reported it to MS and we will no doubt see what kind of reaction it gets.

This someone was me and I just got their reply:
|Thanks for your feedback. We are escalating this bug to the product unit
|who works on that specific feature area. The team will review this issue
|and make a decision on whether they will fix it or not for the next
|release. Thank you, Visual Studio Product Team
|
|You may receive a general "Feedback Item Updated" notification as well, if
|any other changes were made by Microsoft.
|
|Thank you for using Microsoft Connect!
|
|Regards,
|
|the Microsoft Connect Team


It seems to be some kind of canned answer, but it is at least polite, fast
and professional. And I'm using the free Express version, so I'm not really
entitled for bug fixes...

See also
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=356377

Bye, Jojo